Closed Finii closed 1 year ago
For this to work additional preparations are needed on the Github repo:
.gitlab-ci.yml
is moved (unchanged) to .gitlab-ci/build.yml
The diff does not reflect that.
There are some downsides (with that abstruse one-pipeline-only approach of gitlab).
The child pipelines we trigger are not so very visible. So on ordinary pushes the main pipeline is triggered and succeeds. Because the only thing it does is trigger the normal build-test pipeline. So we get a green cicle. Always.
If the tests succeeded needs digging deeper into the child pipeline.
Anyhow, I think this is acceptable, because we do not develop on Gitlab anymore.
Apparently no complaints about the negative side-effects ;-)
So I will set this up now, we can roll it back any time ;-D
This is how it looks now:
There is only one stage visible on the Pipelines
list.
Click on the job number to see more details.
You need to expand the downstream to see to 'normal' details.
The sync job is triggered once a day (cron 0 22 * * *
in UTC)
CICD has the access token via hidden variable:
And the token is actually here:
The botton in the right is 'revoke'.
You can sync anytime, by pushing 'play'
This force-pushes everything to Gitlab... all branches, tags, etc pp
See https://sourcelevel.io/blog/how-to-properly-mirror-a-git-repository
We would need to clone ourselves anyhow, because the Gitlab repo version that is checked out by default via CI process is (for some reason) not valid for pushes. https://www.benjaminrancourt.ca/how-to-push-to-a-git-repository-from-a-gitlab-ci-pipeline/
Skip-ci push option: https://docs.gitlab.com/ee/user/project/push_options.html
[why] While development takes place on Github some stuff will still be handled by the internal Gitlab repository (for example the Doocs release).
Unfortunately the automatic mirroring on Desy's Gitlab instance works only in
push
and not inpull
direction. You would have to pay for that simple switch.[how] Use a CI pipeline with a 'cron' trigger to automatically mirror the repo.
The problem arises that Gitlab does allow only for one workflow (called pipeline). To overcome that and properly disentangle the two workflows (i.e. 'build' and 'sync') a new pipeline is created.
That pipeline (mind: Gitlab has only one pipeline) decides if this trigger shall be a sync or a build trigger. It triggers the secondary (child) pipeline accoringly.
So: Put existing pipeline in subdir. Put sync pipeline in subdir. Replace existing pipeline with simple one that triggers the right child.
The desicion is taken by the variable
GIT_SYNC
. Create a Schedule that sets that variable to1
. Normal pull requests etc will not have set that variable.Some other prerequisites are needed to push to Gitlab. That is described in the workflow ... aeh pipeline file.
Pushing is done with
ci:skip
set. Maybe we want that, maybe not. At the moment we do not detect if there have really been any changes or not. Room for improvement.