It appears as though this is the first pre-singleton type to actually
be registered with the InitRegistrationContext as it failed due to an
uninitialized map, so this change also fixes that.
Bug: 182885307
Test: m nothing
Change-Id: Ibbf6d0db5f3c2fcc89291a16aa5f16b8b5009bd3
The methods returns a copy of TestingBuildParams with every usage of a
path that is relative to the temporary test build directory with a path
relative to a notional top. Similar to how PathRelativeToTop does.
Bug: 182885307
Test: m nothing
Change-Id: I6ec20fc52ed76748138f0d48b4df80f765dfcfdc
When searching for an TestingBuildParams this change will compare the
supplied path against the value returned by PathRelativeToTop() as well
as the String() and Rel() values. In the event that it cannot find the
file it also formats the available outputs, one per line with both rel
and path relative to top.
Bug: 182885307
Test: m nothing
Change-Id: Icbd37018b9a028abf37e27d1bea12a407316e031
Allows the removal of the provider parameter and makes it easier to add
new functionality to baseTestingComponent.
Bug: 182885307
Test: m nothing
Change-Id: Ie8ac600cbce982f2c5fc24a22968efe0c2a29d0c
Prior to this FixtureFactory was basically a FixturePreparer with the
additional support for buildDirSupplier. This makes that a reality by
moving the functionality of FixtureFactory into FixturePreparer and
making FixtureFactory extend that with buildDirSupplier.
This also deprecates the Extend() method in favour of simply using the
GroupFixturePreparers() method.
Once all usages of buildDir have been removed so the buildDirSupplier
is no longer required then FixtureFactory will be removed altogether.
In the meantime follow up changes will migrate those tests that do not
require a buildDirSupplier to just use FixturePreparers in preparation
for the eventual removal of FixtureFactory.
Bug: 183235980
Test: m nothing
Change-Id: Ibb4e5bfec2f76ee34dd7de6aed6bbbfe27d337b8
The visit() method was dropped in favor of a list() method as the
latter makes it easier to treat fixtureFactory, simpleFixturePreparer
and compositeFixturePreparer as simple collections of already flattened
and deduped *simpleFixturePreparers. That will be used in a follow up
change.
Bug: 183235980
Test: m nothing
Change-Id: Ia41ae9bd4f9c39c85865ba698e0da6be00519caf
The ExtendWithErrorHandler method simply wraps the FixtureErrorHandler
in a FixturePreparer that will set the error handler in the fixture.
Bug: 183235980
Test: m nothing
Change-Id: Icf9a5f62cb532efc120300c2f906cd3397aa6763
The Preparer() method allows for another test to be run using the same
preparers as were used to create the TestResult. That is useful when
testing functionality like the sdk snapshot mechanism that generates an
Android.bp and a set of files that are intended to be reconsumed by
Soong. This method allows the test to process that output to ensure
that it is valid. A follow up change will migrate the CheckSnapshot()
method to use this as part of the migration of the sdk package to the
test fixture model.
Previously, the dedupAndFlattenPreparers() would not construct a list
containing all the preparers passed to it as it was trying to avoid
constructing such a list unless necessary. However, as every usage of
this method now needs to construct such a list that functionality has
been added to it.
Bug: 181070625
Test: m nothing
Change-Id: Iab34e2c861bdfd05c44e982224f70c5abc19e468
PlatformSepolicyVersion and BoardSepolicyVers haven't assigned correctly
so far. Below is the reason why it hasn't been discovered yet.
DeviceConfig.PlatformSepolicyVersion() was added to support mixed
sepolicy build (setting BOARD_SEPOLICY_VERS and building vendor sepolicy
with old plat policy files). Soong compares PlatformSepolicyVersion()
and BoardSepolicyVers(), and used old vendor sources if both are
different. Back then, the only place where such logic played a role was
selinux contexts. Test codes were running as intended: after setting
BOARD_SEPOLICY_VERS the context files were built against old policies.
But there were two mistakes:
1) PlatformSepolicyVersion() was not added to soong_config.mk, so it was
always empty.
2) BOARD_SEPOLICY_VERS was set to default in system/sepolicy/Android.mk,
which was processed after soong_config. So if BOARD_SEPOLICY_VERS was
not set in BoardConfig.mk, BoardSepolicyVers() was empty, not
PLATFORM_SEPOLICY_VERSION.
And there were no issues as Soong only checked equality.
To fix the issue correctly, this commit adds the variable
PlatformSepolicyVersion, and then handles BoardSepolicyVers correctly by
returning PlatformSepolicyVersion if it's empty.
Test: set BOARD_SEPOLICY_VERS and see vendor_file_contexts changes
Change-Id: Ie55827f47d2903e9739eccacc3874d354d5c9f2d
The ExcludeFromApexContentsTag marker interface was added to avoid
every implementation of DepIsInSameApex() from having to deal with the
special tags, like PrebuiltDepTag. Unfortunately, when adding that
not all calls to DepIsInSameApex() were protected which meant that the
BootImageModule, which panics if it doesn't recognize a tag, was
causing failures. This change documents the need and improves the
consistency.
A follow up change will add a test for this.
Bug: 182992071
Test: m nothing
Change-Id: If0bf9a7447ebf7a0bb0c88e91951a7220d4af45c
Allow passing a remoteexec.REParams to RuleBuilder to configure it to
run the rule remotely through RBE. Requires the rule to use
SandboxInputs, which ensures that RuleBuilder is aware of all of the
inputs and outputs of the rule.
Running sbox in RBE initially seems unnecessary, as RBE is already a
good sandbox, but reproxy can execute RBE actions locally when configured
for local execution, local fallback or racing. Using sbox in RBE ensures
that these local actions are also sandboxed, giving consistent results
between directly executed actions, local RBE actions, and remote RBE
actions.
Bug: 182612695
Test: manual
Change-Id: Icf2f24dde8dee833eb680ba22566a8e1c0143b15
Remove the references to the android package in remotexec so that
the android package can reference the remoteexec package. This
will allow RuleBuilder to integrate directly with remoteexec.
Bug: 182612695
Test: m checkbuild
Change-Id: I15be5ef126d8aacbd605518638f341daf6f31bb3
When RuleBuilder.SandboxInputs() is called configure sbox to copy
all the input files into the sandbox directory and then change the
working directory there when running the command.
Copying input files into the sandbox directory gets tricky when
the input file is the output file from another rule, and could
be at an arbitrary, possibly absolute path based on the value
of OUT_DIR. They will need to be copied to a directory in the
sandbox using the path relative to OUT_DIR.
RSP files need special handling, they need to both be copied into
the sandbox as an input, rewritten to contain paths as seen in the
sandbox, and references to them on the command line need to use
sandbox paths.
Bug: 182612695
Test: rule_builder_test.go
Change-Id: Ic0db961961b186e4ed9b76246881e3f04971825c
* changes:
Convert android/ninja_deps_test.go to test fixtures
Add NinjaDeps to TestResult
Convert android/singleton_module_test.go to test fixtures
Convert android/neverallow_test.go to test fixtures
Convert android/singleton_module_test.go to test fixtures
Convert android/variable_test.go to test fixtures
Convert android/soong_config_modules_test.go to test fixtures
Convert android/mutator_test.go to test fixtures
Convert android/deptag_test.go to test fixtures
