vulkan-renderer icon indicating copy to clipboard operation
vulkan-renderer copied to clipboard

Refactor GitHub action workflow for nightly release

Open IAmNotHanni opened this issue 4 months ago • 8 comments

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:

  1. the binaries from the build for all os and all compilers
  2. The static code analysis (SCA) reports from clang-tidy, cppcheck, and msvc code analysis (both debug and release)
  3. The documentation build
Image

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

IAmNotHanni avatar Oct 05 '25 00:10 IAmNotHanni

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.

IAmNotHanni avatar Oct 05 '25 01:10 IAmNotHanni

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.

IAmNotHanni avatar Oct 05 '25 01:10 IAmNotHanni

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.

IAmNotHanni avatar Oct 06 '25 18:10 IAmNotHanni

You can mark certain steps as failable. If that helps. And maybe: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows

IceflowRE avatar Oct 08 '25 14:10 IceflowRE

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.

IAmNotHanni avatar Oct 08 '25 18:10 IAmNotHanni

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.

IAmNotHanni avatar Oct 11 '25 13:10 IAmNotHanni

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.

IAmNotHanni avatar Oct 28 '25 20:10 IAmNotHanni

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.

IAmNotHanni avatar Oct 28 '25 20:10 IAmNotHanni