@@ -52,6 +52,9 @@ This way, any CI change can be developed centrally in this repository and does n
### Adding new CI code
1. Implement your new CI code on a branch in this repo, e.g. `add-awesome-test` and ideally add a merge request for easier review.
- Note: your job needs to inherit the `before_script:` section from `.test-job-linux` or `.test-job-windows`, respectively. Without that, the job will not clone this repo (i.e. ivas-codec-ci) and the snippets will be missing. If your job does not make use of any snippet, in theory you can do without this, but as a general rule, you should inherit from one of these. If your job uses a before_script: section as well, see [guidelines section below](#some-guidelines-hints).
2. Test it by opening a branch in the respective ivas-* repository and changing IVAS_CODEC_CI_REF to your WIP branch, so the yaml there should read:
``` yaml
@@ -61,6 +64,21 @@ This way, any CI change can be developed centrally in this repository and does n
3. If your change affects multiple repos/branches, you might need to use multiple test branches
4. Once you are done and review is complete, merge `add-awesome-test` to `main` here. The test branches in the other repos are not needed and SHOULD NOT BE MERGED.
### Some guidelines/hints
- if your new job needs to overwrite the before_script: section, one can use this construct to still get the ci repo cloning:
```yaml
before_script:
-!reference[.test-job-linux,before_script]
-...
```
- use only one include section at the top of the main yml file to keep things clear, remember that later stuff overwrites earlier stuff
- in general prefer adding scripts here over using yaml anchors in a CI config file
- if your script shall modify some environment variable, you need to run it with `source` instead of calling it.
- the merge CI config in the ivas-* repos can be viewed in the pipeline editor under "full configuration" - this is especially useful when making changes which should not functionally affect the CI, then it is helpful to copy the full merged config with and without the changes and compare the files directly or as parsed yaml dict locally.
### Overwriting CI variables in the ivas-* repos' CI configs
Usually, everything should be done in the files here, but if there is the need to still overwrite some configuration/control CI variables - e.g. to switch off something temporarily or in a branch-specific manner - this should be done by in the variables: section at the top of the `.gitlab-ci.yml` file.
-`DISABLE_HRTF` - adds `-k not model` to `PYTEST_ADDOPTS` which skips the testcases with -hrtf in the selftest. Probably more for historic reasons.
-`BASOP_CI_SCRIPTS_BRANCH` - used to change the branch from which testscripts are pulled, see [here](https://forge.3gpp.org/rep/ivas-codec-pc/ivas-codec/-/wikis/Software-development/Test-Setup-For-BASOP-Code#how-do-i-check-that-my-new-testcase-does-work-for-basop) for more info.
### Some guidelines/hints
- use only one include section at the top of the main yml file to keep things clear, remember that later stuff overwrites earlier stuff
- in general prefer adding scripts here over using yaml anchors in a CI config file
- if your script shall modify some environment variable, you need to run it with `source` instead of calling it.
- the merge CI config in the ivas-* repos can be viewed in the pipeline editor under "full configuration" - this is especially useful when making changes which should not functionally affect the CI, then it is helpful to copy the full merged config with and without the changes and compare the files directly or as parsed yaml dict locally.
