View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0008992 | GNUnet | other | public | 2024-06-29 11:41 | 2024-06-29 15:47 |
Reporter | nullptrderef | Assigned To | nullptrderef | ||
Priority | normal | Severity | minor | Reproducibility | N/A |
Status | assigned | Resolution | open | ||
Platform | RISC-V, QEMU | OS | N/A | OS Version | N/A |
Product Version | Git master | ||||
Summary | 0008992: Risc-V CI builds failing | ||||
Description | The GNUNet Risc-V CI builds are failing. Edit: See 1st comment | ||||
Additional Information | Failing since https://buildbot.taler.net/#/builders/18/builds/1034 | ||||
Tags | No tags attached. | ||||
|
Issue appears to be: CI system ignores ci.sh and jumps directly to building Containerfile & running the job directly. |
|
Copied from messages to @dvn: In Taler Buildbot, for GNUNet, the CI system directly builds the Containerfile regardless of contrib/ci/ci.sh, then directly invokes contrib/ci/jobs/<job> rather than contrib/ci/ci.sh <job>. This results in RISC-V builds not working, as they rely on a different FROM than everything else, due to Bookworm not having RISC-V builds. Is there any way we can make CI either run ci.sh, or check for a contrib/ci/[architecture].Containerfile and only fallback to the normal Containerfile if that doesn't exist? |
|
Understandable confusion. Actually, `ci.sh` is supposed to be only a helper script for developers to run the CI jobs locally. See https://docs.taler.net/design-documents/044-ci-system.html#running-ci-locally So the expected behavior of the CI system is to run the jobs directly. Now, to address the problem at hand, I think the latter solution you propose is a good idea. If there is a file with a name that matches *.Containerfile in a job directory, then that will be used before the toplevel ("normal") Containerfile. I can implement this in the buildbot. |
Date Modified | Username | Field | Change |
---|---|---|---|
2024-06-29 11:41 | nullptrderef | New Issue | |
2024-06-29 11:41 | nullptrderef | Assigned To | => nullptrderef |
2024-06-29 11:41 | nullptrderef | Status | new => assigned |
2024-06-29 11:46 | nullptrderef | Additional Information Updated | |
2024-06-29 12:01 | nullptrderef | Note Added: 0022767 | |
2024-06-29 12:02 | nullptrderef | Description Updated | |
2024-06-29 12:04 | nullptrderef | Note Added: 0022768 | |
2024-06-29 15:47 | dvn | Note Added: 0022769 |