Contributing update README.md #108
Conversation
|
|
||
| 1. Update `contributing_inputs.yaml` | ||
| 1. We can also update the `contributing.md` file directly if we like, if we want to avoid another PR |
There was a problem hiding this comment.
Do you think it'd make more sense to discourage people from editing it directly? Sort of defeats the purpose of this automation IMO.
There was a problem hiding this comment.
Yes. I do. I think this is a hacky use case as you mention in your other comment. I think the follow-on issue will address that, and the README will need to be updated when it's done.
For now though, I think it's best to document the action as it is today, seeing as it's already merged and this is how it actually works.
| 1. If the freshly generated `contributing.md`, based on the updated `contributing_inputs.yaml` plus the `contributing.md.template`, differs from `contributing.md`, the automation will catch this, and a PR will be opened to overwrite the existing `contributing.md` with the new one. | ||
|
|
||
| Note: the generate PR will target the `main` branch, BUT the target branch could always be changed to the same branch as the one updating `contributing_inputs.yaml`, and then merged into that without review, to avoid having two PRs to review. |
There was a problem hiding this comment.
Come on, even describing this feels super hacky 😂 I'd be all for setting this behaviour as the default though. I believe it's much better than either encouraging people to edit the contributing.md directly or manually directing the rendered file PR towards the one updating the inputs.
There was a problem hiding this comment.
Hmmm. You're right. I think it would be as simple as this: instead of targeting main, just target "Whatever branch you are currently on".
However, targeting main is how it works today :(
I really don't want to allow the scope of this PR to extend beyond simply updating the README to reflect the state of the already-merged action.
So, I've created an issue to change the action as you suggested: #109.
And then for this PR, I suggest we focus just on documenting the action as it is today.
There was a problem hiding this comment.
Actually, I may be wrong. I'm testing this out. I see from the PR action we're using that the default branch is the one from which the action is called:
| base | Sets the pull request base branch. | Defaults to the branch checked out in the workflow. |
|---|
So I'm testing this out in this workflow run.
Co-authored-by: Phoevos Kalemkeris <[email protected]>
Co-authored-by: Phoevos Kalemkeris <[email protected]>
|
Closing this as it's too much effort. We have decided for now to go with the simpler option of just manually creating and maintaining contributing files. |
No description provided.