Bug 1455249

This is rather a problem of Github not being able to trigger webhook purely only on tag events. I would very much recommend Gitlab that can do it. Apart from that, it is just an amazing system and project import from Github was made _super_ easy. Also, in COPR, we are going to deploy support for Gitlab webhooks today.

...And after writing all this, I looked once more into Github to find out that it can actually do it too (in Webhook settings, there is "Let me select individual events" and then you can pick just "release", instead of "push"). Still, I am very much amazed by Gitlab and I would recommend it to everyone.

On COPR side, this could be done by not rebuilding the same package (of the same version/release) twice but that would make rebuilding of older packages quite a problem.

> ...And after writing all this, I looked once more into Github to find out
> that it can actually do it too (in Webhook settings, there is "Let me select
> individual events" and then you can pick just "release", instead of "push").
> Still, I am very much amazed by Gitlab and I would recommend it to everyone.

I've changed webhook to 'release' and will see what will happen.
Thank you for pointing it out.

If it turn out to be a correct solution I will change this bug to 'documentation'.

Well, setting webhook to 'release' in github interface does not work.
It does not trigger a build at all.

Maybe the content of webhook's js is different than expected?

Can you try "Create" event instead? It should be the one that generates "ref_type: tag".

It seems that "create" event triggered a lot of builds from master branch (of different packages) when I tagged a package in a different branch(?!).

Yep, the "create" event does currently trigger rebuild of all the packages in the project the webhook is triggered for. It's kind of silly but I don't see a way to infer what packages should be rebuilt based on the info from that event (https://developer.github.com/v3/activity/events/types/#createevent). We looked at it even before in the comments here: https://pagure.io/copr/copr/pull-request/22#. It seems that this behavior cannot be (easily) improved at the moment.

> Yep, the "create" event does currently trigger rebuild of all the packages in the project

Well, then it's unusable for us (It would rebuild 150+ packages on every tag).


Looking into details of "create" event triggered by tito tag I can see
{
  "ref": "yum-rhn-plugin-2.6.4-1",
  "ref_type": "tag",
...
}
which clearly identifies the package the event belongs to.
So I think it's possible to guess which package should be rebuilt.


And for standard "push" webhook the normal commit looks like
{
  "ref": "refs/heads/master",
  "before": "f5f28f258f8464c9946dacad78083ad4b6dc7df2",
  "after": "5ff694b1bdb8ca7f7bf0ec78dae62e323215499e",
  "commits": [...],
...
}
while "push" for tag it looks like
{
  "ref": "refs/tags/spacewalk-java-2.7.74-1",
  "before": "0000000000000000000000000000000000000000",
  "after": "419d99d030e199ea2f054b9ded1fe25b6507dbd1",
  "commits": [],
...
}
so again it can be distinguished.
I think in case of "--test option" unchecked the "push" events different than ref:"refs/tag/...." should be ignored.

Yes, in case Tito is used for release engineering, then it can be distinguished (because it tags with the package name and version always). I will implement this logic and deploy tomorrow.

--test is just a Tito switch for building from HEAD. I cannot get my head around it would do something else.

I made a patch (experimental) here: https://pagure.io/copr/copr/c/a26d1c2a48dece7f052aad94cfad69815e582864 and deployed. Please try.

It still triggers builds for non-tag commits.

I am not quite getting what you mean. Have you set sending of "Create" events only? If so, then it should not trigger builds for non-tag commits because no event should be sent in that case.

Ok, that was a misconfiguration on our side. Webhook was set to "push" not "create".

The "create" webhook seems to work correctly.

There's still a minor issue I don't understand - it fired build https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly/build/565302/
although there was no commit in the package's directory for a month.

I can debug this just with the data available currently available but if you could provide the event that launched the build, it would be much easier for me. 
Could you provide the event that executed the build? If not, I'll get one more coffee and try to do it without the event.

The only webhook around this time is spacewalk-java-2.7.83-1.fc25 tag:
  22e4ce80-510b-11e7-959e-6a07a07f365a 2017-06-14 16:09:53
https://github.com/spacewalkproject/spacewalk/settings/hooks/14126552#details

And I can see this pattern repeats pretty deterministically :)
https://copr.fedorainfracloud.org/coprs/g/spacewalkproject/nightly/builds/

Actually, I can't see the event cause I would need some kind of admin access to see it. Anyway, the mention that it happens deterministically helped as well.

The name of that package is 'spacewalk' and that's appearing in basically every tag created.

Can you, please, post the event here as an attachment? I will fix the package name matching condition to be more specific.

Created attachment 1289065 [details]
webhook content

(In reply to clime from comment #16)
> The name of that package is 'spacewalk' and that's appearing in basically
> every tag created.
... 
> Can you, please, post the event here as an attachment? I will fix the
> package name matching condition to be more specific.

Yes, something like 
-                     and package.name not in ref:
+                     and package.name != re.search(r'(.*)-[^-]+-[^-]+$', ref).group(1):
should be it.

I applied the patch (approximately) here https://pagure.io/copr/copr/c/13e5c95fe922fb1e56963d4461e9f50458432864. Should be in production this week.

New copr-frontend has been deployed.