12:59 <iomartin> Hello everyone. I'm trying to configure buildbot to run a special builder only on git (annotaged) tags. I'm facing two issues and I'd appreciate help/pointers:

12:59 <iomartin> 1. In my workflow, I push a potential revision (still untagged), which triggers a bunch of other tests. When those tests pass, then I create the tag and push. However, since buildbot will already have seen that revision, the build is being ignored.

12:59 <iomartin> 2. How can I tell that something is a git tag? Since the ChangeFilter has the revision, I was thinking about trying to somehow do a "git describe --exact-match <revision>" but I don't know a) if this is the best way and b) how to query the git db

12:59 <iomartin> Thanks!

13:05 <mjw> Interesting question, I don't know the answer, but I would also like to know :)

13:06 <mjw> There is buildPushesWithNoCommits=True for gitpoller

13:07 <mjw> but I believe that is only for commits already seen on different branches

13:11 <iomartin> mjw: this might be useful. Tags are kind of new branches, so it might do the trick. Let me give this a try

13:18 <iomartin> Unfortunately that didn't work. If I create a new branch that points to the same revision then the build triggers, but if it's just an annotated tag then it's ignored

13:19 <mjw> yeah, I was afraid of that

13:19 <mjw> Of course that means that you can use it for new (release) branches

13:20 <mjw> which would be somewhat of my use case for this. Trigger a release build on a (signed) annotate tag.

13:22 <mjw> but I would really like it if I could use an annotated tag for that (and preferably signed, to do it only for known signatures, but of course that would mean adding some kind of git tag --verify in there somehow)

13:26 <iomartin> Yeah, that'd be pretty good. Unfortunately creating a new branch for every release doesn't really match our workflow :(

13:27 <iomartin> I almost feel like I'd have to do it via force builds, but then it almost defeats the purpose...

13:34 <iomartin> Oh maybe I can use a post-receive hook (https://github.com/buildbot/buildbot-contrib/blob/master/master/contrib/git_buildbot.py)

13:37 <iomartin> Although that is client-side and thus not so useful...

13:49 <iomartin> Or I can have another GitPoller for the same repo and then use `only_tags` for that poller

13:51 <mjw> I thought you could only have one poller per repo?

13:52 <iomartin> Oh I didn't know about that :(

13:54 <iomartin> So I can't replicate everything under a different workdir?

13:55 <iomartin> And put it under a different project

13:59 <mjw> you might need a different poller dir

14:02 <iomartin> Yeah... I'll have to give this a try later today. Thanks

15:29 <glogan> iomartin: mjw I think you're looking for something like `ChangeFilter(category='tag_push', branch_re=props['pkg_major_version'] + ".*")`

15:30 <glogan> the category changes depending on the host (this is gitlab, github is just 'tag')

15:30 <glogan> I'm not 100% sure it won't squash the build since its seen the hash already, but it's worth a shot

15:31 <glogan> in our usecase the tag's has is unique :/

15:31 <mjw> glogan, how do those set that category? /me isn't using either gitlab or github.

15:31 <mjw> Is there a way to set those from a plain git repo?

15:33 <glogan> It's in the scheduler, doesn't care what kind of source it's fed

15:33 <glogan> https://github.com/opencast/opencast-project-infrastructure/blob/master/ansible-buildbot-cluster/roles/buildbot-config/templates/schedulers.py#L151

15:33 <glogan> although different source -> different category. You may need to do some experimenting

15:54 <mjw> glogan, ok, but the poller sets the change source category

15:55 <mjw> glogan, how does a gitpoller set the category to indicate the change was a tag setting?

15:55 <mjw> is this some special magic only github/gitlab pollers do?

15:57 <glogan> ah

15:57 <glogan> so mine is hooked up via webhooks, which lets the source (github|lab|whatever) set the category

15:57 <glogan> in your case I would define *two* gitpollers. One for general use, another with `only_tags` set to true

15:58 <mjw> ok, so you can have two gitpollers for the same repo?

15:58 <glogan> at least from the docs, it looks like that should restrict it to *only* generating events on tags. Set that poller's `category` to `tag` or whatever

15:58 <glogan> yes

15:58 <mjw> I must have misremembered

15:59 <glogan> you might need to change the `workdir`

15:59 <glogan> since it's going to create a clone for each changesource

15:59 <mjw> http://docs.buildbot.net/current/manual/configuration/changesources.html#gitpoller

15:59 <glogan> (which also doubles your storage, but... mhe)

15:59 <mjw> That has. Note: There can only be a single GitPoller pointed at any given repository.

16:00 <glogan> huh

16:00 <mjw> maybe the documentation is wrong, it happens

16:01 <glogan> sooo... I wonder how it can tell? It is checkign the URL? In which case can you create two pollers, one with a shorter url, and one with a fqdn? Or ip? :)

16:01 <glogan> I struggle to imagine what the issue with having two pollers on the same repo would be, aside from collisions in the workdir

16:02 <glogan> I'd give it a try, ignoring the note. Worst case it no worky

16:03 <mjw> as far as I understand it (might be wrong/imagining) all pollers put their changes in the same git repo as so pointing two at the same would interfere with each other because they see/overwrite each other changes

16:03 <mjw> But maybe the Note means, if you use the same (default) workdir?

16:07 <glogan> maybe. The other option is to do this with change hooks. It'd be more dev work on the server side, but it would step around the need for buildbot to have two pollers

16:08 <glogan> cf https://docs.buildbot.net/latest/manual/configuration/wwwhooks.html#change-hooks