rm misleading doc about paths and paths-ignore

[ryanking]

I would love for this PR to include a suggestion of better content here, but I don't know that it exists. Also, I would be open to editing to just add a large caveat about the problems with this approach.

In short, this approach is un-safe because paths and paths-ignore don't work the way these docs suggest then do. From the docs for paths-ignore:

When all the path names match patterns in paths-ignore, the workflow will not run. If any path names do not match patterns in paths-ignore, even if some path names match the patterns, the workflow will run.

(emphasis mine)

This means that if you change any file not listed in paths or paths-ignore, both workflows will run.

Running both is probably fine, except for a few things:

1. it violates user expectations - at least, that was not my expectation from reading this section of docs
2. it will hide real failures. For example if both workflows run, the "skip" one succeeds, but the "real" one fails due a parsing error, you will get a successful status check on your PR (tested - this is how I went down this rabbit hole)
3. it is a race condition - what if you have auto-merge turned on? The "skip" workflow is almost certain to finish faster leading to a merged PR before the other workflow is done. (not tested)

The only alternative I have heard (from a coworker) is to use paths and negation (!) instead of paths-ignore. I don't think that would work because paths-ignore is an OR not an AND. You need to negate the whole list, not each item individually (!(a || b) rather than (!a || !b)).

Check off the following:

• [ ] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
• [ ] For content changes, I have completed the self-review checklist.

[welcome[bot]]

Thanks for opening this pull request! A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[github-actions[bot]]

Automatically generated comment ℹ️

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

---

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source	Preview	Production	What Changed
repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks.md	fpt ghec ghes@ 3.6 3.5 3.4 3.3 3.2 ghae	fpt ghec ghes@ 3.6 3.5 3.4 3.3 3.2 ghae

---

fpt: Free, Pro, Team ghec: GitHub Enterprise Cloud ghes: GitHub Enterprise Server ghae: GitHub AE

[cmwilson21]

@ryanking Thanks so much for opening a PR! We appreciate all the detailed information, too. I'll get this triaged for review :zap:

[fr33zespace]

Automatically generated comment

This comment is automatically generated and will be overwritten every time changes are committed to this branch.

The table contains an overview of files in the content directory that have been changed in this pull request. It's provided to make it easy to review your changes on the staging site. Please note that changes to the data directory will not show up in this table.

Content directory changes

You may find it useful to copy this table into the pull request summary. There you can edit it to share links to important articles or changes and to give a high-level overview of how the changes in your pull request support the overall goals of the pull request.

Source Preview Production What Changed repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks.md fpt ghec ghes@ 3.6 3.5 3.4 3.3 3.2 ghae fpt ghec ghes@ 3.6 3.5 3.4 3.3 3.2 ghae fpt: Free, Pro, Team ghec: GitHub Enterprise Cloud ghes: GitHub Enterprise Server ghae: GitHub AE

https://github.com/github/docs/projects/2#card-61800482

[fr33zespace]

https://github.com/github/docs/projects/2#card-61800482

[fr33zespace]

\www.dnschecker.org/

[fr33zespace]

Mathew is in the lower right hand corner emulating with my software package apo

[muzaffer015]

https://www.bayindir.com

[muzaffer015]

.patch.https://www.bayindir.com

[lucascosti]

👋 Thanks for this PR, @ryanking. In the absence of product behavior changing, removing this section probably isn't helpful.

I think the intention of the two workflow workaround is to have complete coverage of the repository between them.

i.e. the second workflow should cover all repository contents in its paths-ignore that that first workflow doesn't include in its paths.

In that case, the situation of if you change any file not listed in paths or paths-ignore wouldn't be possible.

This isn't explicitly mentioned in the doc, so I think a better update would be to add it. Let us know if you'd like to update your PR.

Thanks again 🙇‍♂️

[lecoursen]

I'm going to close this PR for now. If you decide to update it as described by @lucascosti in https://github.com/github/docs/pull/21515#issuecomment-1299666508, feel free to reopen! Thanks again for your interest in GitHub Docs!