GitHub Community
Attach metadata to PR (other than status), or close / comment without notification? #24828
-
|
When using an external tool to handle the PR integration process (see: Not Rocket Science Rule to Software Engineering) the external tool has to close the PR explicitly and should probably indicate where / how the PR was integrated (e.g. the hash of the merge / rebase / squash commit). Via the API, this requires two calls: to change its state to closed then to add a comment providing relevant information. This, in turn, generates two notifications to every follower of the PR for what is essentially a single event. On busy repositories, this generates a lot of spam (even more so when using a tool like CPython’s Miss Islington which semi-automatically creates backports for PRs, backports onto which the original contributors likely get automatically pinged. For instance python/cpython#16597 tags the original contributor & the original reviewer in comments, leading to them getting all messages by default, and thus a lot of churn. Even more so as PR notifications / pings tend to be relevant / high-SNR information (people or colleagues bringing up issues or asking for information / feedback) and would thus be amongst the last to be binned or web-only. Alternatively, I’m also open to an other way (than a comment) of adding relevant information to the PR, edirting an existing comment (or the PR message) feels distasteful and adding such meta-information as status seems like a misuse of the feature, not to mention statuses apparently disappear / get suppressed when a PR is closed or merged which rather defeats the intent as we specifically want to tell users where the pull request was actually integrated into the history proper. |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
|
I’m not entirely certain what you mean by “integrated” since that is a fairly overloaded term. But you may want to look at the Deployments API if you haven’t already? It sounds like what you want is some sort of “after the PR is merged” process, so this might be what you’re looking for? Let us know if you have more questions. |
Beta Was this translation helpful? Give feedback.
-
|
That does look extremely interesting, are deployments visible but silent to followers of the PR (aka some sort of link is visible on the PR, but the information is not pushed to followers)? If that’s the case, not only would that suit my needs perfectly, it might provide QoL improvements to various ancillary tasks. I can’t believe I missed this thing. |
Beta Was this translation helpful? Give feedback.
-
|
@lee-dohmafter some testing deployments do seem to fit the bill, however some bits are a bit unclear e.g. the descriptions (on deployment & deployment statuses) don’t seem to be used anywhere, and only the “environment”, “state” and “target_url” look relevant from an UI perspective (rather than automated tooling), is that correct? |
Beta Was this translation helpful? Give feedback.
-
|
To be honest, I don’t know if all the fields are used in the UI or not. I believe the description would show up in the deployments UI for the repository, if used. None of the tools that I’ve employed use the description field though, so I’m not certain. |
Beta Was this translation helpful? Give feedback.
I’m not entirely certain what you mean by “integrated” since that is a fairly overloaded term. But you may want to look at the Deployments API if you haven’t already? It sounds like what you want is some sort of “after the PR is merged” process, so this might be what you’re looking for?
Let us know if you have more questions.