action #151675
closedcoordination #96596: [qe-core][CI] CI/CD and Coding style improvements
[qe-core] CI/CD gitlab forks should not deploy to OSD
0%
Description
When I fork a JobGroup repo, it's required to setup APIKEY / APISECRET variables in order to let the CI run the checks.
If I am an openQA admin, when I push to master on my fork, the CI/CD runs check and, when passed, deploys the result to OSD.
This risks to propagate any error I can make in my fork to the global environment and can be avoided by running the CI/CD for deployment only on one "source-of-truth" repository, with a protected master branch.
Updated by josegomezr about 1 year ago ยท Edited
GitLab does not support natively detection for Forks. It's invisible for the CI if the repo was the original or a fork.
However, a fork could be detected. Not the most pretty way but:
$CI_PROJECT_NAMESPACE says what's the Project Namespace (anything after gitlab.suse.de, anything before the actual repo name). See the docs.
something along the lines of:
rules:
- if: $CI_PROJECT_NAMESPACE == "%name of the main project namespace%"
should only schedule that pipeline job when it's on the main repo and not forks.
Updated by amanzini about 1 year ago
- Subject changed from [qe-core] CI/CD gitlab forks deploy to OSD to [qe-core] CI/CD gitlab forks should not deploy to OSD
Updated by amanzini 12 months ago
- Status changed from In Progress to Feedback
MR: https://gitlab.suse.de/qe-core/qa-sle-functional-userspace/-/merge_requests/196
unfortunately we cannot use the newer rules: syntax, because there are already some only: conditions and they cannot be mixed.
As the only: keyword is deprecated, ideally we should rewrite the whole CI to use rules: keyword.
As proposal for a new ticket, when re-engineering the CI also make it deploy only the changed schedule[s] and not reuse .deploy-template: for both testing and deployment :)