Can you skip a build if there is a tag?
I love the ability to build on tags, and to create special deployment rules for tags vs commits, but generally when I push a tag it is accompanied by a commit (which probably just increments a nuget version and has a commit message the same as the tag name). This means two builds are always queued, but I only care about one of them (the tag build), so I manually cancel the other so I don't have to wait on it.
Is there any way to automatically cancel or skip a build for a commit when there is a tag for the same commit also queued? If not, is this a feature you would consider?
I tried using skip_commits with a pattern to match commits like "v1.2.3" but that also seems to cause tags with that pattern to be skipped, so it's not a viable workaround.
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Feodor Fitsner on 28 Feb, 2015 08:58 PM
So you there are two "similar" builds started when you push a tag? How do you push a tag? What source control/provider is that?
2 Posted by Bret Copeland on 28 Feb, 2015 09:11 PM
I generally use SourceTree on Windows for .NET projects. It runs this command when it pushes:
You can see here the sample app I've been playing with to figure out AppVeyor, and how every time I do a combination commit/tag push, I get two builds (one for the tag, and one for the commit it references).
I would expect for some people, that behavior is desirable, but for me it serves no purpose, and it would be my preference to disable it. I would think it could be a feature similar to rolling builds where a tag for a commit takes precedence over another build for the same commit.
Support Staff 3 Posted by Feodor Fitsner on 28 Feb, 2015 09:19 PM
OK, this is GitHub which is great. Could you check "Recent deliveries" in webhook settings on GitHub? There are probably two calls for each push with tag you do from SourceTree.
Could you drop here their requests to AV please?
4 Posted by Bret Copeland on 28 Feb, 2015 09:28 PM
Correct, there are two for each example like that. I did a diff on the JSON payload and they are largely the same, but one is definitely for the tag while the other is for the commit.
Basically
vs
The rest is the same.
5 Posted by Bret Copeland on 28 Feb, 2015 09:31 PM
I don't see any sensitive data in the post bodies, so here are the complete bodies, which I think you were asking for:
For the tag:
For the commit:
Support Staff 6 Posted by Feodor Fitsner on 28 Feb, 2015 09:36 PM
Yeah, the issue is in
git push --tags origin master:mastercommand which pushes branch changes together with all tags. GitHub in its turn calls webhook for "regular" branch push and then does one call for each tag in that push; seems tag calls go first.If you simply do
git push origin [tagname]or create a tag from GitHub UI that will give one webhook call.Handling
git push --tagsis something new - we should think about how to deal with that case.7 Posted by Bret Copeland on 28 Feb, 2015 09:51 PM
Well,
git push origin [tag]isn't really a solution because then that commit doesn't actually make it into the remote master. At some point, I still have to push to master, and that's what kicks off the unnecessary build.My work flow for most projects (regardless of which language or CI I'm using) is to always have a commit in master marked with the version so that when you scan the commit logs, you can easily see where the releases were, and what commits came between them. Generally all that commit does is increment a package number (for nuget/npm/etc), then I tag it and push. That's the exact workflow
npm versionuses.I'm okay that the answer is "we don't support this yet." I can work around it for now by always pushing the tag first so that it will reliably get queued for building first. Long term, it would be great to handle this better.
I would even accept an ability to specify
skip_commitsseparate fromskip_tags, or a way to sayskip_commitsdoesn't apply to tags, as a reasonable solution since I always want to build tags, but may want to skip commits in certain circumstances.Thanks for your quick response.
Support Staff 8 Posted by Feodor Fitsner on 28 Feb, 2015 11:13 PM
Your flow is perfectly fine and I find
git push --tagsvalid too that must be supported.I think we could bet here on the fact that webhook push commit event is fired shortly after tag events. Thus we could skip commit build by doing a check if there was tag commit with the same head commit ID few seconds before.
We could deploy a fix next week.
Support Staff 9 Posted by Feodor Fitsner on 04 Mar, 2015 01:08 AM
Hi Bret,
I've been experimenting with
git push --tagscommand. Looking at webhook's "Recent deliveries" GitHub calls "push" event for commit first and then for each tag consequently. Could you please take a look at your repo and confirm that this is correct order?My concern here is racing condition.
10 Posted by Bret Copeland on 04 Mar, 2015 02:33 AM
I'm actually seeing the tag hook first most often, but I don't see a consistent order in my logs. Sometimes the tag event is pushed first, and sometimes the commit is first. So I don't think relying on order would work.
Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:54 AM.