[llvm][GitHub] Fix formatting of new contributor comments

GitHub won't reflow the text unless we put it all on one line.

If we try to make our own paragrpahs it comes out too narrow or
too wide.

[workflows] Fix release note request workflow (#94784)

We need to use the issue-write workflow to write the comments, because
pull_request targets don't have permissions to write comments.

[workflows] Add a job for requesting a release note on release branch PRs (#91826)

We have been collecting release notes from the PRs for most of the
18.1.x releases and this just helps automate th

[workflows] Add a job for requesting a release note on release branch PRs (#91826)

We have been collecting release notes from the PRs for most of the
18.1.x releases and this just helps automate the process.

show more ...

[GitHub] Fix typos in automation (#86886)

[GitHub] Allow shortcut for "introductory issue" and request linking to issue in PR (#84635)

The answer to many requests in issues to be assigned to users is often
"just create a pull request". Tha

[GitHub] Allow shortcut for "introductory issue" and request linking to issue in PR (#84635)

The answer to many requests in issues to be assigned to users is often
"just create a pull request". That's in contradiction to the
"introductory issue" instructions posted by the GitHub bot.

This change updates the instructions, mentioning the shortcut of "just
creating a PR". Moreover, it now explains linking PRs to issues in order
to close them automatically upon merge.

show more ...

github-automation.py: Set maintainer_can_modify=True for backport PRs (#84819)

This makes it possible to rebase the branch using the Web UI, which
makes it easier to manually merge the PRs. Manual

github-automation.py: Set maintainer_can_modify=True for backport PRs (#84819)

This makes it possible to rebase the branch using the Web UI, which
makes it easier to manually merge the PRs. Manual merge is required when
squash merge won't preserve author information of the backport.

show more ...

[Github Automation] Allow colon after cherry-pick command (#81002)

Fixes: https://github.com/llvm/llvm-project/issues/64803

Removed unsupported branch command and changed Regex to
accept /cherry

[Github Automation] Allow colon after cherry-pick command (#81002)

Fixes: https://github.com/llvm/llvm-project/issues/64803

Removed unsupported branch command and changed Regex to
accept /cherry-pick: command.

show more ...

Revert "[GitHub][workflows] Ask reviewers to merge PRs when author cannot (#81142)"

This reverts commit 38c706e30f5f339bfb0bfb26fd7b5c2d5086064a.

This workflow always fails in cases where it needs

Revert "[GitHub][workflows] Ask reviewers to merge PRs when author cannot (#81142)"

This reverts commit 38c706e30f5f339bfb0bfb26fd7b5c2d5086064a.

This workflow always fails in cases where it needs to create a
comment, due to a permissions issue, see the discussion at:
https://discourse.llvm.org/t/rfc-fyi-pull-request-greetings-for-new-contributors/75458/20

show more ...

[GitHub][workflows] Ask reviewers to merge PRs when author cannot (#81142)

This uses
https://pygithub.readthedocs.io/en/stable/github_objects/Repository.html?highlight=get_collaborator_permission#g

[GitHub][workflows] Ask reviewers to merge PRs when author cannot (#81142)

This uses
https://pygithub.readthedocs.io/en/stable/github_objects/Repository.html?highlight=get_collaborator_permission#github.Repository.Repository.get_collaborator_permission.

Which does
https://docs.github.com/en/rest/collaborators/collaborators?apiVersion=2022-11-28#get-repository-permissions-for-a-user
and returns the top level "permission" key.

This is less detailed than the user/permissions key but should be fine
for this
use case.

When a review is submitted we check:
* If it's an approval.
* Whether we have already left a merge on behalf comment (by looking for
a hidden HTML comment).
* Whether the author has permissions to merge their own PR.
* Whether the reviewer has permissions to merge.

If needed we leave a comment tagging the reviewer. If the reviewer also
doesn't have merge permission, then it asks them to find someone else
who does.

show more ...

[workflows] Create a more descriptive title and body when creating a PR for backports (#80396)

When a backport request is made, the resulting pull request will have a
title like this:

<release b

[workflows] Create a more descriptive title and body when creating a PR for backports (#80396)

When a backport request is made, the resulting pull request will have a
title like this:

<release branch>: <First line of HEAD commit for the branch>

And a body that says:

Backport <commit0> <commit1> ..

Requested By: <user>

show more ...

[workflows] Close issues used for backports once the PR has been created (#80394)

This will allow us to track the state of the backport request in the PR,
rather than in the issue. The state update

[workflows] Close issues used for backports once the PR has been created (#80394)

This will allow us to track the state of the backport request in the PR,
rather than in the issue. The state updates for PRs can be automated, so
this will save us some triage work.

show more ...

[GitHub][workflows] Reflow some text in buildbot info PR comment

When the markdown link renders the line gets a lot shorter.

[GitHub][workflows] Add buildbot information comment to first merged PR from a new contributor (#78292)

This change adds a comment to the first PR from a new contributor that
is merged, which tells

[GitHub][workflows] Add buildbot information comment to first merged PR from a new contributor (#78292)

This change adds a comment to the first PR from a new contributor that
is merged, which tells them what to expect post merge from the build
bots.

How they will be notified, where to ask questions, that you're more
likely to be reverted than in other projects, etc. The information
overlaps with, and links to
https://llvm.org/docs/MyFirstTypoFix.html#myfirsttypofix-issues-after-landing-your-pr.
So that users who simply read the email are still aware, and know where
to follow up if they do get reports.

To do this, I have added a hidden HTML comment to the new contributor
greeting comment. This workflow will look for that to tell if the author
of the PR was a new contributor at the time they opened the merge. It
has to be done this way because as soon as the PR is merged, they are by
GitHub's definition no longer a new contributor and I suspect that their
author association will be "contributor" instead.

I cannot 100% confirm that without a whole lot of effort and probably
breaking GitHub's terms of service, but it's fairly cheap to work around
anyway. It seems rare / almost impossible to reopen a PR in llvm at
least, but in case it does happen the buildbot info comment has its own
hidden HTML comment. If we find this we will not post another copy of
the same information.

show more ...

[workflows] Drop the intermediate /branch comment for release workflow (#79481)

We used to support a /branch comment to specify a branch with commits to
backport to the release branch. However, now

[workflows] Drop the intermediate /branch comment for release workflow (#79481)

We used to support a /branch comment to specify a branch with commits to
backport to the release branch. However, now that we can use pull
requests this is not needed.

This also simplifies the process, because now the cherry-pick job can
create the pull request directly instead of having it split across two
separate jobs.

show more ...

Remove fork handling from release issue workflow (#79310)

This is currently broken, because the check is performed on the wrong
repository. repo here is llvm/llvm-project, which is not a fork (so t

Remove fork handling from release issue workflow (#79310)

This is currently broken, because the check is performed on the wrong
repository. repo here is llvm/llvm-project, which is not a fork (so this
will always trigger), then we'll push a new branch to
llvmbot/llvm-project, and then again set the wrong owner, so we'll look
for the branch in llvm/llvm-project rather than llvmbot/llvm-project.

Rather than fixing this, I'm removing the code entirely, as it shouldn't
be needed anymore (llvmbot/llvm-project is a fork of llvm/llvm-project).

show more ...

Fix release issue workflow (#79268)

Remove the `--phab-token` argument (which currently eats the subsequent
"auto" as the token no longer exists) and related code.

I think this will fix the work

Fix release issue workflow (#79268)

Remove the `--phab-token` argument (which currently eats the subsequent
"auto" as the token no longer exists) and related code.

I think this will fix the workflow failure in
https://github.com/llvm/llvm-project/issues/79253#issuecomment-1907679229.

show more ...

github-automation: Use the llvm/llvm-project repo for backport pull requests (#71727)

Now that the project uses PRs for code review, we don't need to use the
llvm/llvm-project-release-prs repo for

github-automation: Use the llvm/llvm-project repo for backport pull requests (#71727)

Now that the project uses PRs for code review, we don't need to use the
llvm/llvm-project-release-prs repo for reviewing backports.

show more ...

[GitHub] Add greeting comment to opened PRs from new contributors (#72384)

This includes some commonly needed information like how to add
reviewers.

This is implemented as a job before the label

[GitHub] Add greeting comment to opened PRs from new contributors (#72384)

This includes some commonly needed information like how to add
reviewers.

This is implemented as a job before the labeler, so that on a new PR the
comment is added before there are any subscribers and only the author
gets a nofitication.

The labeler job depends on the greeter having run or having been
skipped. So if the PR wasn't just opened, or it's from a regular
contributor, the labeling still happens.

But we can be sure that when a greeting comment is left, it's the very
first thing we do.

show more ...

[GitHub] Use proper Markdown syntax and avoid child list items (#73700)

[GitHub] Update bot message to suggest GitHub pull requests (#65914)

Fixes #65890.

---------

Co-authored-by: Danny Mösch <danny.moesch@icloud.com>

Try to fix good-first-issue bot (#71816)

The previous code was just overriding the `comment` variable. Fix this by writing two comments if necessary instead.

[Github] Fix github automation script on empty descriptions (#71274)

Before this patch, the github automation script would fail when trying
to escape the text of a PR/issue description that was emp

[Github] Fix github automation script on empty descriptions (#71274)

Before this patch, the github automation script would fail when trying
to escape the text of a PR/issue description that was empty as the
Github library returns None instead of an empty string in those
scenarios. This patch special cases this and makes the escape function
return an empty string when given a value of None.

show more ...

[Github] Add PR author name to subscription email (#68440)

Currently the email that gets sent out to people subscribing to a label
that the bot tags on the PR doesn't include any authorship informa

[Github] Add PR author name to subscription email (#68440)

Currently the email that gets sent out to people subscribing to a label
that the bot tags on the PR doesn't include any authorship information
which some people are interested in having. This patch adds an author
field to the message with the relevant information.

show more ...

[Github] Add a new line before the line separator to avoid paragraphs being treated as titles

[Github] Fix issue number escaping