Don't build tag pushes #270
Conversation
Recently after changes on how we parse payload on pushes form github, we started building tag pushes. Ultimately it's something we could do, but right now tags are interpreted as branches, which is wrong anyway. I'm disabling building tag pushes for now, until we can handle it properly.
|
can't we check if the commit has been built and if not build it? |
|
@joshk we can, but this does not really matter. The problem is that we don't have a notion of a tag in DB nor in UI and additionally, when you push tags you need to push commit to some branch anyway. So in the end, when I disable that, the effect will be almost the same as in what you wrote, but in your version tag push could trigger a build instead of a branch push (which will be confusing). |
|
Sorry, I don't fully follow. I know it doesn't show in the UI correctly (showing as a branch and not a tag) but building tags seems like a fair thing to do. If I push a tag for a commit which hasn't been tested yet, it would be great for Travis to test it. I have had feedback from users that building tags is great, so turning it off just because we display it as a branch and not a tag seems a bit odd to me. |
As far as I know you can't push a tag without a commit, so the commit will be built for one of the branches anyway. That said, I understand that some people may want to build tags, so I'll prepare another patch tomorrow - to add a tag to a commit and build, so we at least save it in the DB in a right way (I will still return it as a branch in API, to be able to deploy it quickly) |
Just to clarify, an example: you have a development branch and you have a commit |
|
Hi, any updates on this? Our continuous deployment process automatically tags our repos, and now it's becoming increasingly overwhelming for us as our tag builds (which are completely duplicated, as discussed above) take up our build queue. We have to manually cancel them in order for our "real builds" to go through quickly. cc @joshk @locochris @locomote/mos |
|
@fredwu we'll look into it this week! |
|
Thanks @roidrage 👍 |
|
Hi, By this, we can continue to add commits to master and then decide which of the already tested commits should become a release. So we don't need a code freeze. Btw, git does allow to push a tag without a commit using |
|
Could we turn this into a setting as well, disable tag builds by default and let people enable them for their projects? |
|
I'd prefer them on by default. |
|
@roidrage yup, I can look into that, in the spirit of pushing more smaller On Fri, Apr 18, 2014 at 10:47 AM, Graham Campbell
Piotr Sarnacki |
|
+1 one to adding it as a setting, but I would vote for it to be turned on by default as deployments can be enabled by tag builds only, meaning you would need to switch on tag builds to get deployment to work. |
Recently after changes on how we parse payload on pushes form github, we
started building tag pushes. Ultimately it's something we could do,
but right now tags are interpreted as branches, which is wrong anyway.
I'm disabling building tag pushes for now, until we can handle it
properly.