Move branch whitelisting/blacklisting to the website #1095

Open
sarahhodne opened this Issue May 6, 2013 · 10 comments

Comments

Projects
None yet
10 participants
@sarahhodne
Contributor

sarahhodne commented May 6, 2013

Another interesting suggestion that came up when discussing #1094 was to move the branch blacklist/whitelist to the website. Having this information stored in our database means we get rid of the slightly odd behaviour where a branch only follows the .travis.yml file on that branch (see #414/#609).

On the database side this could probably be as easy as a whitelist and blacklist field on the repository table containing lists of branches. Again we need to make a page to put these setting on, see #1094.

Closes #902.

@joshk

This comment has been minimized.

Show comment Hide comment
@joshk

joshk May 6, 2013

Member

Big 👍 for this!

On 6/05/2013, at 8:23 AM, Henrik Hodne notifications@github.com wrote:

Another interesting suggestion that came up when discussing #1094 was to move the branch blacklist/whitelist to the website. Having this information stored in our database means we get rid of the slightly odd behaviour where a branch only follows the .travis.yml file on that branch (see #414/#609).

On the database side this could probably be as easy as a whitelist and blacklist field on the repository table containing lists of branches. Again we need to make a page to put these setting on, see #1094.


Reply to this email directly or view it on GitHub.

Member

joshk commented May 6, 2013

Big 👍 for this!

On 6/05/2013, at 8:23 AM, Henrik Hodne notifications@github.com wrote:

Another interesting suggestion that came up when discussing #1094 was to move the branch blacklist/whitelist to the website. Having this information stored in our database means we get rid of the slightly odd behaviour where a branch only follows the .travis.yml file on that branch (see #414/#609).

On the database side this could probably be as easy as a whitelist and blacklist field on the repository table containing lists of branches. Again we need to make a page to put these setting on, see #1094.


Reply to this email directly or view it on GitHub.

@nevik

This comment has been minimized.

Show comment Hide comment
@nevik

nevik May 18, 2013

This issue supersedes #902 and a fix for it would also fix that issue.

nevik commented May 18, 2013

This issue supersedes #902 and a fix for it would also fix that issue.

@tjmcewan

This comment has been minimized.

Show comment Hide comment
@tjmcewan

tjmcewan May 29, 2013

👍 (Travis has been quite a mental paradigm shift for me. I would've expected email notifications to be controlled on a per-user basis through the website, for instance.)

👍 (Travis has been quite a mental paradigm shift for me. I would've expected email notifications to be controlled on a per-user basis through the website, for instance.)

@niedbalski

This comment has been minimized.

Show comment Hide comment
@niedbalski

niedbalski Jul 4, 2013

+1 for this one!

+1 for this one!

atrol referenced this issue in mantisbt/mantisbt Sep 16, 2013

Added .travis.yml file
Copied from master-1.2.x branch to prevent build failures, as 2.0 is
currently not setup for builds.
@arstrube

This comment has been minimized.

Show comment Hide comment
@arstrube

arstrube Sep 25, 2013

I second this. 👍 👍 👍 Out of 3 Travis CI builds that are run for my fork, on average 2 are unwanted. Because I am a contributor, I cannot change travis.yml or commit messages some branches, typically master. These builds are guaranteed to fail, so they are of no use to me.

I use customized scripts for my dev branch. That is the only build I want and pay attention to.

Think of how much server time Travis CI could save, if no unwanted builds were ever run

I second this. 👍 👍 👍 Out of 3 Travis CI builds that are run for my fork, on average 2 are unwanted. Because I am a contributor, I cannot change travis.yml or commit messages some branches, typically master. These builds are guaranteed to fail, so they are of no use to me.

I use customized scripts for my dev branch. That is the only build I want and pay attention to.

Think of how much server time Travis CI could save, if no unwanted builds were ever run

@nevik

This comment has been minimized.

Show comment Hide comment
@nevik

nevik Sep 25, 2013

👍 to @arstrube for whipping out the econ arguments! :D

nevik commented Sep 25, 2013

👍 to @arstrube for whipping out the econ arguments! :D

@felipec

This comment has been minimized.

Show comment Hide comment
@felipec

felipec Nov 11, 2013

This is definitely needed. Right now I have to create a new repository with a single branch just because of this.

And now I have a mess of temporary and non-existent branches reported as failed even though they don't have a .travis.xml file, or aren't even there any more.

felipec commented Nov 11, 2013

This is definitely needed. Right now I have to create a new repository with a single branch just because of this.

And now I have a mess of temporary and non-existent branches reported as failed even though they don't have a .travis.xml file, or aren't even there any more.

@Balkerm

This comment has been minimized.

Show comment Hide comment
@Balkerm

Balkerm Dec 30, 2013

+1 for this one!

Balkerm commented Dec 30, 2013

+1 for this one!

@chad-autry

This comment has been minimized.

Show comment Hide comment
@chad-autry

chad-autry Jun 24, 2015

Grah, trying to push my built node.js app to a special branch where dockerhub can them pull them and create a docker image.

Couldn't figure out why whitelist wasn't working until I found this issue chain #414

2013 is the last comment, looks like there is no hope of it getting fixed, and I'll need to introduce a .dockerignore

Should at least better document the Branch whitelisting/blacklisting. It isn't obvious that a .travis.yml file is still required in each branch for the features to work.

Grah, trying to push my built node.js app to a special branch where dockerhub can them pull them and create a docker image.

Couldn't figure out why whitelist wasn't working until I found this issue chain #414

2013 is the last comment, looks like there is no hope of it getting fixed, and I'll need to introduce a .dockerignore

Should at least better document the Branch whitelisting/blacklisting. It isn't obvious that a .travis.yml file is still required in each branch for the features to work.

@fgp

This comment has been minimized.

Show comment Hide comment
@fgp

fgp Jan 26, 2018

+1. When I commit to my own fork of an upstream repository, I usually want travis to build my own branches, but not the branches that simply mirror upstream. Currently, when I push upstream's master changes to my own master branch (so as to keep things in sync), travis builds unnecessarily.

fgp commented Jan 26, 2018

+1. When I commit to my own fork of an upstream repository, I usually want travis to build my own branches, but not the branches that simply mirror upstream. Currently, when I push upstream's master changes to my own master branch (so as to keep things in sync), travis builds unnecessarily.

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