Skip to content
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

Remove rust channel #63

Merged
merged 1 commit into from
Feb 27, 2017
Merged

Remove rust channel #63

merged 1 commit into from
Feb 27, 2017

Conversation

Arzte
Copy link
Contributor

@Arzte Arzte commented Feb 23, 2017

This is done to prevent a default build from spawning, (it looks weird, its better to have the build as part of the matrix.)
Also the default is to run on stable anyways so its even more silly.

This is done to prevent a default build from spawning, (it looks weird, its better to have the build as part of the matrix.)
@japaric
Copy link
Owner

japaric commented Feb 23, 2017

Thanks for the PR, @SirDoctors.

This is done to prevent a default build from spawning

Yay!

Also the default is to run on stable

Wait, what? How come TRAVIS_RUST_VERSION works if rust: * is not used? That seems like a brittle thing to rely on. I would prefer to have something explicit like global: env: RUST_CHANNEL = stable and the leave the elements of the matrix override that if needed. That approach would also support setting nightly as the default channel. (P.S. ci/install.sh would have to be update to use the RUST_CHANNEL variable)

I think you can use language: generic to have nothing run before before_install. Because right now the builds are defaulting to a ruby environment.

That macOS failure looks odd ...

@Arzte
Copy link
Contributor Author

Arzte commented Feb 24, 2017

Travis's default is to use the latest stable rust version, its not very brittle at all. Builds aren't defaulting to ruby, they only do that when the language isn't set/is set to generic.

As far as that one osx error it seem to be a issue with cross not being in the env after installing, I'd give that job a restart to see if it does it again.

@japaric
Copy link
Owner

japaric commented Feb 27, 2017

Builds aren't defaulting to ruby, they only do that when the language isn't set/is set to generic.

But 'rust: stable' is not specified in most cases. Travis seems to be infering that the repo is rust somehow (from the repo contents probably). I wonder if it's assuming 'rust: stable' because some job in the matrix is 'rust: nightly'.

As I mentioned above, this PR makes the use case of "default to rust: nightly" unergonomic because you'll have to specify 'rust: nightly' in every build.

I still would prefer the 'language: generic' + a 'RUST_CHANNEL' env variable approach.

@Arzte
Copy link
Contributor Author

Arzte commented Feb 27, 2017

Its not, it's inferring that its rust stable from language: rust in the top of the file. When language: rust is set, Travis defaults to rust: stable for all builds that don't specify otherwise.

@japaric
Copy link
Owner

japaric commented Feb 27, 2017

Ohh, I totally forgot that was there.

OK. This seems fine to land as it is.

I'll retry the build to see what's up with the macOS error.

@japaric
Copy link
Owner

japaric commented Feb 27, 2017

It's green this time.

@japaric japaric merged commit 795b796 into japaric:master Feb 27, 2017
@Arzte Arzte deleted the patch-1 branch February 28, 2017 01:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants