In addition, this PR also brings back the project isolation between the generator and the module plugin.
Checksum Task and Build Report tasks now run as part of ./gradlew build. The checksum task will run a hash function against the signed modl file that was output by the signModule task. By default, it uses SHA256. The resulting digest is added to a 'checksum.json' file located at build/checksum/ by default.
The ModuleBuildReport task executes following the checksum task, creating a json file in the root of the build folder. This json contains information about the module and its dependencies. In addition, it will include any configuration that was added to the metaInfo property of the ModuleSettings instance declared in theignitionModule { configuration. This map supports only string keys and values, and has no impact on the module itself. Rather it's useful for automation systems that may need additional information to execute tests, releases, etc. For example, build timestamps, release upload URLS, or changelogs might be added to this map dynamically for inclusion into the buildResult.json file, which may be read by some other downstream actor/task.
In addition, this PR also brings back the project isolation between the generator and the module plugin.
Checksum Task and Build Report tasks now run as part of
./gradlew build. The checksum task will run a hash function against the signed modl file that was output by the signModule task. By default, it uses SHA256. The resulting digest is added to a 'checksum.json' file located atbuild/checksum/by default.The
ModuleBuildReporttask executes following the checksum task, creating a json file in the root of the build folder. This json contains information about the module and its dependencies. In addition, it will include any configuration that was added to the metaInfo property of the ModuleSettings instance declared in theignitionModule {configuration. This map supports only string keys and values, and has no impact on the module itself. Rather it's useful for automation systems that may need additional information to execute tests, releases, etc. For example, build timestamps, release upload URLS, or changelogs might be added to this map dynamically for inclusion into the buildResult.json file, which may be read by some other downstream actor/task.