[outdooracorn]

Check PR description for a Phabricator task Git trailer in the format expected by the community commit message guidelines (Bug: T####)1

Bug: T443397

[github-actions]

@outdooracorn, please add any related Phabricator tasks as git trailers at the end of the PR description, separated from the text by a blank line.

For example (replace the example task IDs with your related tasks):

Example PR description text

Bug: T12345
Bug: T67890

You can also create a new task with the same title and description as this PR using the link below, then add its task ID as a Bug: trailer:

• Create task in the "Waiting for Peer Review" column

[deer-wmde]

I'm still a bit curious why we'd do the "Bug: " notation instead of a plain link

[outdooracorn]

I'm still a bit curious why we'd do the "Bug: " notation instead of a plain link

The main reason for me is that it follows the commit message guidelines of the movement:

• https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines
• https://wikitech.wikimedia.org/wiki/GitLab/Webhooks#Phabricator
• https://www.mediawiki.org/wiki/Commit-message-validator

I don't think we should do something different to what the rest of the community is expecting as it will likely mean we we won't be able to make use of existing tools / scripts / services / libraries / etc. that expect this format, especially if we want to move our repos over to one of the WMF hosted git forge. For example, the wmde-github-phab-bot we use to comment on a Phabricator tasks when a PR is opened.

I don't know the exact reason why the "T####" ID was chosen over the URL but some plausible reasons that come to mind:

• The URL might change (e.g. if it is renamed from https://phabricator.wikimedia.org to https://phorge.wikimedia.org now that the upstream Phabricator project has stopped development).
• It might be easier for bots / scripts to use the "T####" ID rather than the URL. It's probably easier to do URL + "T####" ID over extracting the "T####" ID from a URL.
• According to this reply from Krinkle, there is "a long standing tradition in software development to refer to tickets and issues by ID" and desire to support/maintain a single pattern.
• The "T####" ID is easier to type.

---

How come you would rather use URLs over the "T####" ID?

There are settings and plugins for IDEs that allow you to define the mapping between "T####" ID and URL.
It's a shame that our wbstack org doesn't have the same tier of GitHub as the wmde org that allows for us to make "T####" IDs render as links in the GitHub UI. We could move our repos over to the wmde org, but if we are going through the effort of moving, it's probably better to just move straight to whichever non-GitHub forge we want to use long-term.

[deer-wmde]

There are settings and plugins for IDEs that allow you to define the mapping between "T####" ID and URL.

And a link just works, anywhere.

It's a shame that our wbstack org doesn't have the same tier of GitHub as the wmde org

Then it still would be dependent on a GitHub feature.

there is "a long standing tradition in software development to refer to tickets and issues by ID"

Right, and if we would use GitHub for our tasks or Phabricator for our code, this would work well. That's what we keep working around.

[outdooracorn]

I'm still of the opinion that we should follow the same guidelines as the rest of the technical wiki community so that we don't have to reimplement existing tooling, but let's discuss.

[deer-wmde]

I'm still of the opinion that we should follow the same guidelines as the rest of the technical wiki community so that we don't have to reimplement existing tooling, but let's discuss.

that sounds like a good point. What existing tooling is affected? +1 on discussing this with the team at some point

[github-actions]

@outdooracorn, please add any related Phabricator tasks as git trailers at the end of the PR description, separated from the text by a blank line.

For example (replace the example task IDs with your related tasks):

Example PR description text

Bug: T12345
Bug: T67890

You can also create a new task with the same title and description as this PR using the link below, then add its task ID as a Bug: trailer:

• Create task in the "Waiting for Peer Review" column

[github-actions]

@outdooracorn, please add any related Phabricator tasks as git trailers at the end of the PR description, separated from the text by a blank line.

For example (replace the example task IDs with your related tasks):

Example PR description text

Bug: T12345
Bug: T67890

You can also create a new task with the same title and description as this PR using the link below, then add its task ID as a Bug: trailer:

• Create task in the "Waiting for Peer Review" column

[tarrow]

Looks fine to me and I think it's better that we try this than debate over the idea since the risk is so small and getting rid of it again is easy.

However I nerd sniped myself into understanding the GH actions permissions. Tried and succeeded with a change that I now need @AndrewKostka or @dati18 to review.

Also tried to directly use the ${{ secrets..GITHUB_TOKEN }} in the workflow definition but failed at that and decided to give up since I already sunk so much time.

[dati18]

PR description was updated. github_action bot is happy now :)
Overall I think it's a welcoming change. Maybe implement this for other repos as well

[outdooracorn]

Also tried to directly use the ${{ secrets..GITHUB_TOKEN }} in the workflow definition but failed at that and decided to give up since I already sunk so much time.

I did think about if there was a nicer way to use the GitHub token than defining a new environment variable. I created this as a separate bash script, not inline in the workflow definition, so I wonder if this didn't work because secrets is not made available to the script?

I used a separate bash script as it's easier to parse the workflow file when it doesn't contain long scripts, it will be easier to run linting on a separate bash script than an inline bash in a YAML file, and you don't have to deal with YAML indenting.