chromium-src-build/write_build_date_header.py

119 строки
4.0 KiB
Python
Исходник Обычный вид История

Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
#!/usr/bin/env python
# Copyright (c) 2016 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
"""Writes a file that contains a define that approximates the build date.
build_type impacts the timestamp generated:
- default: the build date is set to the most recent first Sunday of a month at
5:00am. The reason is that it is a time where invalidating the build cache
shouldn't have major reprecussions (due to lower load).
- official: the build date is set to the current date at 5:00am, or the day
before if the current time is before 5:00am.
Either way, it is guaranteed to be in the past and always in UTC.
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
It is also possible to explicitly set a build date to be used.
"""
import argparse
import calendar
import datetime
import doctest
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
import os
import sys
def GetFirstSundayOfMonth(year, month):
"""Returns the first sunday of the given month of the given year.
>>> GetFirstSundayOfMonth(2016, 2)
7
>>> GetFirstSundayOfMonth(2016, 3)
6
>>> GetFirstSundayOfMonth(2000, 1)
2
"""
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
weeks = calendar.Calendar().monthdays2calendar(year, month)
# Return the first day in the first week that is a Sunday.
return [date_day[0] for date_day in weeks[0] if date_day[1] == 6][0]
def GetBuildDate(build_type, utc_now):
"""Gets the approximate build date given the specific build type.
>>> GetBuildDate('default', datetime.datetime(2016, 2, 6, 1, 2, 3))
'Jan 03 2016 01:02:03'
>>> GetBuildDate('default', datetime.datetime(2016, 2, 7, 5))
'Feb 07 2016 05:00:00'
>>> GetBuildDate('default', datetime.datetime(2016, 2, 8, 5))
'Feb 07 2016 05:00:00'
"""
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
day = utc_now.day
month = utc_now.month
year = utc_now.year
if build_type != 'official':
first_sunday = GetFirstSundayOfMonth(year, month)
# If our build is after the first Sunday, we've already refreshed our build
# cache on a quiet day, so just use that day.
# Otherwise, take the first Sunday of the previous month.
if day >= first_sunday:
day = first_sunday
else:
month -= 1
if month == 0:
month = 12
year -= 1
day = GetFirstSundayOfMonth(year, month)
now = datetime.datetime(
year, month, day, utc_now.hour, utc_now.minute, utc_now.second)
return '{:%b %d %Y %H:%M:%S}'.format(now)
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
def main():
if doctest.testmod()[0]:
return 1
argument_parser = argparse.ArgumentParser(
description=sys.modules[__name__].__doc__,
formatter_class=argparse.RawDescriptionHelpFormatter)
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
argument_parser.add_argument('output_file', help='The file to write to')
argument_parser.add_argument(
'build_type', help='The type of build', choices=('official', 'default'))
argument_parser.add_argument(
'build_date_override', nargs='?',
help='Optional override for the build date. Format must be '
'\'Mmm DD YYYY HH:MM:SS\'')
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
args = argument_parser.parse_args()
if args.build_date_override:
# Format is expected to be "Mmm DD YYYY HH:MM:SS".
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
build_date = args.build_date_override
else:
now = datetime.datetime.utcnow()
if now.hour < 5:
# The time is locked at 5:00 am in UTC to cause the build cache
# invalidation to not happen exactly at midnight. Use the same calculation
# as the day before.
# See //base/build_time.cc.
now = now - datetime.timedelta(days=1)
now = datetime.datetime(now.year, now.month, now.day, 5, 0, 0)
build_date = GetBuildDate(args.build_type, now)
Makes GetBuildTime behave sanely on all build types. After discussion with maruel and agl, it seems that (1) for the purposes of build determinism, it's necessary to be able to arbitrarily set the build time. (2) for the purposes of continuous integration, longer duration between cache invalidation is better, but >=1mo is preferable. (3) for security purposes, timebombs would ideally be as close to the actual time of the build as possible. It must be in the past. (4) HSTS certificate pinning is valid for 70 days. To make CI builds enforce HTST pinning, <=1mo is preferable. All of these can reasonably be satisfied by using different settings for CI versus official builds: - For official build, the build time is set to 5:00am of the day of the build or the day before. - For continuous integration build, the build time is set to the current month. If the current day is within the first week of the month and last Sunday wasn't part of the current month, the Sunday of the previous month is used. This results that cache invalidation happens on a Sunday, which is preferable from an infrastructure standpoint. - In the case that the build time needs to be set to a specific value (i.e. to reproduce a build), the GN/GYP variable 'override_build_date' can be used to set the BUILD_DATE explicitly. Its format is "Mmm DD YYYY". The way it is done is: - Generate $target_gen_dir/generated_build_date.h that defines BUILD_DATE. Its value depends on if an official build is done or not. - This step depends on build/util/LASTCHANGE so it is run at every sync. The file is only touched if the content changed to not affect null build. Most importantly, this change removes the need of both GN/GYP variable "dont_embed_build_metadata" and C define "DONT_EMBED_BUILD_METADATA"; the build is always deterministic (up to a month) by default. This removes the risk oversight of forgetting to set this variable, which already happened. R=maruel@chromium.org BUG=489490 Review URL: https://codereview.chromium.org/1641413002 Cr-Original-Commit-Position: refs/heads/master@{#375136} Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src Cr-Mirrored-Commit: 08d91b75212b6592f05ff993d5a71c0f5a546563
2016-02-12 09:23:42 +03:00
output = ('// Generated by //build/write_build_date_header.py\n'
'#ifndef BUILD_DATE\n'
'#define BUILD_DATE "{}"\n'
'#endif // BUILD_DATE\n'.format(build_date))
current_contents = ''
if os.path.isfile(args.output_file):
with open(args.output_file, 'r') as current_file:
current_contents = current_file.read()
if current_contents != output:
with open(args.output_file, 'w') as output_file:
output_file.write(output)
return 0
if __name__ == '__main__':
sys.exit(main())