- project tag:
- `veloren/veloren`: for the veloren repo only
- `veloren/*`: for projects thats are in the veloren namespace, e.g. usefull for smaller projects that dont have their own tag
- `*/*` for projects by 3rd parties, e.g. personal projects
- trusted tag:
- `owned`: The runner is hosted on veloren hardware
- `trusted`: The runner is hosted by a private person, trusted by the veloren devs
- NONE: if no special trust is given in a runner
- check/build tag:
- `check`: a job only performs a check and NO executable is build for users
- `build`: the job contains atleast 1 executable that can be run by users
- NONE: neither a check nor a executable is build, e.g. usefull for pages or meta jobs
- publish tag:
- `publish`: this job produces a artifact that is automatically pushed to users
- NONE: no artifact is pushed automatically to users
- pin tags:
- `benchmark`: pin a runner to a specific job for the cause of benchmarks
- `veloren/*:macos`: runs on a native macos runner ONLY, this needs to be a modified project tag, as otherwise also normal checks would run on this runner.
- NONE: no runner is pinned
"kaniko should only be run inside of a container, run with the --force flag if you are sure you want to continue" error
applied as described here https://github.com/GoogleContainerTools/kaniko/issues/1542
its also done in veloren-docker-cli: c8aa8ac857
We didnt had that problem in veloren repo until now.
This allow us to decouple our test-ci from the release-ci and is necessary for multiple release channels in the future.
E.g. we can run a master build without it directly beeing pushed to watchtower and airshipper (config setting requiered on airshipper)
Adjust Tags for server-cli
