Enforce this requirement for delivery to aosp:
- "A release config shall exist in at most one of build/release and
vendor/google_shared/build/release".
Bug: 349843674
Bug: 370829778
Bug: 371026851
Test: manual, TH
(cherry picked from https://android-review.googlesource.com/q/commit:639423daacc146457f10cf3d060bc2932dc903eb)
Merged-In: Ie4bc8137f2bd10f3b90efcffe8d2c8e317dcc2fc
Change-Id: Ie4bc8137f2bd10f3b90efcffe8d2c8e317dcc2fc
Previously, globs worked by having soong_build rewrite a ninja file
that ran the globs, and then dependended on the results of that ninja
file. soong_build also pre-filled their outputs so that it wouldn't
be immediately rerun on the 2nd build.
However, the pre-filling of outputs worked for ninja, because although
it updated their timestamps, the soong ninja file was then touched
by soong_build after that, so the soong_build ninja file was newer
and ninja wouldn't rerun soong. But N2 reruns actions if their inputs'
mtimes change in any way, not just if they're newer. Similarly,
hashed-based ninja implementations could not enforce an order on
file contents, so they would have the same problem.
To fix this, lift the glob checking out of ninja and into soong_ui.
Soong_build will output a globs report file every time it's run, and
every time soong_ui is run it will check the globs file, and if any
globs change, update an input to soong_build. soong_ui is essentially
doing what was done in ninja with bpglob actions before.
Bug: 364749114
Test: m nothing, m nothing again doesn't reanalyze, create a new file under a glob directory, m nothing again reanalyzes
Change-Id: I0dbc5ec58c89b869b59cd0602b82215c4972d799
So that the build can't access extra information unintentionally.
Particuarly ANDROID_BUILD_TOP is dangerous.
In the future PATH should be locked down as well.
Bug: 307824623
Test: Added a all_genrules target and built that
Change-Id: I88bb0efb0a82529a1c85875a53cf20c8384d07fe
Currently, OUT_DIR is inherited from the parent process, leading to
scripts being able to find the output directory when the enviornment
variable is set to an absolute path. When sandboxing a command,
also rewrite the OUT_DIR environment variable to the sandboxed one,
so that scripts can't find the real out dir.
Bug: 307824623
Test: Presubmits
Change-Id: I325071121a60bddc4105df680fbdfe3d11dc94e2
Rename `enum workflow` to `enum Workflow`, and similarly for `message`
declarations.
This should reduce downstream issues when the protos are converted to
non-Go languages.
Bug: 347076012
Test: TH, manual
Change-Id: Iee20dc763fcef497d8b88f83f489604fda104100
Flags must only be declared in one place in the tree. This change
prevents new ones from being added while we fix the bad flags already
present.
Bug: 352105274
Test: manual
Merged-In: I8c4bf2b2852685e84177500f28fe8908016082b9
Change-Id: I8c4bf2b2852685e84177500f28fe8908016082b9
Throw an error if a release config dir appears to contribute flagging
overrides to a release config without actually doing so (by having
release_configs/{name}.textproto).
Bug: None
Test: manual, TH
Change-Id: Ie71cd6898bda4b8da8d58c3e23fb89ed17ebebd1
release_config_artifact.directories contains the ordered list of
release config map directories that contributed flag declarations and/or
flag values to the release config (ignoring inheritance).
release_config_artifact.value_directories contains the ordered list of
release config map directories where we found a release_config message
for this release config.
Also, improve various error messages.
Bug: None
Test: manual, TH
Change-Id: Ifb67e80fc8746ae466f2e3515c5b0c3ba07a291d
C++ hates it when there is a field with the same name as a message.
Bug: 351826222
Test: manual, TH
Change-Id: I45355baacce57309c72d1658a095b328841a8d9a
This build flag causes us to create aconfig flag artifacts for the
given extra release configs.
Bug: 298444886
Test: manual
Change-Id: I10148f6e7318b0477438ed1d8baafbf4dc594c90
Having a message name and field name that are the same causes C++
generated code to fail.
Bug: 347076012
Test: manual, TH
Change-Id: I198e92dc906d476881ef351e603ef2ea63ce5848
Currently, when you do `m` repeatedly, it does a little bit of
rebuilding to copy release config files around. If we change
release-config to only rewrite the files if they've changed, we
get a proper "ninja: no work to do." message.
Bug: 346757289
Test: m repeatedly
Change-Id: I9c1f6d34ec20d14b684a0183c5ec457ea92440f9
This allows us to generate an error when it is then set in an earlier
location in the list.
Bug: 346883187
Test: manual
Change-Id: I1c8389ff0d5a16c080008967ab5e0b9b93101301
- move WriteMakefile to release_config.go
- use slices.Sort instead of slices.SortFunc where applicable.
- improve error message when inheriting an invalid release config
Bug: None
Test: manual
Change-Id: Id959ddccc75fad912518d5cce8d14da506e0bbea
If we are setting a flag for a release config in a map directory that
doesn't yet declare that release config, this map directory needs to
contribute to the release config.
Bug: 345278765
Test: manual
Change-Id: Ie4e74bce008c4c4fdc4bc16e3209f0d9ef9cf8a2
Let graphvis decide how to best display the release config graph.
Also add some color to the graph.
Bug: None
Test: manual
Change-Id: If8b9eb41eb78bd553fd5543938a2c1c098b41591
If the release config has a name matching build prefixes, it may not
inherit from an alias.
Bug: 340208722
Bug: 328495189
Test: manual
Change-Id: Idb7b1fa372db980c5732b700663553b7a9bf4a36
Include those paths in the inheritance graph.
Bug: 348495189
Test: manual
Merged-In: I993af3a34ab7dd9a3346c6ffccb17e7abff23545
Change-Id: I993af3a34ab7dd9a3346c6ffccb17e7abff23545
release-config now creates `inhertance_graph-${TARGET_PRODUCT}.dot`
showing the inheritance graph for all release configs present for
${TARGET_PRODUCT}.
Bug: 328495189
Test: manual, TH
Change-Id: I79242eaa848e0374b33f376e44d8938e9d398e21
If the release config name is a build prefix and different from the
inherited value, set RELEASE_PLATFORM_VERSION based on the release
config name.
Bug: 348495189
Test: manual
Change-Id: I95d715150cba9b57e343a8b8364d36f38dcc18a3
Define release_flags_json module type to install build_flags.json in
'etc'. release_flags_json reads the json files generated from the
soong release-config command.
Bug: 324996303
Test: build and see if the files are installed
Change-Id: I8cdcb7c61dd75cc54e4912d2ed7d1687f424151c
Many of the fields in `flag_artifact` are not valid in
the all_build_flag_definitions artifact.
Bug: 328495189
Test: manual
Change-Id: I00eab1ef76f67f7db2118a6fc0d5771e3dd39fbb
This was previously used in conjunction with blueprint_package_includes
to prune Android.bp files from soong analysis.
Test: m nothing
Bug: 308188212
Change-Id: Ie82e20eec63bd0be70e1cf0290c70f62d5621c76
Currently, both stdout and stderr are redirected to a file. We want
stderr to be visible on the terminal in case the release config
fails, but we don't want to see the spam of warnings release config
always produces.
Move the warnings to stdout so they stay in the file when we start
showing stderr.
Test: m nothing
Change-Id: Ic869675f917270a472142b6e3a4210acaad7499b
And use the types to appropriately type selects on the release
variables.
Bug: 323382414
Test: Presubmits
Change-Id: Ide7eca95662caaa7b4be42e20399d9fcd7fed35f
