Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use GitHub actions for continuous integration #467

Open
IAmNotHanni opened this issue Mar 13, 2025 · 1 comment
Open

Use GitHub actions for continuous integration #467

IAmNotHanni opened this issue Mar 13, 2025 · 1 comment

Comments

@IAmNotHanni
Copy link
Contributor

IAmNotHanni commented Mar 13, 2025

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

@adam-sawicki-a
Copy link
Contributor

Hello

Thank you for this effort and I'm sorry for my delayed response.

I agree it would be good to test the compilation on Windows and Linux, Debug and Release configuration, with multiple compilers. On Windows, Visual Studio should be the primary one.

I also agree it may be a good idea to run clang-tidy, as long as it is not required to be clean of any messages reported.

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

No branches or pull requests

2 participants