@mohanboddu @kevin @pingou are you fine with editTag rules as defined here for Fedora production instance or you would like to see more restrictions in place? If so, which ones?

I'm -1 to overriding existing Koji APIs. I'd prefer to create new API endpoint if required.

• isn't this going to break rpkg that is calling this endpoint?

That would mean, you will duplicate editTag cmdline entirely. And no, that is not going to break rpkg or anything.

And no, that is not going to break rpkg or anything.

How is it not if you remove an endpoint that is being used?

You don't remove it, you override it with additional check. As you can see in the code, if tag is not a side tag and owner of it is not the user, it falls back to the original call to koji hub. Otherwise it uses koji-hub internal function to edit tag without checking for permission.

Yep, it is a wrapper around koji's endpoint. Only possible problem can appear if koji will change its internal handling of that call - but it is a problem of many plugins. So, I don't see much harm in this.

That is not the only problem - overridden editTag2 bypasses normal policy/permission checks. I would prefer implementing more flexible tag policy in Koji, or creating a dedicated API endpoint.

You don't remove it, you override it

Ah, sorry I had missed the createTag was still present lower down in the PR.

While I agree that it would be nice to have it in koji, it will not be in 1.19 for sure and this is needed for us to be able to build Rust packages without modularity in stable releases.

Once it is available in Koji, we can rework this, but for now I would like to have this as it is.

Can you describe this new workflow you are working toward and how this is needed please?

Is this going to change any of the functionality that the rawhide gating team has been using/testing?

No, it is not related to what gating team is working on.

The workflow is: create side tag, change rpm.macro.dist to sidetag name, set some other macro which makes builds to not run tests and skip actual build stage, build all crates from specific commits (that's why I need to edit dist macro, otherwise we won't be able to build them due to NVR uniqueness), unset dist macro and build application RPM. Then untag crates, submit bodhi update and hope that side tag will be removed automatically.

ok. Do the rawhide gating folks see any issues with that? Gating should only test the actual final package(s) in the tag when it's merged right?

Gating should only test the actual final package(s) in the tag when it's merged right?

No the packages are tested before the tag is merged, so when they are still on the side.

change rpm.macro.dist to sidetag name,

This is not going to happen for every side-tag, right?
Otherwise I think it may break rawhide gating

This is not going to happen for every side-tag, right?
Otherwise I think it may break rawhide gating

Only for side tags where Rust packages are built. But this should not be a concern since MBS overrides %dist to random thing anyway. And it is part of the Release tag in RPM. So nothing overcomplicated.