Signing for compliance builder implemented and tested

[godofredoc]

Signing for compliance will be implemented as multiple small independent pieces with a final integration task. The list of tasks is the following:

• Create a signer.py recipe in https://cs.opensource.google/flutter/recipes/+/main:recipes/engine_v2/
• The recipe receives a property config_name. This property is used to read the configuration from a checkout of the engine repository and ci/builders/<config_name>
• The json file is read to collect the final destination of the artifacts generated by the build. This includes both the artifacts generated by builders and for global generators.
• The list is iterated running one signer tool command per file. This can be optimized using the multiprocessing API.
• For simplicity we assume that every single artifacts needs to be codesigned and the action of signing or not is delegated to the signing tool

[godofredoc]

To test the implementation we need to:

• git add signer.py.
• led get-builder 'luci.flutter.try:Mac Engine Drone' > signer.json
• vim signer.json and replace recipe name with engine_v2/signer and add a property called config_name with a value of mac_host_engine
• run the signer with led cat signer.json | led edit-recipe-bundle | led edit-system -p 20 | led launch -modernize
• Add functionality to recipe, test, iterate

[godofredoc]

Once we land this part I'll provide instructions for the second part and third parts.

[godofredoc]

\cc @khyati82

[XilaiZhang]

Yeah earlier today I re-studied schedule_builds and my understanding was that since each build in the builds will share the same recipe when we trigger them from shard_util_v2.schedule_builds, I would normalize the format of 'builds' and 'archives' in shard util v2, so that the signer recipe can use the same runsteps() for each build no matter it is in the format of 'builds' or the format of 'archives'. But yeah looking at the spec now I guess I implemented the wrong thing again. Fortunately this current spec seems very easy and I can do it 👍

[godofredoc]

Signer recipe is ready: https://flutter-review.googlesource.com/c/recipes/+/35006

[godofredoc]

Integrate signer builder with recipes v2:

• At the end of the engine_v2 recipe add a new section for signing. https://cs.opensource.google/flutter/recipes/+/main:recipes/engine_v2/engine_v2.py;l=167
• We need to iterate the builds list and pass every archive config to paths = api.archives.engine_v2_gcs_paths(checkout, archive_config) the will give us a DS with the local path and final destination.
• Send the full list of archive artifacts to the signer recipes using the shard_util_v2 schedule method.

[XilaiZhang]

As pointed out by sir Godofredo and Christopher, the new way of building it is through led get-build -real-build 8797863654106084673 > signer-2.json

[godofredoc]

Closing this as complete, mac_ios and mac_host_engine are now code signing artifacts correctly in beta:

• https://ci.chromium.org/p/flutter/builders/prod/Mac%20mac_host_engine/3184
• https://ci.chromium.org/p/flutter/builders/prod/Mac%20mac_ios_engine/3018

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.