-
Notifications
You must be signed in to change notification settings - Fork 24
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
A better story for canary jobs (yellow CI) #33
Open
jonhoo
wants to merge
10
commits into
master
Choose a base branch
from
smoketest
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 6 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
0cc8254
Add warn-free clippy smoketest
jonhoo 2a5d0a8
Make it easy to disable all smoke tests
jonhoo 1375923
Use cargo check with -Dwarnings over clippy
jonhoo 9891ddd
Canaries is better than smoketests
jonhoo 432bb20
Slightly more concise name for -Dwarnings
jonhoo c0d85e3
cargo check needs setup
jonhoo 0e19cd3
Support allow_fail on cargo check
jonhoo a413dbb
Remove remains of reverted change
jonhoo 7bcfb49
Merge branch 'master' into smoketest
jonhoo 4e6377a
Avoid a repeated if
jonhoo File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,22 +1,32 @@ | ||
parameters: | ||
setup: [] | ||
canaries: true | ||
|
||
jobs: | ||
- template: rustfmt.yml | ||
parameters: | ||
name: rustfmt | ||
- template: rustfmt.yml | ||
parameters: | ||
name: rustfmt_beta | ||
rust: beta | ||
allow_fail: true | ||
- ${{ if eq(parameters.canaries, 'true') }}: | ||
- template: rustfmt.yml | ||
parameters: | ||
name: rustfmt_beta | ||
rust: beta | ||
allow_fail: true | ||
- template: cargo-clippy.yml | ||
parameters: | ||
name: clippy | ||
setup: ${{ parameters.setup }} | ||
- template: cargo-clippy.yml | ||
parameters: | ||
name: clippy_beta | ||
setup: ${{ parameters.setup }} | ||
rust: beta | ||
allow_fail: true | ||
- ${{ if eq(parameters.canaries, 'true') }}: | ||
- template: cargo-check.yml | ||
parameters: | ||
name: warning_free | ||
setup: ${{ parameters.setup }} | ||
err_on_warn: true | ||
allow_fail: true | ||
- ${{ if eq(parameters.canaries, 'true') }}: | ||
- template: cargo-clippy.yml | ||
parameters: | ||
name: clippy_beta | ||
setup: ${{ parameters.setup }} | ||
rust: beta | ||
allow_fail: true |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we allow
deprecated
? It'll make things more stable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is already
allow_fail
, so I'd be inclined to still give deprecation warnings. They're things you should probably fix, just like other warnings.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allow_fail
allow_fail
witherr_on_warn
. In my use case, I do not want to be doing that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good catch! Fixed 1 in latest commit.
As for 2, it doesn't really assume that. If you specify
err_on_warn
withoutallow_fail
, you are specifically saying "I want to treat warnings as CI errors". Seems reasonable for that to be a valid option?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While so far I've gotten away with
deprecated
being enabled, you've brought up the concern over dependencies breaking people. If we want to take that seriously and support people who want a pinned warnings check, then we'd need to disable that warning.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking here was that either you care about warnings, or you do not (this is
err_on_warn
). If you do, you either want them to cause red CI or you want them to cause yellow CI (this isallow_fail
). We could add a third branch point which is "care about all but warnings caused by changes in dependencies" I suppose (what would it be called)? My guess is that that option is less common, but I have limited data on that.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My care abouts
As long as those conditions are met, I'm fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so, I think this satisfies all of those. Specifically, the default
stages.yml
will never make your CI red from warnings, it will only ever make it yellow. You can choose to directly depend oncargo-check.yml
, and then you can choose whether you want warnings to cause red CI (err_on_warn: true
+allow_fail: false
), yellow CI (err_on_warn: true
+allow_fail: true
), or green CI (err_on_warn: false
+allow_fail: false
; the default).Thus, anything that'd make your CI red would be by choice in setting up your pipeline.
Now, what this PR does not give you the ability to do is to run CI and have it fail on warnings that are not due to dependencies. I think that's specifically something you would like, but I also think that's something that's better handled in a new PR where we can explicitly figure out which warnings that would require allowing.
So, with all that said, my inclination would be to merge and then open an issue tracking "red CI from non-dependency warnings".