Input on including the PR number in the changelog yaml.

[emmyoop]

Wondering if anyone might have an idea of how to implement below for the best user experience. This is more of an GitHub Actions question than strictly changie.

Within my custom fields, I want to include the PR number related to the change.

custom:
  - key: Author
    label: GitHub Username(s) (separated by a single space if multiple)
    type: string
    minLength: 3
  - key: Issue
    label: GitHub Issue Number
    type: int
    minLength: 4
  - key: PR
    label: GitHub Pull Request Number
    type: int
    minLength: 4

The problem is I audit if a changelog exists on the PR with GitHub actions so everyone gets a failed check when they open the PR since they cannot include the PR number before the PR exists.

This is obviously not stopping us from using changie. There are work arounds - opening the PR in draft stops the check from running & generating the changie yaml with a fake PR number (or I could make it optional and it could then be blank) - but these don't feel great.

What I'd like is to auto populate the PR number with an action. The problem here is we are an open source project that gets many community contributions from forks. So I won't be able to just add a commit to the PR with the changelog modified. I don't think I could do it after I merge into main (where I have control) because I would no longer have access to the PR number.

Any ideas on a solution here?

[miniscruff]

So having thought about this for a few days given I was on vacation I have a few things.
First, minLength does nothing if the type is not string, you should be using minInt https://changie.dev/config/#custom-minint.

Next, for the project Changie it only uses the issue key for a few reasons as you have alluded to. There is no PR number to enter until you have created a PR after the change is complete. And for me, pull requests are technical details not related to the end user, for me that is the issue. There was an issue and now it is resolved, if you want to read about the issue you can. The PR is linked to the issue yes, but that is more of a technical thing.

Now if your project wants to include the PR I can only really think of two methods.

1. Create PRs in draft or normal mode, maybe give a few reviews, then once the PR is about to be merged, create the changie fragment. This also keeps the date of the changie fragment closer to the merge time which is ideal. Could create a Github tag for "waiting changie fragment" to indicate the PR is done and can be merged once a fragment is created and values approved.
2. Create a changie fragment where you put in some estimate for the PR, then force push a change with the proper PR number if you were incorrect. This sort of works because issue and PRs are incremental so it is not too hard to guess, but it would require editing a yaml file which goes around any changie validation checks you may have.

I would not auto populate or auto build any changie fragments, but that is just me.