Hello
EDIT: This does not really require Linux support (#466): We can build the Windows version in CI now already.
Using GitHub actions for Continuous Integration (CI) on GitHub has become more or less the industry standard. From my personal experience, there are many advantages of this approach. The CI is directly embedded into the GitHub repo, and GitHub is very generous with providing resources to run your CI for free.
My plan would be to add a simple CI workflow which compiles both debug and release for Windows and Linux. On Linux, we can use gcc and clang, and for Windows, we can use MSVC compiler (and even clang for Windows). You can mark GitHub workflows as required, so pull requests are only merged if builds pass. This is very convenient.
In addition, I also would like to add a separate setup for static code analysis using clang-tidy. I would not recommend to mark this as required though, because it would certainly require a lot of cleanup in the existing code. Clang-tidy can be very detailed, and not ever warning makes sense for the project. Still, it is nice to have a look at the static code analysis from time to time, especially when new pull requests come in. Although it is a lot of work, I have managed to get to (almost) zero warnings in some of my projects, which resulted in very high code quality (although it was a lot of work and in some parts probably not worth it).
Also, I would recommend to store the results of the builds as artefacts in a nightly build. This allows you and others to download latest builds, and to run them directly.
While all of this sounds like a lot of code, maintaining a CI using GitHub actions has become very easy, and it's only a small number of GitHub workflow files to add. To see all of this in actions, check out our code here for example:
https://github.com/inexorgame/vulkan-renderer/tree/main/.github/workflows
https://github.com/inexorgame/vulkan-renderer/actions/runs/13732338625/job/38411491197
Some more notes:
- I think it's important to check if both debug and release build work. I have experienced several code bases where release is totally broken because it is never really tested for.
- You could also migrate to https://github.com/google/googletest and integrate tests into the CI as well. I am personally not yet doing this either, because I also don't have a solution yet how to run code which requires a gpu in CI. There seem to be some commercial services for this, but I don't think GitHub offers this for free yet. It would be a great thing to suggest to Microsoft.
- Documentation could also be built in the CI. I can also recommend this a lot.
best regards
Johannes
Hello
EDIT: This does not really require Linux support (#466): We can build the Windows version in CI now already.
Using GitHub actions for Continuous Integration (CI) on GitHub has become more or less the industry standard. From my personal experience, there are many advantages of this approach. The CI is directly embedded into the GitHub repo, and GitHub is very generous with providing resources to run your CI for free.
My plan would be to add a simple CI workflow which compiles both debug and release for Windows and Linux. On Linux, we can use gcc and clang, and for Windows, we can use MSVC compiler (and even clang for Windows). You can mark GitHub workflows as required, so pull requests are only merged if builds pass. This is very convenient.
In addition, I also would like to add a separate setup for static code analysis using clang-tidy. I would not recommend to mark this as required though, because it would certainly require a lot of cleanup in the existing code. Clang-tidy can be very detailed, and not ever warning makes sense for the project. Still, it is nice to have a look at the static code analysis from time to time, especially when new pull requests come in. Although it is a lot of work, I have managed to get to (almost) zero warnings in some of my projects, which resulted in very high code quality (although it was a lot of work and in some parts probably not worth it).
Also, I would recommend to store the results of the builds as artefacts in a nightly build. This allows you and others to download latest builds, and to run them directly.
While all of this sounds like a lot of code, maintaining a CI using GitHub actions has become very easy, and it's only a small number of GitHub workflow files to add. To see all of this in actions, check out our code here for example:
https://github.com/inexorgame/vulkan-renderer/tree/main/.github/workflows
https://github.com/inexorgame/vulkan-renderer/actions/runs/13732338625/job/38411491197
Some more notes:
best regards
Johannes