You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
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.
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
The text was updated successfully, but these errors were encountered: