GitHub action C/C++ workflows
| Name | Description |
|---|---|
| gh-pages-publish.yml | Publish API docs to GitHub Pages |
| gh-release.yml | Create a GitHub Release |
| unit-ci.yml | Build and run Unit tests (on Linux, Mac, and Windows) |
This project uses it's own workflows in order to test them (the C++ App/Lib is just a demo/example). Copy and paste one or more of the following files into your project .github/workflows directory and update parameters accordingly:
| Name | Description |
|---|---|
| ci.yml | Continuous Integration of an App/Lib |
| cd.yml | Continuous Deployment of an App/Lib with GitHub release |
The ci workflow invokes unit-ci to configure, build, and unit test. The ci workflow can be customized with docker commands to launch containers and run integration tests (Java Example).
The cd workflow invokes gh-release and optionally gh-pages-publish. The gh-release workflow uses the VERSION file to determine which tag to create. The cd workflow generally should monitor the VERSION file for changes to trigger the workflow.
The gh-pages-publish workflow creates docs on GitHub Pages. For example, the demo Lib docs are here: Doxygen API docs. The workflow creates a new directory in the gh-pages branch of your project for each release using the semver name and copies the auto generated API docs there. An index HTML with JavaScript can then use the GitHub API to lookup the directories in the branch and list them in the index. This means there is a one-time setup for each project where you need to commit and push the index.html, index.js, and .nojekyll files. The path to the docs are then obtained at https://jeffersonlab.github.io/project/ where project is your project name. Example setup commit - notice first line of index.js must be customized with project name.
This project includes a Hello World C++ app to demonstrate the workflow. Use the cxx-devcontainer to configure, build, and test:
cmake -S. -Bbuild
cmake --build build
ctest --test-dir build -C Debug -V
Workflows are versioned in semver just as with regular software, however, the GitHub Action workflows convention is to reference a major version number such that backwards compatible minor and patch updates are received automatically. This means a separate major tag such as v1 must be moved after each release. To move a major tag after a release execute (v1 shown):
git tag -f v1
git push --tags -f