Add step for binutils build in cross-arm{64}-alpine

[am11]

While we can use llvm's linker (lld), we still want to keep gnu binutils gold linker (ld) in Alpine linux, as we had in 16.04 b016fdd.

cc @jkotas

[am11]

@mthalman, could you please rebuild Ubuntu 22.04 crossdep images so we get 2023 tags? There is a fix for arm(32) which went in llvm-15 in December after the last build.

[am11]

I see that there is a 2023 tag, but it looks like the re-build was skipped (created date is old and we don't have llvm 15 fix which went in mid December):

              "simpleTags": [
                "ubuntu-22.04-cross-arm-alpine-20230106221608-3fc5553",
                "ubuntu-22.04-cross-arm-alpine-staging"
              ],
              ...
              "created": "2022-11-23T15:59:20.0048712Z",

[mthalman]

@am11 - Are you referencing staging? Or is the staging suffix excluded from your configuration? If you're referencing staging I can get that updated. But by default (without the staging suffix), things are coming from the production branch and that build is handled by the .NET Eng. Services team (cc @michellemcdaniel). They build from that branch on a regular cadence, but things have been paused during the holiday break and I don't know when the next update is scheduled.

[am11]

I was using ubuntu-22.04-cross-arm-alpine-20230106221608-3fc5553. Debian/Ubuntu push package hotfixes but docker builder skips the unchanged steps in Dockerfile. I think what we want is 'always force rebuild' behavior for prereq images whenever the new tags will be published.

[mthalman]

I was using ubuntu-22.04-cross-arm-alpine-20230106221608-3fc5553.

Ideally, everyone should be using the floating tags now: ubuntu-22.04-cross-arm-alpine. That will always give you the latest version. Note that the ubuntu-22.04-cross-arm-alpine-20230106221608-3fc5553 image is from the main branch, not the production branch. Images from the main branch use a -staging suffix (e.g. ubuntu-22.04-cross-arm-alpine-staging) for the floating tag.

Debian/Ubuntu push package hotfixes but docker builder skips the unchanged steps in Dockerfile. I think what we want is 'always force rebuild' behavior for prereq images whenever the new tags will be published.

That's the intention with builds from the production branch, to always get latest versions of packages by doing a force rebuild. But there hasn't been a build from the production branch since early December. I'll leave it to @michellemcdaniel on determining when to do that since Eng. Services wants a rollout schedule for the images.

[am11]

Yup, I was using staging tags just to test a bug fix on arm32 and noticed that while the new tags were published, the image still has old bits (running update with apt fix the bug I was monitoring).

IMO, even for staging, this situation is not ideal. New tag should imply new image build. Otherwise, there is no point to publish/advertise a new tag for old stuff when the build steps were actually skipped.

[mthalman]

IMO, even for staging, this situation is not ideal. New tag should imply new image build. Otherwise, there is no point to publish/advertise a new tag for old stuff when the build steps were actually skipped.

This is not intentional and is a bug. I've logged dotnet/docker-tools#1102 for that. I've also logged #761 to better distinguish timestamp-based tags between staging and production.

I've kicked off a new staging build at https://dnceng.visualstudio.com/internal/_build/results?buildId=2084293&view=results that you should be able to use. Once finished, that should have a rebuilt version of the ubuntu-22.04-cross-arm-alpine-staging tag.

[michellemcdaniel]

We will be rolling out all of the changes in this repo to production tomorrow. We will make sure that the production tag for this image also gets respun.

[am11]

Thank you! The issue (dotnet/runtime native test build failure) is fixed in ubuntu-22.04-cross-arm-alpine-20230110192127-3fc5553. I will wait for the production rollout before updating the CI to floating 18.04 -> 22.04 tag.