Fix some typos (#123506)

Fixes some typos in the documentation

[Doc] Add a section on CI to the GitHub documentation (#85376)

See
https://discourse.llvm.org/t/rfc-add-a-warning-when-bypassing-the-premerge-testing/77610
for context.

[github] Document the process for requesting the CI/CD role (#115321)

See https://discourse.llvm.org/t/rfc-proposing-a-new-ci-cd-admin-for-the-project

[llvm][docs] Add Approvals section to GitHub guide (#113434)

Based on feedback that when reading the document as a guide, it's odd
that it skips right from updating the PR to merging it.

The sec

[llvm][docs] Add Approvals section to GitHub guide (#113434)

Based on feedback that when reading the document as a guide, it's odd
that it skips right from updating the PR to merging it.

The section is a link to the existing Code Review guide's text on the
topic.

I have updated that to mention required reviewers, which some
subprojects do use (libcxx is one) but most don't.

Also we use the words "accepted" and "approved" interchangeably, so I've
swapped one instance so it's consistent between paragraphs.

show more ...

[llvm][docs] Clean up the "Landing Your Change" section of the GitHub docs (#112869)

* Note up front that the author may not have permissions to use the
merge button and should ask a reviewer to do

[llvm][docs] Clean up the "Landing Your Change" section of the GitHub docs (#112869)

* Note up front that the author may not have permissions to use the
merge button and should ask a reviewer to do those steps.
* Make it clear that a single commit PR can be landed with a single
button click.
* There are in fact 3 ways to land a multi-commit PR.
* Order the ways in increasing amount of overhead for the PR author.
* Put them in bullet point sections so they are visually separate.
* Add a note that force pushes can be problematic when the PR has multiple authors, but don't go too much into how to solve that, Git's docs are better here anyway.

show more ...

[docs] Fix links in github user guide - graphite section

Mistakenly used markdown style rather than rst in #104499.

[docs] Stress out the branch naming scheme for Graphite. (#104499)

This should make this nuance more discoverable, if the user's first instinct is to search for "Graphite" rather than "stacked revie

[docs] Stress out the branch naming scheme for Graphite. (#104499)

This should make this nuance more discoverable, if the user's first instinct is to search for "Graphite" rather than "stacked reviews"

show more ...

Update the backporting docs (#100401)

The documentation implies the special commands only work with issues,
but they also work directly from a pull request.

llvm/docs: Try to fix some broken links

I messed up the syntax here previously - let's see if this is enough to
get it working.

Document use of `skip-precommit-approval` label for non-review pull requests (#81053)

Derived from this discussion:
https://discourse.llvm.org/t/prs-without-approvals-muddy-the-waters/76656

[llvm][Docs] Expand MyFirstTypoFix's post-commit section (#79827)

And link to it from the GitHub guide. Since it fits in the flow of the
former document better, but is of interest to those using th

[llvm][Docs] Expand MyFirstTypoFix's post-commit section (#79827)

And link to it from the GitHub guide. Since it fits in the flow of the
former document better, but is of interest to those using the GitHub
specific guide.

This includes some content I wrote for an automated PR comment but I
think is useful to have in a single place to link to instead.

I have removed some details:
* About the waterfall view because it doesn't seem that useful to new
contributors and is likely to just seem like constant chaos given how
many builds are going on.
* The orange bubbles in the console view. I also remember this being the
case but whether it was changed, or the web UI is just not loading
properly, I now see red builds that were red before that commit. So
again, it seems like detail that's not needed for a new contributor.

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 ...

Update GitHub doc to mention that we accepts user branches for Stacked PRs (#73774)

This isn't yet a guide on how to do stacked PRs.

[docs] Advise contributors to check for truncated PR titles (#68021)

GitHub will use the first line of the commit as the title for a
single-commit PR, but truncates it at 72 characters
<https://gi

[docs] Advise contributors to check for truncated PR titles (#68021)

GitHub will use the first line of the commit as the title for a
single-commit PR, but truncates it at 72 characters
<https://github.com/orgs/community/discussions/12450>. This truncation
makes the PRs less readable if not manually undone, and even worse, the
truncated form may survive through to commit if "Squash and rebase" is
used in the GitHub web UI. From preparing LLVM Weekly, I've seen this a
number of times and it really does make it more annoying to flick
through commits.

I'm not sure if this is the best place for the guidance, or whether you
get the same behaviour when creating a PR with `gh`, but I'm quite keen
we give a warning of some sort about this behaviour.

show more ...

[Docs][Github] Say '--delete-branch' instead of '--delete' and '--delete branch'

The documentation for how to use "gh pr merge" was broken.
In one place it said '--delete-branch' (which seem to be c

[Docs][Github] Say '--delete-branch' instead of '--delete' and '--delete branch'

The documentation for how to use "gh pr merge" was broken.
In one place it said '--delete-branch' (which seem to be correct for
that option). But in second place it said '--delete branch' and in a
third place it just said '--delete'.
Make sure '--delete-branch' is used in all three places.

show more ...

[Docs][Github] explain how to rectify gh pr merge failure (#66223)

I recently went to merge a PR that had a merge conflict:

$ gh pr merge --squash --delete-branch
X Pull request #66003 is not m

[Docs][Github] explain how to rectify gh pr merge failure (#66223)

I recently went to merge a PR that had a merge conflict:

$ gh pr merge --squash --delete-branch
X Pull request #66003 is not mergeable: the merge commit cannot be
cleanly created.
To have the pull request merged after all the requirements have been
met, add the `--auto` flag.
Run the following to resolve the merge conflicts locally:
gh pr checkout 66003 && git fetch origin main && git merge origin/main

This is how I resolved it; we should recommend this explicitly for
fellow contributors.

show more ...

Clariy the GitHub PR doc that a "single commit" is only the expected initial state

Review rounds can add more commits, this addresses a post-merge comment.

Aligning the section about pull-request with the `gh` tools with the section using the web UI (#65795)

This is fairly minor, but start addressing the post-review comments

[llvm][Docs] Fix missing ' in GitHub documentation

[Docs] Add example of making a PR with git and GitHub web interface (#65393)

Some people may not have access to `gh` or may prefer to use `git` and
the GitHub web interface to make a PR. This patch

[Docs] Add example of making a PR with git and GitHub web interface (#65393)

Some people may not have access to `gh` or may prefer to use `git` and
the GitHub web interface to make a PR. This patch adds an example of
making a PR using this approach.

show more ...

[Docs] Update documentation for the new GitHub workflow (#65162)

This adds first version of a GitHub workflow in the documentation and marks some
sections as deprecated. We should clean up these se

[Docs] Update documentation for the new GitHub workflow (#65162)

This adds first version of a GitHub workflow in the documentation and marks some
sections as deprecated. We should clean up these sections ASAP. I was
just keen to get something on the documentation site as soon as
possible.

show more ...

[doc] Fix link typo

[doc] Give better info about forks

Differential Revision: https://reviews.llvm.org/D153884

docs: Document procedure for updating pull requests

See discussion in #56637.

Reviewed By: ldionne, jhenderson

Differential Revision: https://reviews.llvm.org/D147284

docs: Document policy around GitHub branches

See discussion in #56643.

Reviewed By: rengolin, jhenderson, ldionne

Differential Revision: https://reviews.llvm.org/D147276