Skip to content

Add CI that leverages bot:status last_build to see if all targets have (appropriately) been built for - #1564

Draft
casparvl wants to merge 9 commits into
EESSI:mainfrom
casparvl:check_build_status_overview_ci
Draft

casparvl wants to merge 9 commits into
EESSI:mainfrom
casparvl:check_build_status_overview_ci

Conversation

@casparvl

@casparvl casparvl commented Aug 10, 2026 •

Copy link
Copy Markdown
Collaborator

Add a CI that can check the 'bot:status last_build' output to see if it is complete in the sense that it supports all architectures, and all builds are done from the same software-layer commit.

TODO:

  • actually list the reference architectures it should check for
  • make sure it handles multi-architecture GPU builds correctly

…it is complete in the sense that it supports all architectures, and all builds are done from the same software-layer commit
casparvl pushed a commit to casparvl/software-layer that referenced this pull request Aug 10, 2026
@ocaisa

ocaisa commented Aug 23, 2026

Copy link
Copy Markdown
Member

In https://github.com/EESSI/software-layer/blob/main/.github/workflows/test-software.eessi.io.yml there's a maintained list of all the architectures and accelerators for each EESSI version. I think it makes sense to have a source of truth for that list (a yaml file?) and to also use it for this CI.

Caspar van Leeuwen and others added 3 commits October 5, 2026 14:26
…file

The list of supported CPU and accelerator targets per EESSI version was embedded
as env variables in test-software.eessi.io.yml. Move it to
.github/workflows/eessi_targets.json so it can be reused by other workflows and
scripts (e.g. a check on the bot's build status), without duplicating it.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Replace the placeholder SUPPORTED_TARGETS mapping with targets read from the
shared .github/workflows/eessi_targets.json (also used by
test-software.eessi.io.yml), so the list is defined only once.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@casparvl

casparvl commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

#1745 Single source of truth - still need to test the PR though.

@casparvl

casparvl commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Updated this PR so that it uses #1745 . We should merge #1745 first, then the diff in this current PR should shrink to the essential part.

Caspar van Leeuwen and others added 2 commits October 5, 2026 16:06
yq infers its output format from the input file extension, so reading a .json
file produced quoted JSON strings (e.g. "x86_64/amd/zen2"), which broke the
CPU target detection. jq -r prints raw strings.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…facts

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
@casparvl

casparvl commented Oct 5, 2026

Copy link
Copy Markdown
Collaborator Author

Status update: this still needs some final changes from #1745 to be merged into this branch. Then, we can leverage the single source of truth json file to check all the built targets.

TODO: I don't think this can check accelerator-builds yet, and related is that we should make the code aware of 'for:' values that contain multiple architectures.

Caspar van Leeuwen and others added 3 commits October 6, 2026 14:27
TOML is parseable from Python's standard library (tomllib, 3.11+) and from the
shell with yq, and unlike JSON it allows comments. yq is called with explicit
input/output formats (-p toml -o yaml) so the output is raw strings, rather
than relying on yq inferring the output format from the file extension.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants