@kevin @smooge @sgallagh

This variable name strikes me as confusing. Should it be fetch_cmd instead?

Shouldn't you catch the possible IOError here from the open() and write() calls?

I think this is just supposed to be {0}-playground, not {0}-playground-candidate. This is essentially a branch name, not a target name. I'm not sure where fedpkg gets the association between branch and koji target, but it does it. (See for example that https://src.fedoraproject.org/rpms/libuv/blob/1/f/package.cfg builds for f29+ and epel7 by branch name, not by Koji target).

Do we want to be creating it for epel7?

Do we want to be creating it for epel7?

sgallagh this was meant originally for epel7 but added to epel8 to get it there before we got so far down the garden lane as we are in epel7. [This has been on the drawing books in one form or another before epel7.]

Do we want to be creating it for epel7?

sgallagh this was meant originally for epel7 but added to epel8 to get it there before we got so far down the garden lane as we are in epel7. [This has been on the drawing books in one form or another before epel7.]

Right, but are we committing to implementing this in EPEL 7 right now? Because dropping this file into new epel7 branches will probably cause chaos if we aren't also producing epel7-playground branches...

Ah ok. yeah.. that would cause problems. This needs to be conditionalized for epel8 only for the time being.

This variable name strikes me as confusing. Should it be fetch_cmd instead?

I just named it as per the previous one's as there are push, commit, add....

I think this is just supposed to be {0}-playground, not {0}-playground-candidate. This is essentially a branch name, not a target name. I'm not sure where fedpkg gets the association between branch and koji target, but it does it. (See for example that https://src.fedoraproject.org/rpms/libuv/blob/1/f/package.cfg builds for f29+ and epel7 by branch name, not by Koji target).

It uses the target, as there is fxx build target as well. I can add epel8-playground target as well, but we need epel8-playground-candidate target as fedpkg uses that to identify which target it has to use if target is not provided in fedpkg build command.
https://pagure.io/fedpkg/blob/master/f/fedpkg/init.py#_179

Shouldn't you catch the possible IOError here from the open() and write() calls?

Fixed

Do we want to be creating it for epel7?

Fixed

Hmm, I think we probably ought to fail outright here, ideally filing the releng ticket automatically.

Continuing and letting the user proceed could lead to things getting out of sync pretty fast.

Hmm, I think we probably ought to fail outright here, ideally filing the releng ticket automatically.
Continuing and letting the user proceed could lead to things getting out of sync pretty fast.

I thought of it, ideally it should file the releng ticket and close the fedscm ticket that it was processing. I thought I will leave it for future changes as we are running short on time :disappointed: