Refactor GitHub action workflow for nightly release
Is your feature request related to a problem?
The current GitHub action workflow for nightly release works only by using a hack. I currently wait for the msvc static code analysis (Release) to finish because I know this step takes the most time!
Description
In the nightly release, I want to include:
- the binaries from the build for all os and all compilers
- The static code analysis (SCA) reports from clang-tidy, cppcheck, and msvc code analysis (both debug and release)
- The documentation build
This creates the following problem:
In GitHub actions, we can't have multiple conditions to trigger another workflow (from what I understand). This means we can't tell GitHub actions to run the nightly workflow only after the following workflows have all completed: build, static code analysis, and building documentation.
There seem to be several way to fix this, but I am not happy with either one of them.
- Option A: Create a nightly release based on scheduling around a certain time at night, let's say 4:00 am
- Option B: Create 3 separate workflows which are individually triggered if the build, building docs, or static code analysis is finished. Each "follow-up" workflow then edits the nightly release.
- Option C: Maybe we can link workflows? But again: We need to wait for all 3 to finish before creating the release!
Alternatives
Keep everything as it is
Affected Code
The GitHub action workflow
Operating System
Additional Context
Speaking of, I just encountered the first case of the static code analysis finishing before the code build. It really depends on how the runners are started by GitHub.
Speaking of, I just encountered the first case of the static code analysis finishing before the code build. It really depends on how the runners are started by GitHub.
In this case, we would have to run the release script manually again after all builds have finished after merging. This is not a big problem, since the nightly release generation script is quite fast. This is also an option to solve this entire problem manually.
Another option would be to chain the execution of Github workflows, like 1) build code, 2) build docs, 3) static code analysis, 4) create nightly release. This would work and it would ensure correct order, but we would lose parallelization. It would take much longer for the overall CI to finish.
You can mark certain steps as failable. If that helps. And maybe: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
You can mark certain steps as failable. If that helps. And maybe: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
The problem is that we need to trigger the automatic generation of the nightly release after all workflows have finished (build code, build docs, static code analysis). All 3 of those workflows produce output (build, docs, output from sca will also be uploaded now!). There is no effective way to wait in one workflow run for 3 other workflow runs to finish, at least to the best of my knowledge.
Another option would be that every workflow uploads its results to the latst nightly release once the workflow itself is finished. For the moment, our current workflow runs correctly though.
Another thing we should keep an eye on: The scan-build static code analysis sometimes fails because it seems to be unable to download Vulkan SDK? Idk what is going on there. Maybe we exceed some GitHub actions cache.
I think the best solution will be option B: We can make a new release once all of the builds are succeeding, then each of the other workflows (static analysis and docs) can add their artifacts to the latest nightly release once the workflows finish. This way, we have a short time where not all artifacts are available, but this is still better than having some artifacts not available because it is currently the static analysis which determines when to create the nightly release.