Add travis-ignore config #1468

nkt opened this Issue Sep 29, 2013 · 14 comments


None yet

10 participants

nkt commented Sep 29, 2013

I mead something like that:

    - docs/*

If I update readme or docs I don't want run tests, and don't want add to every commit [ci skip], I'd like to describe the rules in one place and forget about it.


I do like the idea of this, but I'm not quite sure exactly how to implement it. We could get the files from GitHub, but I'm not sure exactly how many API requests that would create (well, one per commit).

thedrow commented Oct 9, 2013


nkt commented Oct 20, 2013

git works with changes, not files. So I think it is impossible to know changed files in advance. But we could clone and get all information about changes


Well, yes, git works with changes, but each change is attached to the path of the changed file, so if we had the diffs we could just match the paths.

It looks like we'd have to either clone the repository or query the GitHub API while creating the request to do this. Cloning the repository is not really an option, but if we could make this a single GitHub API request I think we could implement this at some point.

It would require a refactoring of our request creation, though, as it is currently starting to get quite messy and I don't want to add something as complicated as this without cleaning it up a bit first.

rkh commented Oct 24, 2013

The payload for normal pushes actually includes added, removed and modified, so we could base it on that.

thedrow commented Oct 24, 2013

@rkh That could work.

grobie commented Nov 7, 2013

Also, does it make sense to build tags? I just pushed a new release (commit + a tag for that commit) and travis built it twice.


@grobie Building tags is unrelated to this ticket, I think. We're working on some changes to the way we handle tags (and other pushes), so that if we get a push for a commit we've already built, we'll just "tag" that build instead of creating a new one.

grobie commented Nov 7, 2013

@henrikhodne haha, of course, sorry, wasn't really think when I wrote the comment. Cool stuff though!

joshk commented Jan 6, 2014

I do generally like the idea behind this.

roidrage commented May 2, 2014

I'm very hesitant regarding this added complexity. With [ci skip] there's already control about these settings.

I'm closing this for now, but we may revisit this in the future.

@roidrage roidrage closed this May 2, 2014
@scott113341 scott113341 referenced this issue in soundcasts/soundcasts-server Oct 16, 2015

Skip Travis Builds on Certain Changes #22

listx commented Aug 29, 2016 edited

FWIW, I would think that this ticket should be revisited, if only for the added relief it would give the Travis build machines (there will be lesser builds).

I disagree with incorporating added, removed, and modified values in a push payload, because that's just too much added complexity (e.g., what does it mean to ignore a deleted file? but what if that file is essential to a build (i.e., the commit was in error)?).
EDIT: Re-reading this, I realize that I asked a line of inquiry in the wrong direction. Still, I think that juggling added, removed, and modified files (and treating each differently) is just too much complexity. It would be much, much simpler to just have a .travisignore full of patterns, and then only care about changes to files that "survive" this pattern, as discussed below.

I mean, there is already git diff --name-only A..B which gives a list of all files that have changed (all modified paths). So now the problem is reduced to something like CHANGED_FILES - IGNORED_FILES_PATTERNS > 0. The hard part would be the handling of globbing rules and such, but I'm assuming there's abundant literature on this topic.


I also think this ticket should be revisited. Having something like a .buildignore or .travisignore which allows to exclude files similar to .gitignore would reduce the amount of unnecessary builds (e.g. when doing some sole fixes on repository artifacts e.g. or content below a docs directory).

The option to skip builds via patterns in the commit message IMO adds unrelated metadata to the commit (kind of a SRP violation).


I would also like to vote for reopening this issue.

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