action #90164
closedcoordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes
coordination #43934: [epic] Manage o3 infrastructure with salt again
Make gitlab.suse.de/openqa/salt-states-openqa public
0%
Description
Motivation¶
To be able to use the salt recipes for o3 as well as provide it as a solution to manage any openQA infrastructure we decided to make gitlab.suse.de/openqa/salt-states-openqa public, e.g. put it on github within github.com/os-autoinst/
Acceptance criteria¶
- AC1: gitlab.suse.de/openqa/salt-states-openqa is available on a public, non-personal git repository
- AC2: SUSE QE Tools team member have read-write access to the repository
- AC3: Changes in the repo are still automatically applied within the OSD infrastructure
Suggestions¶
- Research about best practices to move from internal gitlab repo to external github/gitlab
- Copy gitlab.suse.de/openqa/salt-states-openqa to github, e.g. in https://github.com/os-autoinst scope, and create back-mirror into salt-states repo or get rid of it completely
Updated by okurz over 3 years ago
- Status changed from Workable to In Progress
- Assignee set to okurz
https://rtcamp.com/blog/gitlab-to-github-migration/ mentions a script solution to move from gitlab to github which mostly concerns transferring issues and such. As we only use the git repo itself plus CI but no issues or wiki we do not need that.
https://jsramblings.com/automatically-sync-gitlab-mirrored-repository-on-every-push-to-github/ explains how gitlab repositories can be automatically synced with github repos. Of course this – same as all other solutions I found except for polling – need access to the gitlab server from github so that github can trigger actions within gitlab. But given that we also pull test code by cron job every minute in https://gitlab.suse.de/openqa/salt-states-openqa/-/blob/master/etc/master/cron.d/SLES.CRON#L5 I don't see a problem with that.
Created
https://gitlab.suse.de/openqa/salt-states-openqa/-/merge_requests/471
to replace hardcoded mentions of openqa.suse.de with jinja variables.
Updated by openqa_review over 3 years ago
- Due date set to 2021-04-17
Setting due date based on mean cycle time of SUSE QE Tools
Updated by okurz over 3 years ago
- Status changed from In Progress to Feedback
waiting for MR feedback
Updated by okurz over 3 years ago
- Status changed from Feedback to In Progress
Followed https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#setting-up-a-push-mirror-from-gitlab-to-github to sync https://gitlab.suse.de/okurz/test-sync/ with https://github.com/okurz/test-sync . This pushed https://github.com/okurz/test-sync/commit/f9eb6a7d23e8f020f01b6ca91dad65b957c38312 , so far so good. Now about the other direction. Pulling from github is a "premium" feature for gitlab: https://docs.gitlab.com/ee/user/project/repository/repository_mirroring.html#pulling-from-a-remote-repository so I am thinking of a gitlab CI job to pull periodically, maybe as often as every 5 minutes or even every minute. For production use I would prefer to use a non-personal email-adress.
I created a new github account "openqa-git-sync", created a new github project and invited that user as a member, created a personal token within that user account and setup mirroring in https://gitlab.suse.de/openqa/salt-states-openqa/-/settings/repository#js-push-remote-settings with that token to https://github.com/os-autoinst/salt-states-openqa/
Updated by okurz over 3 years ago
- Status changed from In Progress to Resolved
password stored in https://gitlab.suse.de/openqa/scripts/-/blob/master/password#L15
split out the sync from github.com to gitlab.suse.de into #91332
Updated by okurz over 3 years ago
- Tracker changed from coordination to action
- Due date deleted (
2021-04-17)