#43 Migrate git repos to Pagure
Closed: Fixed Opened by adamwill.

We should move the openqa_fedora and openqa_fedora_tools git repos to Pagure (under the fedora-qa project). It's both nicer and freer than bitbucket, and it'd be nice to have as many QA repos as possible in one place.

We don't have to move issue tracking or the PR / 'diff' workflow if we don't want to, those can both be disabled in Pagure.

Checklist:

Create Pagure repos (under fedora-qa namespace)

Push current state of bitbucket repos to them

Give fedora-qa group write access to repos

Disable PRs and issues (unless we decide to use Pagure instead of Phab for that)

Update ansible plays

Update wiki references

Check for fedorahosted links in projects' code, update them

Update internal and external (i.e. SUSE's docs) documentation

Ensure docs explain PRs / issues go to Phab (unless we switch)

Update Phab configuration

Replace fedorahosted repo's contents with a MOVED notice


This ticket is a duplicate of https://pagure.io/fedora-qa/fedora_openqa/issue/46

So I had a thought on this: do we want to take this opportunity to rename the repos, and possibly split up openqa_fedora_tools?

I kind of hate both names. I'd suggest we rename openqa_fedora to os-autoinst-distri-fedora to follow the convention established by SUSE's names for equivalent repos.

For openqa_fedora_tools, I don't like how it has all sorts of things awkwardly smooshed together (and you have to go through like three levels to get to the scheduler code). I was thinking we could at least split the scheduler and createhdds into into their own repositories. (We could also look at consistency in the scheduler naming...it's in a directory called 'scheduler', the name in setup.py is 'fedora-openqa', and the library is called 'fedora_openqa_schedule'...)

That leaves us with a few little bits and pieces: the 'how to install' documentation, the docker bits, and the testpackages script that's used to create the fake package for the update tests.

WDYT? Ack, nack, patch?

I agree with renaming openqa_fedora to os-autoinst-distri-fedora SUSE's style, but we should probably create pagure.io/fedora-qa/openqa_fedora and redirect it to the new name.

As with openqa_fedora_tools, I would move docker stuff into new repository, update upstream and then get rid of it. Scheduler stuff deserves it's own repository (and proper naming) as does createhdds. Then maybe move documentation, install guides and viewneedles (I use it from time to time, but if you want to delete it, feel free to do it) together with testpackages into third repository?

So I've done openqa_fedora:

https://pagure.io/fedora-qa/os-autoinst-distri-fedora

I pushed everything from develop to master and dropped the master branch, since we weren't really doing a 'periodic merge from develop to master' thing anyway, we were just completely ignoring master. I think I've updated all the appropriate configuration bits in Phabricator and .arcconfig, and I've updated the Ansible plays so the production servers will now work from that repository.

If we want to switch to Pagure for issues and PRs, we should ideally find a way to export the existing ones (at least open ones) from Phabricator to Pagure. I'll have to talk to tflink about that. For now, I just disabled PRs and issues on Pagure and added a note to the README that they're still in Phabricator for now.

I think that moving code reviews to Pagure would open us to external contributors. But question is, how Pagure handles code reviews? Would be all done using fork and pull requests? Even by us? We can try it with something unimportant (docs or whatever) and see how it works :-).

AFAIK it's all pull requests, yeah. Though you do still have direct push access to the repo so you can land changes yourself (not via the web UI) once reviewed, I think.

Yes, I was thinking whether simple fork & pull-request will cover all our needs (it's still more basic than Phabricator), but I would definitely try.

Update: I've now moved the scheduler/reporter library/CLI (now called fedora_openqa) and createhdds out of openqa_fedora_tools:

  • https://pagure.io/fedora-qa/fedora_openqa
  • https://pagure.io/fedora-qa/createhdds

I renamed the Phab projects so they now match the new repo names (we have os-autoinst-distri-fedora and fedora_openqa projects now). I didn't create a project for createhdds, I figure we can just use Pagure issues / PRs for it.

There's still some bits left in the rump openqa_fedora_tools, I will do my best to come up with a sensible plan for moving them all out. I think we can lose viewneedles, move the package creation script into qa-misc, and try to move the docs bits into the wiki and/or upstream openQA documentation.

This is almost complete now, the only bit remaining in openqa_fedora_tools is the Docker stuff. That only needs re-updating and sending upstream. @jsedlak said he'd take care of that.

I hadn't sent it upstream because their Dockerfiles diverged from ours (looks like they are using it for testing on Travis). I figured out that dockerized openQA on Fedora might be still useful to us from time to time, so I've simplified it as much as possible - removed all those scripts for setting different auth methods (it's meant for testing/development only, so why not use fake auth), got rid of complicated data handling using data volume container and updated it to newest Fedora, created [[ https://pagure.io/fedora-qa/openqa_docker | its own repo on Pagure ]] and removed Docker stuff from repo on bitbucket, so I think that we may close this ticket as resolved.

Sounds great! We might need to do some documentation updates, in that case, though, to point to the new repo (I had changed our docs which mention Docker to point upstream on the assumption we were gonna upstream the changes). We may also need to send a PR for upstream docs to say 'if you want to run a containerized openQA for testing on Fedora, go here', or so.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/issues/43

Please continue any further discussion there.

Metadata