#41 Add a way for developers to use the staging infrastructure to fedpkg
Closed: Fixed Opened by bowlofeggs.

Adding a --staging flag or a staging binary to fedpkg would make it a little bit easier to work on Fedora Infrastructure tools like Bodhi and Koji. This new feature would cause it to drive *.stg.fedoraproject.org deployments instead of the production deployments.

Thanks!


I propose to use separate subpackage which provides fedpkg-stage binary.

+1 to @pbabinca

Subpackage fedpkg-stage will provides a separate binary fedpkg-stage and well-configured fedpkg.conf containing *.stg.fedoraproject.org deployments.

I'm happy with either solution, thanks!

One thing to be careful about is the fedpkg update and fedpkg retire commands: we either need to make sure they point to staging infra or they should be disabled. It would be unfortunate if fedpkg-stage affected production systems.

The update command calls bodhi executable, I don't think bodhi 0.9.X has an option for switching environment.

The retire command talks to PkgDB through the python library.

@bowlofeggs Is bodhi command able to switch to bodhi.stg.fedoraproject.org?

For fedpkg retire, pkgdb2client.PkgDB.__init__ is

pkgdb2client.PkgDB(self, url='https://admin.fedoraproject.org/pkgdb/', insecure=False, login_callback=None, login_attempts=3)

we can pass https://admin.stg.fedoraproject.org/pkgdb/ to argument url.

For fedpkg update, we can pass https://bodhi.stg.fedoraproject.org/ to bodhi's option --bodhi-url. @bowlofeggs could you help to confirm whether this option can be used for this purpose? Thanks.

@cqi Bodhi 2 (in Rawhide and soon to be in EPEL 7) does have a --staging flag. I'm not particularly familiar with the bodhi 0.9 CLI, but that flag sounds reasonable. Honestly, we could also just disallow --staging with the bodhi 0.9 CLI (there's already code to check which bodhi version is being used.) I think that'd be the easiest path.

@cqi changed the status to Fixed

Metadata