New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to skip CI for a tag #8051

Closed
Deilan opened this Issue Jul 6, 2017 · 8 comments

Comments

Projects
None yet
6 participants
@Deilan

Deilan commented Jul 6, 2017

Please provide a way to skip CI for a newly created tag. For example make it in a consistent fashion with commits: skip CI when a tag's message containts [skip ci] or [ci skip] - that would be enough for the time being. Or provide an appropriate option in .travis.yml config.

Motivation:
A tag is being created automatically as a part of deployment to GitHub Releases done by Travis on every commit to master branch. After pushing a tag a redundant build of the same commit is being launched in that case, which I don't need. Builds in my project are being executed very long, so even just one build counts.

Continuation of discussion #8041.

@BanzaiMan

This comment has been minimized.

Member

BanzaiMan commented Aug 22, 2017

Related: #1532

@svenfuchs

This comment has been minimized.

Member

svenfuchs commented Oct 10, 2017

Always skipping builds for tags should be possible by using conditional builds now: https://docs.travis-ci.com/user/conditional-builds-stages-jobs/

I.e. adding the following to .travis.yml should always skip tag builds:

if: tag IS blank
@chaim-sw

This comment has been minimized.

chaim-sw commented Oct 10, 2017

[We think, and are still trying to confirm, that] this has caused our tags to go from not building to recursively building over and over. that's our fault for using after_success instead of deploy.

We previously relied on the branch filter:

branches:
  only:
  - develop
  - /feature\/.+/
  - /release\/.+/

...to filter our tags. Naturally that's wrong because it's a violation of SOLID/Liskov to consider "tags" to be "branches" even though they are both "refs". But this may break other people as well.

[I feel that] if: tag IS blank is not declarative at all and implies a conditional structure that doesn't exist. It should follow the declarative pattern you're using for your other resources:

tags:
  enabled: false
@chaim-sw

This comment has been minimized.

chaim-sw commented Oct 10, 2017

Please forgive all the edits. We thought we were seeing two issues instead of one. Must have been the IPA.

@sw-carlin

This comment has been minimized.

sw-carlin commented Oct 10, 2017

@svenfuchs the workaround for this and related issues was to use the branch filter but it no longer seems to be filtering tags at all.

@chaim-sw

This comment has been minimized.

chaim-sw commented Oct 11, 2017

Another change that seems to have been introduced is that now, for tagged builds:

image

The tag name is showing as the commit message, and the tag is not shown where branch names are usually shown. I'm not sure if that's related to this fix but it's bad. We're following up with ops about the problems tomorrow if we can.

@philipgloyne

This comment has been minimized.

philipgloyne commented Oct 11, 2017

+1 @chaim-sw
Whatever has changed recently has caused multiple projects I work with to create infinite loops building tag branches. It seems to be ignoring our .travis.yml

branches:
  except:
    - /.*-skip-ci$/
    - /^\d*(\.\d+)*(-.+)*$/

Which used to shield us from tags getting built. Adding the below seems to fix it. It would have been good to know the above was going to deprecate (if it was intended)

if: tag IS blank
@stale

This comment has been minimized.

stale bot commented Apr 13, 2018

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues

@stale stale bot added the stale label Apr 13, 2018

@stale stale bot closed this Apr 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment