Automatic GitHub Pull Request numbers

[Frassle]

Is your feature request related to a problem? Please describe.

We've been using an internally developed tool at Pulumi for some of our changelog management. We're looking at switching over to changie now but one feature of our internal tool that's quite nice is that it will fetch pull request numbers for fragment files when rendering the changelog.

I'd like to add this feature to changie as well.

Describe the solution you'd like

I've been playing around in the changie codebase and my current thinking for this feature is the following:

Add a new config section to ".changie.yaml" called "GitHub" with two nested fields "Organization" and "Repository". If both of these are set then when loading changes from fragment files try to lookup what commit sha added that file via the local .git information (can use go-git for this), then query GitHub for what pull requests are associated with that commit and take the one that is merged.

There are some questions around what to do if a commit is referenced by multiple merged PRs? Should we return the earliest PR number or all?

Once the PR information is fetched add some extra template data when rendering the changelog. ".GitHub.PullRequest" which is the pull request number (or zero if one wasn't found) and ".GitHub.User" which is the user name associated with the pull request (or empty if no pull request was found).

Describe alternatives you've considered

My workaround to move to changie until this feature is in is I'm asking for pull request numbers as a a custom fragment entry. This is simple, and works but it means users have to push the change to make a pull request, see what pull request number they got, then create the changelog entry and re-push the change.

Additional context

You can see the code for our internal tool at https://github.com/pulumi/go-change/blob/main/internal/changelog/entry.go#L39.

[miniscruff]

Heyo Pulumi team, I would love to help but I do want to mention a few design rules of changie.

First, changie only reads, writes and deletes files. It does not know about git, hosting or even the output format of the files. With the exception of the yaml fragments.
Second, changie is highly configurable but not extensible as there is no way of adding plugins, or similar options. This one could in theory change but it's true for now.

So, with that said, adding go-git or any knowledge related to GitHub or any other host would go against the first point.

However, I know this has come up before, I believe dagger.io was looking for this as well. My usual suggestion is to just use an issue number instead but changing to issues may not be an option.

Brainstorming a little the option I would try out is to use an action to automatically add pr numbers to change fragments using a tool like yq for yaml parsing and updating. I would be willing to build an example and add that as a guide.

Not sure what other option exists without breaking rule one. And without any sort of plugin support adding that is also not possible.

[Frassle]

So, with that said, adding go-git or any knowledge related to GitHub or any other host would go against the first point.

I can respect that. Strong design guidelines generally lead to better tools so I do not want to be pushy about this.

I believe dagger.io was looking for this as well.

Interesting, I'll give this issue link a post on their discord see if they have anything to chime in here.

My usual suggestion is to just use an issue number instead but changing to issues may not be an option.

Yes I saw that was what changie was doing, and it seems fairly reasonable. I'll definitely talk to the team about if we want to just do that instead as an option.

Brainstorming a little the option I would try out is to use an action to automatically add pr numbers to change fragments using a tool like yq for yaml parsing and updating. I would be willing to build an example and add that as a guide.

I don't think I know GitHub actions well enough to see what you mean here? Are you suggesting having an action run on the PR merge to edit the yaml file with the PR number just before it commits to master? It's an interesting idea, I wouldn't worry about taking the time to build a concrete example for it just yet though.

Not sure what other option exists without breaking rule one. And without any sort of plugin support adding that is also not possible.

I was musing about plugin systems and thought this might be doable with just a very simple system. List a keyed executable in the .changie.yml config, for each change call that executable with the JSON marshaled Change struct written to its stdin and read a new JSON object from stdout that would be added to the change data under an extensions key. So you'd get something like, changie.yml:

extensions:
  github: changie-github-ext

On loading the Change call changie-github-ext with stdin set to the json string of the Change (including the filename), read stdout and add the json result from that Change.Ext["github"].

An idea, but I'll talk to our team some more about this and see if dagger have any input before saying its wise to action anything here.

[Frassle]

Linking a dagger issue about their use of PR numbers to this: dagger/dagger#5475

[miniscruff]

The action would do:
On push to my pr
For each new changie file
Update the fragment with the pr version
Push the change back to GitHub

That's all.

[Frassle]

The action would do:

Ah yeh that doesn't seem too complex. I'll be sure to add that to list of possibilities to discuss internally. Thank you.

[miniscruff]

Hey @Frassle just reaching out to see if there was any updates, still around here if you need any help.

[Frassle]

We're trying it out in https://github.com/pulumi/pulumi-dotnet, with just the manual "push once get a PR number, create changelog, push again" workflow for now.
The autofix changelogs in PR workflow is interesting, but not so needed that we felt we needed to spend the time writing it right now.
It does feel like it would make a good reusable action though, if we get around to writing it first we'll probably go in that direction.

[miniscruff]

Sounds good, I might try and write it up myself soon for fun. Will let you know if I do.