ci: Add missing docker.io prefix for native tasks to CI_IMAGE_NAME_TAG #28330

1. 
   maflcko commented at 8:40 pm on August 23, 2023: member

   Currently, the CI system may pick the wrong (non-native) architecture due to the missing prefix.

   For example, assuming the CI_IMAGE_NAME_TAG is debian:bookworm and the user has previously pulled an s390x image:

   0$ podman run --rm 'docker.io/s390x/debian:bookworm' dpkg --print-architecture
   1exec /usr/bin/dpkg: exec format error
   

   Now, debian:bookworm will refer to the same image:

   0$ podman run --rm 'debian:bookworm' dpkg --print-architecture
   1exec /usr/bin/dpkg: exec format error
   

   However, docker.io/debian:bookworm works fine:

   0 $ podman run --rm 'docker.io/debian:bookworm' dpkg --print-architecture
   1arm64
   

2. ci: Add missing docker.io prefix to CI_IMAGE_NAME_TAG fab7f5c01d
3. 
   DrahtBot commented at 8:40 pm on August 23, 2023: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	hebasto

   If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

   Conflicts

   Reviewers, this pull request conflicts with the following ones:

   • #28211 (Bump python minimum version to 3.9 by MarcoFalke)
   • #28210 (build: Bump minimum supported Clang to clang-13 by MarcoFalke)

   If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

4. DrahtBot added the label Tests on Aug 23, 2023
5. 
   hebasto commented at 8:47 pm on August 23, 2023: member

   Does it make sense to be explicit about an architecture: docker.io/amd64/*?
6. 
   maflcko commented at 8:53 pm on August 23, 2023: member

   Does it make sense to be explicit about an architecture: docker.io/amd64/*?

   Why? and How? The architecture is native, not amd64.

7. 
   fanquake commented at 8:54 pm on August 23, 2023: member

   Does it make sense to be explicit about an architecture: docker.io/amd64/*?

   Wouldn’t that just defeat the point of this change?

8. 
   hebasto commented at 9:10 pm on August 23, 2023: member

   Before #21652, it was obvious that the fuzzers task is executed on a x86_64 platform. What is the way now to figure out the platform which runs this test?
9. 
   maflcko commented at 9:22 pm on August 23, 2023: member

   #21652 should be unrelated to any CI changes, because it didn’t touch the ./ci/ folder, only the cirrus yaml file.

   To find out the architecture, you can look at the logs.

   For example, the depends build directory has the HOST included. Or the build directory:

   0Making install in doc/man
   1make[1]: Entering directory '/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/doc/man'
   2make[2]: Entering directory '/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/doc/man'
   3make[2]: Nothing to be done for 'install-exec-am'.
   

10. 
    hebasto commented at 9:28 pm on August 23, 2023: member

    #21652 should be unrelated to any CI changes, because it didn’t touch the ./ci/ folder, only the cirrus yaml file.

    It is related because now it is possible to change worker architectures.

    To find out the architecture, you can look at the logs.

    For example, the depends build directory has the HOST included. Or the build directory:

    0Making install in doc/man
    1make[1]: Entering directory '/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/doc/man'
    2make[2]: Entering directory '/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/doc/man'
    3make[2]: Nothing to be done for 'install-exec-am'.
    

    Another run might use a worker with arm64 architecture (potentially), no?

11. 
    fanquake commented at 9:30 pm on August 23, 2023: member

    It is related because now it is possible to change worker architectures.

    The CI system was already being used on x86_64 and aarch64 long before that PR was merged. Hopefully we’ll even have a third architecture soon.

12. 
    hebasto commented at 9:33 pm on August 23, 2023: member

    It is related because now it is possible to change worker architectures.

    The CI system was already being used on x86_64 and aarch64 long before that PR was merged. Hopefully we’ll even have a third architecture soon.

    I mean, non-intentional change, for example, by an error.

13. 
    maflcko commented at 9:57 pm on August 23, 2023: member

    Another run might use a worker with arm64 architecture (potentially), no?

    Correct, but then that seems unrelated to this pull request here.

14. maflcko added this to the milestone 26.0 on Aug 24, 2023
15. 
    maflcko commented at 7:47 am on August 24, 2023: member

    To clarify, this pull request fixes a bug that exists since CI_IMAGE_NAME_TAG was introduced.
16. hebasto approved
17. 
    hebasto commented at 9:17 am on August 24, 2023: member

    ACK fab7f5c01d0b4be00bdd8922d3bf8bd1a27ba8fb.

    FWIW, on my machines the following strings work:

    • x86_64 hardware: 'docker.io/amd64/debian:bookworm'
    • arm64 hardware: 'docker.io/arm64v8/debian:bookworm'
18. fanquake merged this on Aug 24, 2023
19. fanquake closed this on Aug 24, 2023

    ---

20. maflcko deleted the branch on Aug 24, 2023
21. Frank-GER referenced this in commit 14488430d0 on Sep 8, 2023
22. bitcoin locked this on Aug 23, 2024

Contributors
maflcko DrahtBot hebasto fanquake

Labels
Tests

Milestone
26.0