Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat: Add support for ref comparison#1408

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
jarojasm95 wants to merge7 commits intorelease-drafter:master
base:master
Choose a base branch
Loading
fromjarojasm95:diff-commits

Conversation

@jarojasm95
Copy link

@jarojasm95jarojasm95 commentedOct 6, 2024
edited
Loading

This project is great ❤️

I've found myself using it more and more, however I've found that it does not work as I'd expect for some git workflows, specifically when using "merge commits" to the branch whererelease-drafter is configured.

This is happening becauserelease-drafter uses the date of the last release to list commits to draft a new release, however if commits were merged with an earlier date they get ignored!

This PR adds a configuration option to support such workflows in a backwards-compatible way.

gautiwiseis, Borewit, and gjvoosten reacted with thumbs up emoji
Comment on lines +107 to +108
ref(qualifiedName: $baseRef) {
compare(headRef: $targetCommitish) {
Copy link
Author

Choose a reason for hiding this comment

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

the goal here is to get something like the result of this rest endpoint:
https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#compare-two-commits

@jarojasm95jarojasm95 changed the titleAdd support for ref comparisonfeat: Add support for ref comparisonOct 6, 2024
@jetersen
Copy link
Member

Wouldn't ref comparison not always be the better option over dates? I assume it is related to#1382#1260 🤔

gautiwiseis reacted with thumbs up emoji

@kylejPomelo
Copy link

this feature would be useful to my use case. We're managing different types of releases from a monorepo, and whenever one type releases, the commits of the next release, or either type, are calculated since that release.

I'd like to use this and manually derive the ref on our end and provide that to release-drafter if possible

@jetersen
Copy link
Member

@jarojasm95 I don't think we need the option to turn this off. I believe would provide a better result then using dates as in we should always use the refs instead of dates. To determine commits that should be included. I would love to see this PR merged.

gautiwiseis, ScumbagScalawag, and gjvoosten reacted with thumbs up emoji

@ScumbagScalawag
Copy link

Maybe I can add a little clarity on direction for this feature of "ref comparisons", specifically release notes that can show the diff between two known commits/tags, likeprevious_tag_name in the GitHub API'sgenerate release notes API.

Theautomatically-generated release notes'release.yaml file correctly calculates new Pull Requests for the release because it lists the pull requests between commita andb by using something likegit log --graph (which itself implies the--topo-order flag) as opposed to the current implementation, which I suspect is calculating the "new" PRs by date instead of topological order; something likegit log --date-order.

The correct solution, which wouldpotentially also solve issues like#1382 and#1260, would be to make sure the diff to calculate PR's between releases is always determined by topological order of git history. I've tested this logic out in a (private) repo that has Pull requests that were new to a "release" branch, but older than the last release + release notes and using the topological history (or--graph) is the only way for me to validate the auto-generated release notes' listed PRs. When I do regular git log and look at the commit range it fails to include a series of PRs that I know are actually new to that branch/build/release notes.

Not sure if this isexactly what's going on, but it's one of the problems I've found with calculating PR diffs for the sake of another complex release train I'm managing. I can elaborate more if needed, but I have a suspicion that the topological ordering is necessary not just to feature match GitHub'sprevious_tag_name, but also to fix these issues of missing PRs

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@jarojasm95@jetersen@kylejPomelo@ScumbagScalawag

[8]ページ先頭

©2009-2025 Movatter.jp