This repository was archived by the owner on Mar 3, 2023. It is now read-only.
Only trigger branch builds on master and release branches #14250
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.
Description of the Change
Modify the Travis, Circle CI, and AppVeyor build metadata to only create branch builds for
master
and release branches namedx.y-releases
. This should help our build queue situation somewhat.Note that pull request builds should still be triggered on all three systems.
Alternate Designs
We could do this by adding logic to the build scripts themselves to detect when they're being executed on a branch build that will also create a PR build, but there's no reason not to use the built-in solutions for this.
AppVeyor and (I believe) Circle both allow you to configure this setting in their own web UIs. I generally prefer to keep build configuration within the repository as much as possible, though, it's less confusing and we can manage it with pull requests (like this one!).
Why Should This Be In Core?
The core build metadata files are in core 😁
Benefits
This will decrease the extraneous builds that are created when maintainers push branches to the atom/atom fork and create pull requests from them, which is common in our workflow. This results in two builds for each push to a feature branch: one from the push to the feature branch and one from the pull request event:
Running fewer builds will result in less queue pressure and more rapid feedback on changes.
Possible Drawbacks
Running the tests less often may cause us to miss flaky failures that happen only occasionally. We will also lose the ability to distinguish failures that are present on the branch itself (from the branch build) from those that are caused by the merge into master (from the pull request build).
Applicable Issues
N/A
We've agreed to hold off on changing the build for a day or so to more easily isolate the cause of any problems from #13646.
/cc @damieng @as-cii @maxbrunsfeld @50Wliu