feat: Implement check-pr-title workflow#73
Conversation
mathbunnyru
changed the title
mathbunnyru
changed the title
| steps: | ||
| - uses: ytanikin/pr-conventional-commits@fda730cb152c05a849d6d84325e50c6182d9d1e9 # 1.5.1 | ||
| with: | ||
| task_types: '["build", "feat", "fix", "docs", "test", "ci", "style", "refactor", "perf", "chore"]' |
There was a problem hiding this comment.
Since the rippled repo doesn't support the feat and style prefixes, can we allow the caller to set the task types as an input?
One option would be to have a comma-separated list as input, and another would be to have a set of boolean inputs that all default to true but which can be easily overridden. You'd have to do some preprocessing before calling the action, but shouldn't be too much effort.
@ximinez: it would make sense for clio and rippled to support the same prefixes.
There was a problem hiding this comment.
feat is used though: XRPLF/rippled@ed5d6f3
git log | grep "feat: "
feat: Add public key to log messages (#5678)
feat: Install validator-keys (#5841)
* feat: Install validator-keys
feat: Implement separate upload workflow (#5762)
* feat: Implement separate upload workflow
feat: improve squelching configuration (#5438)
feat: add user version of `feature` RPC (#4781)
feat: allow `port_grpc` to be specified in `[server]` stanza (#4728)
feat: support Concise Transaction Identifier (CTID) (XLS-37) (#4418)
feat: mark 4 amendments as obsolete: (#4291)
I haven't found style:, but I think the easiest solution would be to just use the same list - it's been working well at Clio, and doesn't create confusion.
There was a problem hiding this comment.
Don't we already have the PR template to capture this information? So, either we keep using that or remove that?
I think the major use-case of this won't be just to identify PR category from title, but to also filter them in searches. Although, that can be done using string matching in title, but it is fragile. Filtering using labels though is much more robust. So, better way would be to just program the Copilot to analyze changes in PR and assign a label to it automatically. What do you think?
There was a problem hiding this comment.
Don't we already have the PR template to capture this information? So, either we keep using that or remove that?
I will remove that, that was my plan and part of the frustration. It will be a part of the rippled PR after this one gets merged.
I think the major use-case of this won't be just to identify PR category from title, but to also filter them in searches. Although, that can be done using string matching in title, but it is fragile. Filtering using labels though is much more robust. So, better way would be to just program the Copilot to analyze changes in PR and assign a label to it automatically. What do you think?
Since we don't know yet how to launch Copilot using corporate tokens, I think it might be a further improvement, not something that can be implemented right now.
There was a problem hiding this comment.
We should ask developers to follow this workflow then. Also, check this out: #76
There was a problem hiding this comment.
We should ask developers to follow this workflow then.
What do you mean?
It will be automatic workflow that verifies that PR title is as expected, and if everything's good no action won't be needed, if not - they will get red CI (and will eventually fix it).
Also, check this out: #76
It looks like a reimplementation of add_label + custom_labels of the ytanikin/pr-conventional-commits.
I didn't want to add labels here, because neither Clio, nor rippled uses automatic labels for our own PRs right now, so I didn't want to deal with this problem.
There was a problem hiding this comment.
I meant the workflow of adding the Type of Change value or Label, so that we can use these values while filtering PRs. The PR I created automatically adds label, so dev. doesn't need to do it. This way we don't need to introduce the PR title requirements. Since the labels are more reliable and useful.
Besides, how would you tell a developer which prefix to use in the title of their change? Maybe by adding information regarding that in the PR template?
So, developers then need to read those details and then update the PR title accordingly. I would propose to keep the existing Type of Change section, let dev. select the correct option there, as they do now. Then the workflow script automatically apply the correct label to the PR. So, basically nothing changes for developers and we get what we want.
There was a problem hiding this comment.
@pratikmankawde let's discuss your suggestion offline & merge this PR to make things at least better going forward.
4 participants
No description provided.