|
1 | 1 | # Test C++ Build Actions |
2 | 2 |
|
3 | 3 | This is a test project that builds a small C++ program in a |
4 | | -Debian container on an Ubuntu GitHub runner, and directly on |
5 | | -a GitHub runner VM on Windows. |
6 | | - |
7 | | -A GitHub run number, which is the only variable that can be used |
8 | | -for build numbers, is restarted from `1` when the workflow file |
9 | | -is renamed. In addition to this, GitHub requires a workflow file |
10 | | -to exist in `main` in order to run a workflow on any branch. |
11 | | -This requires very careful workflow maintenance to match typical |
12 | | -pipelines in other CI environments, such as Azure DevOps. |
| 4 | +Debian container on an Ubuntu GitHub runner, and on a GitHub |
| 5 | +runner VM on Windows. |
| 6 | + |
| 7 | +Each workflow YAML file represents the app version of the upcoming |
| 8 | +release, which in this demo case are `3.2.0` and `2.8.1` versions. |
| 9 | + |
| 10 | +The `3.2.0` workflow file builds a candidate for the next dot-zero |
| 11 | +release, which would be branched into `3.2.x` for patch releases. |
| 12 | + |
| 13 | +The `2.8.1` workflow on the `main` branch is necessary because |
| 14 | +GitHub will not run a workflow file on a branch unless there is |
| 15 | +one on the `main` branch, so it's a dummy file that exists only |
| 16 | +for the purpose of surfacing the real workflow file on the `2.8.x` |
| 17 | +branch. |
| 18 | + |
| 19 | +Every time a release has been done, each respective workflow file |
| 20 | +must be renamed, so the build numbers would be restarted from `1` |
| 21 | +for the next target release. |
0 commit comments