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

fix(git-node): do not assume release commit will conflict #871

Merged
merged 2 commits into from
Nov 19, 2024

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Nov 16, 2024

As I was testing git node release --promote with nodejs/node#55879, I realized the assumption that a release commit would necessarily conflict when cherry-picked to the default branch is wrong for the case of semver-patch releases.

Copy link

codecov bot commented Nov 16, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.08%. Comparing base (e3e19b3) to head (a3b4442).
Report is 40 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #871      +/-   ##
==========================================
- Coverage   83.08%   80.08%   -3.00%     
==========================================
  Files          37       39       +2     
  Lines        4251     4676     +425     
==========================================
+ Hits         3532     3745     +213     
- Misses        719      931     +212     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@aduh95 aduh95 requested a review from RafaelGSS November 18, 2024 23:53
@@ -147,23 +147,31 @@ export default class ReleasePromotion extends Session {
cli.warn(`Aborting release promotion for version ${version}`);
throw new Error('Aborted');
}
await this.cherryPickToDefaultBranch();
const appliedCleanly = await this.cherryPickToDefaultBranch();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to check if the release is semver-patch instead of appliedCleanly. It will be confusing to people when reading the code.

Copy link
Contributor Author

@aduh95 aduh95 Nov 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's a good idea to assume that a semver-patch release never conflicts, and that a non-semver-patch would always conflict. I don't understand why it would be confusing, on the contrary it seems to me having fewer assumptions in code leads to fewer confusion in my experience.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel confusing the git checkout HEAD^ | git checkout HEAD part considering a appliedCleanly variable. Maybe a comment? I'm fine leaving it as appliedCleanly with a comment on that part

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could use git rev-parse HEAD before trying to cherry-pick, and then git checkout (or the less ambiguous git restore) with the exact commit sha.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to add comments

@aduh95 aduh95 merged commit ec6c6cb into nodejs:main Nov 19, 2024
10 of 11 checks passed
@aduh95 aduh95 deleted the release-commit-no-conflict branch November 19, 2024 18:22
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.

3 participants