Auto: Releases being generated even though no-release label is present
Describe the bug
In one of our repos we're seeing consistent deployments when we expect no deploy to happen. This churn specifically happens when @renovatebot makes a pull request to update dependencies, so it _may_ be how it's handling the commit/merge process.
Here's an example PR where the no-release label is present (Version: Trivial in our case) but the release is still happening. Here's the CI results of that given merge.
@hipstersmoothie I'll update with a verbose mode run when I get a chance. If I can chase it down to something particular I'll open a PR.
To Reproduce
I haven't quite identified what the commonality here is. This is the only place in our org where @renovatebot auto-merges code updates so it could be related to that.
Expected behavior
No release should be triggered.
zephraph
All 11 comments
Had another instance of it on a different repo. https://github.com/artsy/palette/compare/v2.25.10...v2.25.11. This was automerged too, but by peril instead of @renovatebot. Maybe it's the way bots merge PRs?
zephraph
on 15 Jan 2019
it could be. the skip release labels requires the head to have the associated label.
It should look probably look for last PR rather than last commit.
hipstersmoothie
on 15 Jan 2019
Relevant lines https://github.com/intuit/auto-release/blob/83463e3f468a6d5e265cd5c720530bc5ac637365/src/semver.ts#L59
hipstersmoothie
on 15 Jan 2019
Hmmm... yeah. So, when I was building this I looked between the head hash and the hash of the last release and used that to figure out what the PRs were.
https://github.com/artsy/reaction/pull/1407/files#diff-ff397bdd24eed50e2a2cade2792a9d80R100
zephraph
on 15 Jan 2019
@zephraph Just to be clear, is this the situation that is happening?
gitlog:
- Some commit a bot or person made after you merged
- the commit that has the PR with the
skip-releaselabel
result:
auto doesn't skip-release because commit 2 is not at the top of the gitloh
hipstersmoothie
on 17 Jan 2019
There wasn't a commit that was made after the merge. It seems to be the merge itself. When a bot merges (I think it's that, but that could be a coincidence) a PR then a release happens even when a skipReleaseLabels label is present. I can find more examples if needed.
Here's the latest example (similar to the one above).
- https://github.com/artsy/renovate-config/pull/164 was created by renovate
- Renovate assigned
Version: Trivialto the PR (which is in skipReleaseLabels) - Renovate merges the PR automatically
- A new release is cut despite there being a
skipReleaseLabelslabel being present
zephraph
on 17 Jan 2019
This PR merge doesn't have a PR number in the commit subject
All the one that work do have a PR number
auto relies on this number in the commit message to get the PR number:
So something seems to be up when merging those PRs. Is it a rebase that is happening?
hipstersmoothie
on 17 Jan 2019
we need a function that returns the pr associated with a SHA but I'm having trouble finding an appropriate octokit method
hipstersmoothie
on 18 Jan 2019
hmm is just went down the path of trying to match the commit in master to the commit in the PR but the seem to have different SHAs.
This is super disappointing. Now I have no clue how we can match these commits to their PRs
hipstersmoothie
on 18 Jan 2019
merge_commit_sha to the rescue
hipstersmoothie
on 18 Jan 2019
@zephraph this should be fixed in v2.5.6. Let me know if you still have issues!
hipstersmoothie
on 18 Jan 2019
Related issues
jdalrymple
·
6Comments
hipstersmoothie
·
11Comments
theAdhocracy
·
6Comments
reintroducing
·
14Comments
thuringia
·
14Comments
Most helpful comment
@zephraph this should be fixed in
v2.5.6. Let me know if you still have issues!