I’m working on a pull request with a minor change to the community.general.ini_file module. According to Creating a changelog fragment,
The file name should include the PR number and a description of the change.
The description of the change is no problem, but how can I create a file with the pull request number in the name before submitting the pull request? I won’t know the PR number until I create the PR.
Implement your changes, create a PR and then add the changelog fragment in a second commit.
I’m not sure about this requirement. I always thought it’s mainly there to ensure uniq file names. Sometimes, you also see changelog fragments using the issue number that the PR fixes / implements. But I don’t know how the maintainers of community.general work and if they would accept this.
Using another commit (for force-pushing to update if you want to have everything in one) is what most people do.
You can also guess the PR number by looking at the last issue/PR number used in Issues · ansible-collections/community.general · GitHub, and incrementing that by one. In case nobody creates a new PR/issue between you looking at that page and creating your PR, that will be the number your PR gets I’m using this approach when creating PRs for ansible/collection PRs and it mostly works fine (in the very few cases it does not I’ll have a bit more work to update the number).
In general it’s also OK if you don’t have the PR number in the filename, but the file itself still has to include the PR URL (and the issue URL if that exists).
Yes, I think that is really important. Since the fragment turns up in the changelog, it’s easier for people to read up on what and why changed in detail if they wish to.
Although I usually include just the issue URL if one exists (the PR is just one click away since they’re linked) and the PR URL if I implement stuff without having an issue in community.vmware.