One of the assumptions we're making as we go into the dist-git style tasks is that there will be git repositories available for the packages and that we won't need to do anything directly to create them or handle the ACLs.
This should still be true but we do need to make sure that we're coordinating with infra in order for any of that to happen.
This ticket is a duplicate of https://pagure.io/taskotron/libtaskotron/issue/339
Talked to @ralph today on IRC and it sounds like most of the stuff is in place or close to being in place. The remaining bits that we know of right now are:
checks/
pkgs01
! In #752#10237, @tflink wrote: * final determination of namespace's name (if checks/ is determined to be problematic)
+1 to 'checks/' from me.
add that namespace in pkgdb and create entries for all packages
We should consult with @pingou about this. We can likely write the script ourselves, but he may have a trick up his sleeve or be able to bang it out real quick like.
create the actual check repos on pkgs01
This should happen automatically in response to our creation of the entries in pkgdb. Adding them in pkgdb sends a fedmsg which triggers a script on pkgs01 to go and sync all the repos it should from pkgdb. It uses this script to do that: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/distgit/templates/pkgdb_sync_git_branches.py#n245 and that script is already namespace-aware, so.. it should (fingers crossed) "just work".
write a service to keep rpm repo and check repo in sync
This will require some brand new work. A little fedmsg Consumer plugin running somewhere could probably do it.. but it would be a "from scratch" project.
file ticket for rpkg/fedpkg to handle checkout of check repo when the rpm repo is cloned with fedpkg The implementation on this can wait for later, once we have the server-side bits in place
Agreed. It will sure be cool, though. :) We can even have the checks/ repos be live and even in use server side months before we start promoting them to the broader packager group with some rpkg/fedpkg convenience like this.
Some tracking tickets for parts of this work on the pkgdb2 repo:
Just to add a note here, the current namespace plan is to use rpm-checks/ as the namespace for rpm checks. Eventually, the plan is to have a dockerfiles-checks/ namespace as well which will contain checks for docker images which will happen later
rpm-checks/
dockerfiles-checks/
! In #752#10237, @tflink wrote: * file ticket for rpkg/fedpkg to handle checkout of check repo when the rpm repo is cloned with fedpkg
So, rpm dist-git and rpm-checks dist-git for a package foo will be two separate git repos, with automatically synced branch names (f22, f23, etc) and ACLs, right? How is fedpkg going to glue them together, using git submodules? Are we OK with some of the pain points git submodules bring? Or is it going to work in a different way?
rpm
rpm-checks
foo
f22
f23
As far as I know, they're completely separate repos and there's some stuff behind the scenes which puts the paths together to look like they're a single thing.
That's my understanding of what will happen though - I figure that it's safe enough to not pay too much attention to pkgdb so long as it behaves consistently and I can't think of any reason to think otherwise. From asking questions on the tickets above, it sounds like they're pretty much ready to go on getting check repos deployed - mostly waiting for the "go" from us before starting on the last tasks.
As far as I know, this is complete for both stg and production.
ACLs are identical to the rpms repo - anyone who has write access to the rpms repo will have write access to the rpms-checks repo and visa-versa. The thought process behind this is that someone writing checks could cause just about as much damage as someone changing the specfile once we start doing more build gating.
This can be changed in the future but it makes sense for now and also happens to be the easiest way forward :)
http://pkgs.fedoraproject.org/cgit/rpms-checks
Metadata Update from @tflink: - Issue tagged with: infrastructure
Login to comment on this ticket.