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

Add travis-ignore config #1468

Closed
nkt opened this Issue Sep 29, 2013 · 16 comments

Comments

Projects
None yet
@nkt

nkt commented Sep 29, 2013

I mead something like that:

skip_build:
    - docs/*
    - README.MD
    - LICENSE

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.

@sarahhodne

This comment has been minimized.

Show comment
Hide comment
@sarahhodne

sarahhodne Oct 7, 2013

Contributor

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).

Contributor

sarahhodne commented Oct 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@thedrow

thedrow commented Oct 9, 2013

+1

@nkt

This comment has been minimized.

Show comment
Hide comment
@nkt

nkt 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

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

@sarahhodne

This comment has been minimized.

Show comment
Hide comment
@sarahhodne

sarahhodne Oct 20, 2013

Contributor

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.

Contributor

sarahhodne commented Oct 20, 2013

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

This comment has been minimized.

Show comment
Hide comment
@rkh

rkh Oct 24, 2013

Member

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

Member

rkh commented Oct 24, 2013

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

@thedrow

This comment has been minimized.

Show comment
Hide comment
@thedrow

thedrow Oct 24, 2013

@rkh That could work.

thedrow commented Oct 24, 2013

@rkh That could work.

@grobie

This comment has been minimized.

Show comment
Hide comment
@grobie

grobie 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 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.

@sarahhodne

This comment has been minimized.

Show comment
Hide comment
@sarahhodne

sarahhodne Nov 7, 2013

Contributor

@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.

Contributor

sarahhodne commented Nov 7, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@grobie

grobie Nov 7, 2013

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

grobie commented Nov 7, 2013

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

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Jan 6, 2014

Member

I do generally like the idea behind this.

Member

joshk commented Jan 6, 2014

I do generally like the idea behind this.

@roidrage

This comment has been minimized.

Show comment
Hide comment
@roidrage

roidrage May 2, 2014

Member

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.

Member

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.

@listx

This comment has been minimized.

Show comment
Hide comment
@listx

listx Aug 29, 2016

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.

listx commented Aug 29, 2016

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.

@raphaelstolt

This comment has been minimized.

Show comment
Hide comment
@raphaelstolt

raphaelstolt Aug 30, 2016

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).

raphaelstolt commented Aug 30, 2016

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).

@Scotchester

This comment has been minimized.

Show comment
Hide comment
@Scotchester

Scotchester Sep 30, 2016

I would also like to vote for reopening this issue.

Scotchester commented Sep 30, 2016

I would also like to vote for reopening this issue.

@raphaelstolt

This comment has been minimized.

Show comment
Hide comment
@raphaelstolt

raphaelstolt May 10, 2017

Seems like this, is still #6301 something the people want. 😶

raphaelstolt commented May 10, 2017

Seems like this, is still #6301 something the people want. 😶

@BanzaiMan

This comment has been minimized.

Show comment
Hide comment
@BanzaiMan

BanzaiMan May 10, 2017

Member

There is further discussion in #6301. We have an internal discussion going, but it is not on the roadmap at this time.

I'm locking this to prevent further comments here.

Member

BanzaiMan commented May 10, 2017

There is further discussion in #6301. We have an internal discussion going, but it is not on the roadmap at this time.

I'm locking this to prevent further comments here.

@travis-ci travis-ci locked and limited conversation to collaborators May 10, 2017

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