I mead something like that:
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).
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.
The payload for normal pushes actually includes added, removed and modified, so we could base it on that.
@rkh That could work.
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.
@henrikhodne haha, of course, sorry, wasn't really think when I wrote the comment. Cool stuff though!
I do generally like the idea behind this.
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.
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.
git diff --name-only A..B
CHANGED_FILES - IGNORED_FILES_PATTERNS > 0
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. README.md 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.