ci: workflow to publish prebuilt ld and binutils

[crazy-max]

needs #114

Adds workflows to publish prebuilt ld and binutils using a dynamic matrix based on grouped bake targets to distribute the workload over several runners.

It will only build on push on master. To create a new release the workflow needs to be triggered manually:

Git tag will be in the form:

• binutils/2.36.1-5 (where 5 is the run number for the workflow ; unique)
• prebuilt/ld-2.36.1-8 (where 8 is the run number for the workflow ; unique)

Test prebuilt ld:

• https://github.com/crazy-max/xx/actions/runs/4155796216/jobs/7189273401#step:5:68
• https://github.com/crazy-max/xx/releases/tag/prebuilt%2Fld-2.36.1-30
• Update base/xx-ld-shas crazy-max/xx#1

Test binutils:

• https://github.com/crazy-max/xx/actions/runs/4155561424/jobs/7188907667#step:4:12
• https://hub.docker.com/r/crazymax/xx/tags?page=1&name=binutils-

[tonistiigi]

I'll try to split up all the ld targets to separate Dockerfile inside a subdirectory. Then we can make this workflow so that it runs only if files inside the subdirectory change. If it is simple, we can also set up some bot that would allow to trigger the additional CI on-demand.

For the release, we do not need to release this very often. It shouldn't be on every master branch change. The method we use in binfmt is quite nice to trigger it from manual form and then also create a tag for the deployment.

Note that releasing new binaries does not change xx. The digests need to be updated manually later on. If this isn't implemented already the release should generate a file with all the digests so it can be easily copied to the scripts (or we could keep it in a separate file as well and modify script to link it).

[tonistiigi]

Why do we need these separate targets in here. ld64-tgz already builds all combinations.

[crazy-max]

It's to reduce build time so we can distribute builds across multi runners in the pipeline, see: https://github.com/crazy-max/xx/actions/runs/4155296585

[crazy-max]

Note that releasing new binaries does not change xx. The digests need to be updated manually later on. If this isn't implemented already the release should generate a file with all the digests so it can be easily copied to the scripts (or we could keep it in a separate file as well and modify script to link it).

Yes indeed, I have another branch that would update shas and open a pull request with new sums: master...crazy-max:xx:binutils-2.38#diff-ee26bbfc163346b915c6c9c65709c15b58251a23a0d9ecaaed6d2d20f969fb92R96-R148

[crazy-max]

For the release, we do not need to release this very often. It shouldn't be on every master branch change. The method we use in binfmt is quite nice to trigger it from manual form and then also create a tag for the deployment.

Agree, will change this.

[crazy-max]

Updated, see PR description

[crazy-max]

rebased and needs #114