Correct runner linux package archs

As part of the pulp migration in a discussion with @balasankarc, we noted the the architectures for which we currently build deb and rpm packages were not quite right. Specifically.

For rpm distros/packages:

  • arm64 is not used/common. aarch64 is the preferred arch.
  • arm is similarly not used. armhfp is the preferred arch.
  • loongarch64 is the preferred name, not loong64.
  • armhfp is similary preferred over to armhf.
  • x86_64 is preferred over amd64.

For deb distros/packages:

  • aarch64 is not used/common. arm64 is the preferred arch.
  • armel legacy and effectively redundant/unused. armhf the preferred arch now.
  • i386 is preferred over i686 in deb-land, while the opposite is true in rpm-land.

This MR adjust the runner-supported arches to be in line with the above. This does mean that we now create and thus publish packages for fewer architectures than we did previously, sort of. I say sort of because some of the arches were not actually downloadadble by tools like apt-get, dnf, yum, because either the tools of repository did not recognize the arch, or because the exact same package was downloadable under a different equivalent arch (e.g. packages for arm, armhf, and armhl arches contained the exact same binary). This is more of a removal of redundancy than elimination of options.

One apparent impact of this change is the output of the mage package:archs command:

Before:

> mage package:archs deb
amd64 i686 aarch64 arm64 armel armhf riscv64 loong64 s390x ppc64le

> mage package:archs rpm
x86_64 i686 aarch64 arm64 arm armhf riscv64 loongarch64 s390x ppc64le

After:

> mage package:archs deb
amd64 i386 arm64 armhf riscv64 loong64 s390x ppc64le

> mage package:archs rpm
x86_64 i686 aarch64 armhfp riscv64 loongarch64 s390x ppc64le

Another consequence of this change is that the rpm/deb package filenames now match the package architecture, whereas before they did not always match (e.g. the file was named gitlab-runner_amd64.rpm but the package arch was x86_64). The package architectured can be queried via dpkg-deb -I <file>.deb | grep Architecture and rpm -qi <file>.rpm | grep Architecture for deb and rpm package files respectively.

Why do we need all this anyway!? In addition to the inherent advantage of pruning irrelevant package archs, this also means we upload fewer packages, which will slightly speed up releases. Also, for rpm repos in pulp, the package architecture is encoded in the repository name. For example, the command to upload an rpm package to pulp is:

pulp rpm content upload --file out/rpm/gitlab-runner_amd64.rpm --repository runner-unstable-el-9-x86_64

Note the x86_64 suffix on the --repository argument. This will be different for each arch. The issue with this is that, given an rpm package, we need it's (correct) arch to assemble the above command invocation, and if the package filename has the "wrong" arch name, we have to resort to the above rpm -qi command to get it's arch. It's all much easier if the file just has the right arch name.

Testing

The CI jobs that create packages should continue to pass, but should now produce these packages:

out/deb/gitlab-runner-helper-images.deb
out/deb/gitlab-runner_amd64.deb
out/deb/gitlab-runner_arm64.deb
out/deb/gitlab-runner_armhf.deb
out/deb/gitlab-runner_i386.deb
out/deb/gitlab-runner_loong64.deb
out/deb/gitlab-runner_ppc64el.deb
out/deb/gitlab-runner_riscv64.deb
out/deb/gitlab-runner_s390x.deb

out/rpm/gitlab-runner-helper-images.rpm
out/rpm/gitlab-runner_aarch64.rpm
out/rpm/gitlab-runner_armhfp.rpm
out/rpm/gitlab-runner_i686.rpm
out/rpm/gitlab-runner_loongarch64.rpm
out/rpm/gitlab-runner_ppc64le.rpm
out/rpm/gitlab-runner_riscv64.rpm
out/rpm/gitlab-runner_s390x.rpm
out/rpm/gitlab-runner_x86_64-fips.rpm
out/rpm/gitlab-runner_x86_64.rpm

Also, the CI job that publishes these packages to packagecloud should continue to pass, and upload the above packages to PC. That job only runs in protected branches, so I'll try making this MR's branch protected.

when uploading rpm packages to pulp, the rpm repo

Edited by Axel von Bertoldi

Merge request reports

Loading