Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge #6400: ci: refactor GitHub Actions CI to use reusable workflows…
…, respect `DEP_OPTS`, build multiprocess depends with Clang a976777 ci: build multiprocess depends with Clang, use in tsan builds (Kittywhiskers Van Gogh) c9708b7 ci: drop `DEBUG=1` to try and avoid exhausting Actions runner storage (Kittywhiskers Van Gogh) 68ddcdb ci: add nowallet depends, multiprocess depends and build variant (Kittywhiskers Van Gogh) c83efa8 ci: start respecting `DEP_OPTS`, unify with GitLab (Kittywhiskers Van Gogh) f41efa4 ci: source target triple from `matrix.sh` (Kittywhiskers Van Gogh) a7d11f8 ci: pass the whole key instead of trying to reconstruct it (Kittywhiskers Van Gogh) fa0dc5e ci: switch from matrices to manual definition (Kittywhiskers Van Gogh) 1f58365 ci: split out building src and running unit tests into reusable workflow (Kittywhiskers Van Gogh) 0d8f2ef ci: split out building depends into reusable workflow (Kittywhiskers Van Gogh) 41d9867 ci: split out building CI container into reusable workflow (Kittywhiskers Van Gogh) Pull request description: ## Additional Information * Depends on #6406 * We have to move away from matrices as matrix-based job variants cannot be _individually_ accepted as dependencies for the next job, only the whole job can. This means that the next job cannot start until the last matrix variant of the dependency succeeds. This also means that if any variant fails in the dependency job fails, every job forward also ceases. The approach taken in this PR is a mirror of the current implementation on GitLab CI, defining a reusable unit ("templates" in GitLab parlance, "reusable workflows" in GitHub) and defining each variant, now coming with a unique job name that can be specified as dependencies for the job. This should reduce stalling from slower variants. * `DEBUG=1` had to be dropped as it resulted in the runners running out of free space ([build](https://github.com/kwvg/dash/actions/runs/13240781702/job/36956549082#step:7:3137)). Despite this only being a problem with GitHub Actions, this change also affects GitLab CI as we now read `DEP_OPTS` from matrix scripts instead of the CI configuration file. * We are reading from the matrix script to ensure that both CI instances build with the same configuration and to reduce code complexity arising from passing around details between different workflows. * Potential `DEP_OPTS` conflicts (as discussed [here](#6400 (comment))) have been circumvented by passing the expected cache key wholesale instead of reconstructing it ([commit](1a67a02)). We do still expect that `HOST` will be defined correctly in the matrix script (the `HOST` of both depends and build should match) but as differing `HOST`s are incompatible regardless, this shouldn't be a problem. * To make sure we can `output` `cache-primary-key`, the depends cache step was split in two so that the output from the `restore` action is can be exported from the workflow ([source](https://github.com/dashpay/dash/blob/1a67a026de39017a544cfb7852390de88864deec/.github/workflows/build-depends.yml#L21)). * As `DEP_OPTS` is a new parameter that _could_ require rebuilding depends, it needs to be incorporated into the cache key. The most straightforward way to do it is to append the hash of the file that defines `DEP_OPTS` to the cache key. Unfortunately, this requires us to hardcode the name of the individual file (e.g., `00_setup_env_native_qt5.sh` for `linux64`) as `matrix.sh` is just a dispatcher and comes with the drawback that _any_ change to the script could result in a cache miss due to a changed hash. This has been mitigated by hashing the build variant name and the environment variables that influence the build ([source](https://github.com/dashpay/dash/blob/cfdd2c678819de04cd867740a0f9a9f729c891bb/.github/workflows/build-depends.yml#L41-L43)). * `head` trims the output of `sha256sum` to 64 characters, the hash itself isn't being trimmed but everything after it is (trailing hyphen and newline). This is also why `echo -n` is used in some places, to avoid newline addition resulting in a different hash value. * Currently there doesn't seem to be a way to have full control on a reusable workflow's name, it remains a fixed "[caller name] / [reusable workflow name]" and attempting to remove the name altogether will still result in a trailing slash ([source](https://stackoverflow.com/questions/79241079/how-to-control-the-name-of-a-reusable-workflow)). ## Breaking Changes None expected. ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: UdjinM6: ACK a976777 PastaPastaPasta: utACK a976777 Tree-SHA512: 34436d7e887bc12b89cced49c17ec83405c074dd01eddce8a425c4edc67e7fc6005d1ddc36eef0c8c4888d65a5e6c99ae4bce1726ebfa07d8b7a07063fed4f40
- Loading branch information