github / docs Goto Github PK

What feature or product is affected?

The managing-your-work-on-github/linking-a-pull-request-to-an-issue.md page which covers how special keywords can be used in pull request descriptions.

Basically, the code looks in the description for special terms and parses them to create links to issues, and additionally, issues are closed when the pull request is merged.

The special keywords in a pull request description are interpreted when the pull request targets the repository's default branch.

However, if the PR's base is any other branch, then these keywords are ignored, no links are created and merging the PR has no effect on the issues.

What is the new or expected behavior?

In particular, we should mention that both linking and closing behaviours only apply to PRs that target the repository's default branch.

Secondly, IMHO this condition is important enough that we should also highlight it, perhaps in a big yellow box or similar. Having it in a single sentence as part of a paragraph makes it much too easy to miss.

How is the old or inaccurate behavior currently documented?

In managing-your-work-on-github/linking-a-pull-request-to-an-issue.md, the first section mentions that issues can be linked from a pull request. However, this is misleading and incomplete, as it does not say that this only happens when the PR base branch is the repository default branch.

The closing section does allude to the behaviour when it says:

When you merge a linked pull request into the default branch of a repository, its linked issue is automatically closed.

This is a single statement, so it is very easy to miss amongst the rest of the document and our documentation.

It is also very weakly stated - it only applies to one half the situation. This is not just an "if" condition, it is an "if and only if".

Content to update

In managing-your-work-on-github/linking-a-pull-request-to-an-issue.md:

• This doc does mention the default branch passively a number of times, but we should be more explicit in the fact that it only works on the default branch.
• Add a note or short paragraph at the top of "Linking a pull request to an issue using a keyword" that it must be on the default branch
• While we're in the article, lets update a line in Linking a pull request to an issue change the sentence to "You can link a pull request to an issue by using a supported keyword in the pull request's description or in a commit message."

What is the current behavior?

May I know the reason you guys are using blue color on sidebar? The background color is great but I think it has breached your design system which it supposedly to come in black.

What changes are you suggesting?

As a Product Designer myself, I think it's better to follow the GitHub design system for the documentation as well.

Additional information

What is the current behavior?

The docs repo is multi-licensed, MIT and CC-BY-4.0. The README outlines the situation but still many people and most tools (including GitHub's own licensee) will not recognize the current license structure where the two LICENSE files are in separate directories.

What changes are you suggesting?

The licenses should both be at the root in separate files (e.g., LICENSE and LICENSE-CODE). That makes it obvious to the repo browser that there are two licenses and enables licensee (and other tools/systems) to pick up the multiple licenses. There is a separate problem of updating the GitHub UI to deal with multiple licenses appropriately but that can be addressed separately.

What article on docs.github.com is affected?

File README.md at github/docs

What part(s) of the article would you like to see updated?

After opening a multitude of PRs without realizing there was a template for it, I was warned about the situation. I hadn't found a link or a reference to a PR template when reading the README.md file, and I probably missed it right before the PR submission since I was rapid-firing PRs. IMHO adding a reference to PR templates (in the same manner that it's done to Issues templates) would be beneficial for other users.

Additional information

None at this time.

What feature or product is affected?

Local and remote commits

What is the new or expected behavior?

A user has written in asking if the documentation at

https://help.github.com/en/github/committing-changes-to-your-project/changing-a-commit-message

could be updated to clearly spell out that instructions 1-5 of the section about changing old commits can be used locally, even though the section as a whole is for updating old remote commits.

Content plan

• We should make the headings H3 so that they show up in the TOC.

• It's not necessary to split heading by local / remote, as this is GitHub documentation. Instead, we can have the last step be:

  When you're ready to push your changes to GitHub, use the push --force command to force push over the old commit.
  $ git push --force example-branch

• Remove the warning box at the top of the guide "In Git, the text of the commit message is part of the commit..." to make it part of the content, and then add the warning box about force pushing.

• The titles should be changed to:

  • Changing the message of the most recently pushed commit - combines the content from here and "Amending the message of the most recently pushed commit"
  • Changing the message of older or multiple commit messages

What is the current behavior?

there are several places in the code where path.join is used in the creation of a URL. Unfortunately, on windows the path separator is ``` and that produces invalid URLs. While we may not intend the service to actually run on Windows, community members seeking to contribute and working on Windows will want to run the tests which expect valid URLs.

See the following for specific examples. There may well be more.

• https://github.com/github/docs/blob/main/middleware/archived-enterprise-versions.js#L72
• https://github.com/github/docs/blob/main/middleware/archived-enterprise-versions.js#L100

Unfortunately there are lots of legit uses of path.join so a simple search for that pattern is pretty noisy. I don't have a good enough handle on the codebase to easily identify which parts are likely to construct URLs.

Would be super interesting to have a CodeQL query that detects the use of path.join to create value that's eventually returned in a header or some such.

What changes are you suggesting?

cc: @github/docs-engineering

Issue party content strategy plan

Feedback on Downloading the CodeQL runner:

We say "You can download the CodeQL runner from ." Then we suggest how to change permissions before we run it. It would be great before we do that to provide a little wget script pointing to the latest release options so I can copy and paste it into my pipeline.

wget https://github.com/github/codeql-action/releases/download/codeql-bundle-20200826/codeql-runner-linux chmod +x codeql-runner-linux

Content plan

This requires changes to the Running code scanning in your CI system topic.

Audience

Anyone who's integrating code scanning into their CI/CD system where the system has access to GitHub.com, especially people who spin up a fresh VM for each run.

Content to update

Suggest splitting the current first paragraph in Adding the CodeQL runner to your CI system after the first sentence.

Then revise the first sentence to explain that each CI server that you intend to use for code scanning needs to have the CodeQL runner. You might configure each server to copy the runner from a central, internal location, or you could use the REST API to get the runner direct from GitHub, for example: wget script above.

Questions

None outstanding.

What feature or product is affected?

https://help.github.com/en/packages/publishing-and-managing-packages/about-github-packages#managing-packages

Please let me know if you want me to submit a PR for this as it is an easy fix.

What is the new or expected behavior?

Remove the a from the sentence
You can delete a version of a private package on GitHub

How is the old or inaccurate behavior currently documented?

There is an a in the sentence.
You can a delete a version of a private package on GitHub

https://help.github.com/en/packages/publishing-and-managing-packages/about-github-packages#managing-packages

Who does this affect?

100% of users

What is the impact to users?

Grammar and clarity

Note: The Doctocat who triages this issue may invite you to open a PR to address it. Doing so is absolutely not required, though it's helpful for a speedy fix! Someone from our team will work with you to take your changes across the finish line.

Content strategy and implementation

Please link any in-flight PRs to this issue.

The webpack setup logs a bunch of build info on local server startup. Maybe this output is useful, but I tend to never look at it. I noticed today that in some cases if there's an error in the app at startup, that error output can be scrolled offscreen by the webpack info, making it harder to notice:

~/git/github/docs-internal
$ npm start

> [email protected] start /Users/z/git/github/docs-internal
> cross-env NODE_ENV=development ENABLED_LANGUAGES='en,ja' nodemon server.js

[nodemon] 2.0.4
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,json,yml,md,html,scss
[nodemon] starting `node server.js`
ENABLED_LANGUAGES: en,ja
TypeError: Cannot read property 'some' of undefined
    at /Users/z/git/github/docs-internal/lib/all-products.js:62:99
    at Array.forEach (<anonymous>)
    at Object.<anonymous> (/Users/z/git/github/docs-internal/lib/all-products.js:33:18)
    at Module._compile (internal/modules/cjs/loader.js:868:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:879:10)
    at Module.load (internal/modules/cjs/loader.js:731:32)
    at Function.Module._load (internal/modules/cjs/loader.js:644:12)
    at Module.require (internal/modules/cjs/loader.js:771:19)
    at require (internal/modules/cjs/helpers.js:68:18)
    at Object.<anonymous> (/Users/z/git/github/docs-internal/middleware/robots.js:2:18)
    at Module._compile (internal/modules/cjs/loader.js:868:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:879:10)
    at Module.load (internal/modules/cjs/loader.js:731:32)
    at Function.Module._load (internal/modules/cjs/loader.js:644:12)
    at Module.require (internal/modules/cjs/loader.js:771:19)
    at require (internal/modules/cjs/helpers.js:68:18)
ℹ ｢wdm｣: Hash: 64200700e0691a191700
Version: webpack 4.44.1
Time: 4328ms
Built at: 09/22/2020 9:51:02 PM
                   Asset      Size  Chunks             Chunk Names
   fonts/Inter-Bold.woff   140 KiB          [emitted]  
 fonts/Inter-Medium.woff   139 KiB          [emitted]  
fonts/Inter-Regular.woff   131 KiB          [emitted]  
               index.css   311 KiB    main  [emitted]  main
                index.js  2.03 MiB    main  [emitted]  main
Entrypoint main = index.css index.js
[./javascripts/deprecation-banner.js] 1.03 KiB {main} [built]
[./javascripts/display-platform-specific-content.js] 2.81 KiB {main} [built]
[./javascripts/experiment.js] 3.97 KiB {main} [built]
[./javascripts/explorer.js] 286 bytes {main} [built]
[./javascripts/google-analytics.js] 514 bytes {main} [built]
[./javascripts/helpfulness.js] 6.25 KiB {main} [built]
[./javascripts/index.js] 956 bytes {main} [built]
[./javascripts/localization.js] 248 bytes {main} [built]
[./javascripts/nav.js] 400 bytes {main} [built]
[./javascripts/print.js] 538 bytes {main} [built]
[./javascripts/search.js] 10.8 KiB {main} [built]
[./javascripts/sidebar.js] 2.73 KiB {main} [built]
[./javascripts/wrap-code-terms.js] 910 bytes {main} [built]
[./node_modules/browser-date-formatter/index.js] 901 bytes {main} [built]
[./stylesheets/index.scss] 39 bytes {main} [built]
    + 538 hidden modules
Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js??ref--5-1!node_modules/resolve-url-loader/index.js??ref--5-2!node_modules/sass-loader/dist/cjs.js??ref--5-3!stylesheets/index.scss:
    Entrypoint mini-css-extract-plugin = *
    [./node_modules/css-loader/dist/cjs.js?!./node_modules/resolve-url-loader/index.js?!./node_modules/sass-loader/dist/cjs.js?!./stylesheets/index.scss] ./node_modules/css-loader/dist/cjs.js??ref--5-1!./node_modules/resolve-url-loader??ref--5-2!./node_modules/sass-loader/dist/cjs.js??ref--5-3!./stylesheets/index.scss 776 KiB {mini-css-extract-plugin} [built]
    [./node_modules/css-loader/dist/runtime/api.js] 2.46 KiB {mini-css-extract-plugin} [built]
ℹ ｢wdm｣: Compiled successfully.

What feature or product is affected?

In the docs for Creating a default community health file, Step 4 for Creating a repository for default files sounds more suggestive than compulsory, whereas the step is an essential step to setup.

https://docs.github.com/en/github/building-a-strong-community/creating-a-default-community-health-file

What is the new or expected behavior?

1. Step 4 should not come across as suggestive but necessary since it is an essential part of the setup.

How is the old or inaccurate behavior currently documented?

Step 4 comes across as suggestive.

Who does this affect?

Users who want to create a repository for default files might me led to choose a private repository

What is the impact to users?

Confusion.

Issue overview

A question came up in the Central Sales slack channel (we're mostly focused on Enterprise sales, FYI):

Question: Does anyone know if GH Actions charged by the “calendar” month, ie. 1st through 30th, 15th to 15th.. or date of subscription start + 30 days?

I went to the help docs, thinking I could find the answer here. I quickly found this passage:

At the end of the month, GitHub calculates the cost of minutes and storage used over the amount included in your account. For example, if your organization uses GitHub Team and allows unlimited spending, using 15,000 minutes could have a total storage and minute overage cost of $56, depending on the operating systems used to run jobs.

Based on the first sentence, I was sure that the answer was at the end of the calendar month. One of my colleagues replied that one of his customers saw their minutes refresh on the 8th of the month...

So, I think there should be some clarifying language to prevent this misinterpretation. Looking at some other subscription-type services (like a cell phone carrier), it's common to see language like

Your data will reset (as indicated above) at midnight on the last day of your billing cycle.
Your new billing cycle (and new data allowance) begins at midnight on the first day of your next billing cycle.

I did find this page that talks about how to find your billing date, but this really only talks about when your next bill is due, which might be monthly or annually (most Enterprise customers are on an annual plan).

I suggest "At the end of the month" be changed to something like "At the end of your monthly billing cycle" or something to that effect.

I've not had many customers really dig into actions yet, but that's about to change as I have 2 large customers that are about to rollout GHEC for 9k users (combined) and Actions is in their plans. As their Account Manager, I want to avoid any nightmares or misunderstandings around overages, etc based in misinterpretations. 🙏

I was going to try and take a swing at a PR on this topic, but I don't have permission to create a branch in this repo, so opening this issue instead.

Products affected by this issue

to be completed by the core product docs team first responder

• Dotcom (all products)
  • GitHub Free
  • GitHub Pro
  • GitHub Team
• GitHub Enterprise Cloud
• GitHub Enterprise Server (Versions: )
• API
• Desktop

Note: The doctocat who triages this issue may invite you to open a PR to address it. Doing so is absolutely not required, though it's helpful for a speedy fix! Someone from our team will work with you to take your changes across the finish line.

/cc @github/product-docs-core

We want our use of GitHub Actions to be a secure as possible. This is a tracking issue for steps we can take to make them more secure. See https://github.com/github/security/issues/3907

• Create a test to lint workflows for correctness and consistency https://github.com/github/help-docs/pull/13181
• #555 Use SHAs instead of version numbers for all uses values (see https://github.com/github/security/issues/3907#issuecomment-619103152)
• Create an AllowList of known/trusted Action authors https://github.com/github/docs-internal/pull/15850

cc @github/content-platform-engineering

A fresh clone of this repo requires npm run build to be run before all the tests will pass. This is an easy thing to forget because you only have to run it once and then npm test continues to work without a fresh build.

One way we can work around this is by adding a pretest script to package.json with a value of npm run build. That way the build will always run first when anyone runs npm test.

That would solve the immediate problem for first-time contributors, but it would also incur a performance penalty every time you run the tests locally, as the build currently takes ~4 seconds to run on my superfast computer. Maybe 4s doesn't matter much in the grand scheme of things... but it would be nice to not incur that cost.

🤔 What are some ways we can solve this?

cc @github/docs-engineering @jeffmcaffer

While reviewing github/docs-internal#15734, I had a difficult time grokking which code was used during runtime vs. only in tests/local scripts. I've thought that a couple of times - we don't currently have a clear separation of that code. Generally speaking, lib is used for runtime code - stuff to run the server. Code solely used for tests often lives in like a tests/helpers directory or something.

Interested in how y'all feel @github/docs-engineering, if this is just me or if others have felt this confusion as well.

What feature or product is affected?

GitHub Actions. Specifically the description of GITHUB_WORKSPACE at https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables#default-environment-variables

We discoved this when writing github/codeql-action#54 and trying to set up a self-hosted runner.

What is the new or expected behavior?

The GITHUB_WORKSPACE environment variable contains the checkout path of the repository.

How is the old or inaccurate behavior currently documented?

The current documentation says "The workspace directory contains a subdirectory with a copy of your repository ..." but this is misleading or wrong. It's unclear whether "The workspace directory" is referring to RUNNER_WORKSPACE (which exists but is undocumented) or GITHUB_WORKSPACE (the variable being documented). If the former then it's technically correct but confusing as that variable is otherwise undocumented. If the latter then it is incorrect.

To fix this, just change "The workspace directory contains a subdirectory with a copy of your repository ..." to "The workspace directory a copy of your repository ..." and leave the rest unchanged.

Who does this affect?

Some small percentage of actions developers. In particular those who aim for their actions to work on self-hosted runners where the directory structure is more important.

What is the impact to users?

Largely just momentary confusion because by looking at the values of all the environment variables you can easily tell what is what and spot the error.

Content strategy and implementation

Please link any in-flight PRs to this issue.

Hi there,

Do you have any plan to build a ready-to-use version of current docs for those who want to use it individually?
An Easy-to-use docs package that anything can be controllable through some GraphQL or REST or JSON files and some folders?

Kind regards,
Ehsan

What article on docs.github.com is affected?

For instance, Actions - Workflow commands: Setting an environment variable does not say that the examples are bash specific. They won't work as-is in cmd or powershell on Windows.

What part(s) of the article would you like to see updated?

• Tell the user what shell an example is for if it's not compatible with all standard terminals
• Ideally provide examples for other shells as well

Additional information

In Workflow syntax for GitHub Actions there is actually a great example of how it should be:

What feature or product is affected?

https://help.github.com/en/github/managing-your-work-on-github/applying-labels-to-issues-and-pull-requests

What is the new or expected behavior?

A user can apply up to a maximum of 100 labels to issues and pull requests.

How is the old or inaccurate behavior currently documented?

Currently there is no mention of this in the above help article. I would recommend that we add a note to the article noting this limit.

Who does this affect?

Any user who uses labels with issues and pull requests.

What is the impact to users?

If a user applies more than 100 labels to an issue or pull request this can cause problems in the GitHub UI, such as problems closing the issue or pull request.

Content to update

In https://help.github.com/en/github/managing-your-work-on-github/applying-labels-to-issues-and-pull-requests:

• Add content about limits to top of page (before procedural)
• Rather than having two tips/notes on this page, we should just turn the current tip into content.

We've had a few PRs land on this repo, but it appears none of them are getting comments after being merged to main.

https://github.com/github/docs/actions?query=workflow%3A.github%2Fworkflows%2Fmerged-notification.yml

I think this may be because of the conditional?

if: github.event.repository.private == false && github.event.pull_request.merged && github.event.pull_request.base.ref == github.event.repository.default_branch

cc @JasonEtco

In https://github.com/github/help-docs/pull/11410 we introduced breadcrumbs. Under the hood, the breadcrumbs are generated by a currentTree object that captures the entire hierarchy of the site, relative to the page you're currently viewing. We can use this new tree to infer what pages precede and follow a given article.

Let's consider adding [Previous] and [Next] links below each article, where appropriate. We'll have to iron out the details of when these links should and should NOT be displayed:

• should these links be displayed for articles that don't have a parent map topic?
• does an article at the end of a map topic link to the next map topic?
• does an article at the beginning of a map topic link to the previous map topic?
• does an article at the end of the last map topic have a [next] link?
• etc

cc @github/product-docs-engineering @github/product-docs-content-strategy

Content strategy plan

In https://help.github.com/packages/publishing-and-managing-packages/deleting-a-package#reserved-package-versions-and-names we say that:

To prevent confusion and build problems, GitHub permanently reserves a package's name and version number. Even if an entire package is deleted, you cannot reuse the deleted package name in any repository owned by the same account.

However, this behavior was modified recently. Now if all versions of a private package are deleted, the user can re-create the package with any version number they want. When all versions of a package have been deleted, republishing over those deleted versions (i.e. publishing a package with the same name and version) should be the same as publishing a new package for the first time.

Content plan

The existing docs are still true for public packages, but we'll want to update the content to note the new behavior for private packages.

Audience

Maintainers of GitHub Packages.

Content to update

We'll want to update https://help.github.com/packages/publishing-and-managing-packages/deleting-a-package#reserved-package-versions-and-names to note the new behavior for private packages.

Questions

If you have any questions after writing a plan, ask them here!

What is the current behavior?

1. the section is not align correctly with the docs content on the big screen.

2. the button position is a little bit off on mobile

What changes are you suggesting?

1. expected result

i added this class on the contact support banner

2. expected result on mobile view

fix it by replacing the classes into this

Additional information

👋 Noticed this today when reviewing some content. Hope this is the right place to open this issue now.

On this page: https://docs.github.com/en/enterprise/2.22/user/github/working-with-github-pages/about-github-pages

The table on subdomain isolation with Pages overlaps the ToC and feedback buttons:

This is the case in all browsers I've tested on desktop with a wide enough viewport to put the ToC in the right-hand column. On mobile the table just gets clipped off so you have the scroll right, which is probably fine.

What feature or product is affected?

GitHub Pages + Enterprise documentation

What is the new or expected behavior?

Table should be the same width as the rest of the content in this column

Who does this affect?

Any users reading this page on desktop. Verified it looks the same in Chrome, Edge, & Safari.

What is the impact to users?

Unable to read ToC or click buttons without moving the table out of the way

Content strategy and implementation

Please link any in-flight PRs to this issue.

What feature or product is affected?

GitHub Enterprise Server administration (virtual appliance network settings)

What is the new or expected behavior?

From the Support side, it would be helpful to make it clear that we do not support multiple network adapters on GHES (we do not support adding additional network adapters to GitHub Enterprise Server).

How is the old or inaccurate behavior currently documented?

We could mention it in this documentation https://docs.github.com/en/enterprise-server/admin/configuration/configuring-the-ip-address-using-the-virtual-machine-console or on https://docs.github.com/en/enterprise-server/admin/configuration/configuring-network-settings.

Who does this affect?

GHES admins

The bots are confusing one another! 🤖 ⚡ 🤖

cc @github/docs-engineering

Issue overview

The 'Configuring the self-hosted runner application as a service' page has tabs for specific instructions for Mac, Windows, and Linux.

Currently, the default tab is Mac.

Let's change the default to Linux, as this is the most common for our users.

Products affected by this issue

to be completed by the core product docs team first responder

• Dotcom (all products)
  • GitHub Free
  • GitHub Pro
  • GitHub Team
• GitHub Enterprise Cloud
• GitHub Enterprise Server (Versions: )
• API
• Desktop

Note: The doctocat who triages this issue may invite you to open a PR to address it. Doing so is absolutely not required, though it's helpful for a speedy fix! Someone from our team will work with you to take your changes across the finish line.

/cc @github/product-docs-core

Issue overview

When I open the actions help docs page, I thought the categories in the sidebar were arbitrarily uncollapsed, but I learned that the first three categories are uncollapsed by default.

I didn't find it very intuitive why the first three categories were uncollapsed when viewing the page. I actually assumed that maybe the browser was caching some previous configuration of my viewing of that page or something. 🤷‍♀ I find it much easier to see the hierarchy of the docs when all of the categories are collapsed or just the active category uncollapsed.

Products affected by this issue

• Dotcom (all products)
  • GitHub Free
  • GitHub Pro
  • GitHub Team
• GitHub Enterprise Cloud
• GitHub Enterprise Server (Versions: )
• API
• Desktop

/cc @github/product-docs-engineering

What article on docs.github.com is affected?

The specific README.md files for both variables and reusables; CONTRIBUTING.md

What part(s) of the article would you like to see updated?

As they are now, these files are a little bit dry - it's not something that's intuitively usable by first-time contributors. I suggest both of these files could be updated to look like the one for liquid tabs, with references, usage examples, etc.

Also - adding a brief section on each of these (liquid tabs, variables, reusables, etc) would be extremely helpful.

Content design plan

• Open for an OS contributor: For specific README.md files, I think they should be as complete as possible: definitions, examples, everything that a content contributor could learn about what's being referenced (code intrincacies = negative scope).
• @janiceilene will make these changes: As for CONTRIBUTING.md: IMHO it should be a complete quick start. Let's take, for instance, the last 24h: I was learning about variables, reusables, and callout tags as the PRs were reviewed. I mean, the technical detailes are there if I follow the md links, but the text doesn't give me any reasons to do so. And even if I do it, there's no clear benefit for the newcoming contributor - it reads and feels like technical documentation (which is technically not wrong, but not necessarily helpful to a newcomer as such).
  • Structure the CONTRIBUTING.md file more like a quick start guide - "welcome, here's the basic stuff you need to know, here's why you need to know it, here's where you can learn more about each of them" - paced, with simple examples. Perhaps something like this.

What feature or product is affected?

LDAP team sync—GHES admin docs

What is the new or expected behavior?

When syncing a group from LDAP to a team that has greater than 1500 members, it doesn't populate any users. However, syncing a group that has 1499 members seems to work. It was asked if their LDAP service supports paged results and if they have a page cap, to which they replied that pagination is working.

How is the old or inaccurate behavior currently documented?

From a support ticket:

This has not been documented yet.

I think it would maybe be best suited for a note or call out in https://docs.github.com/en/enterprise/admin/authentication/using-ldap#enabling-ldap-sync

Something as short as this I think would at least give us something to point to when customers ask:

Note: LDAP synchronized teams are limited to a maximum 1499 members.

Who does this affect?

GHES admins using LDAP team sync with teams of 1500+ members

Issue overview

In our documentation we do not make it clear to users that in order to link a repository to your organisation or user owned project board the repository needs to have Issues enabled.

Help Article: https://help.github.com/en/github/managing-your-work-on-github/linking-a-repository-to-a-project-board

Content to update

In https://help.github.com/en/github/managing-your-work-on-github/linking-a-repository-to-a-project-board:

• Add a sentence "In order to link a repository to your organization or user owned project board the repository needs to have Issues enabled"
• We should really link to an article about issues being enabled, maybe https://docs.github.com/en/github/managing-your-work-on-github/disabling-issues?

What article on docs.github.com is affected?

There is a small bug in cloning an empty repository to the local machine, that has not been included in GitHub documentations.

What is the bug?

Steps to check,

• Create an empty repository in Github.
• Clone it into the local system.
• Add some files to it.
• Open git bash and type git add . then git commit -m
• Finally git push origin main

It raises an error because the main is not working in case of cloning an empty repo.
If instead of git push origin main, you try git push origin master, it will work.

The bug is - remove the master word and replace it with main, as the master keyword has been removed officially while creating an empty repo.

Additional information

We may have two solutions,

• Adding this to the documentation page
• Solving the bug

After the discussions below, we realized that the docs don't currently remind you to check what the default branch name is when you clone a repository. You need this information to know where to push the first files. The content design plan below is designed to address this omission.

Content design plan

Proposed content design plan to address this issue.

Topics to update:

Cloning an empty repository - in the section "Cloning an empty repository":

• Add a new step 2, after the first step ({% data reusables.repositories.navigate-to-repo %}) to note the name of the default branch for the repository, shown on the branch selector on the left of the screen.
• Include a screenshot with the branch selector highlighted.

I've attached a screenshot with the branch selector highlighted. This should be added to the /assets/images/help/repository/ directory with a suitable name, for example: branch-selector.png.

What is the current behavior?

Seems like there is a misconfiguration somewhere between the github-actions bot and the allcontributors bot

In #204 we see the github bot asking the allcontributors to add me as a docs contributor and then allcontributors not understanding what to do.

What is the current behavior?

There is a translation error in translations/pt-BR/.../licensing-a-repository.md. We don't translate README into Portuguese, we just call it README.

What changes are you suggesting?

Change "LEIAME" to "README".

In our team meeting on 3.21.19 @zeke mentioned that it might be nice to add a short description of each change made to the docs similar to how Heroku documents dev changes.

This might be a good thing to implement once we've merged help.github.com and developer.github.com.

There are currently changelogs spread out across the developer site and GitHub.com. There are plans to consolidate the blogs on developer.github.com into GitHub.com.

This is a list of the changelogs and blogs that I'm aware of:

• GitHub Blog
• Developer Blog
• GitHub changelog
• Actions changelog Note: This will be removed when actions hits GA.
• GraphQL changelog
• GraphQL breaking changes

Related developer.github.com issues

• https://github.com/github/customer-feedback/issues/1544

cc @github/product-docs-engineering

What article on docs.github.com is affected?

Basically any REST API endpoint which returns HTTP 4xx responses

What part(s) of the article would you like to see updated?

The REST API documentation provides in depth description of responses for successful requests.
However things might not work as expected and then the API responds with HTTP errors. Some of them are predictable (4xx), some not (5xx).
For example, fetching a repository which is affected by DMCA takedown notice ends up with HTTP 451 Unavailable for Legal Reasons

Additional information

As GitHub App developer I would love to have predictable errors as part of the documentation
In order to gracefully handle some errors
When developing GitHub apps which consume REST API

Currently I create pull requests for octokit.rb whenever I identify a type of error which I need to handle. Having the errors documented would make this job much easier.

I ran Lighthouse on a few pages on docs.github.com, here's some opportunities for us from that:

• Our DOM is excessively large, with the left navigation having over 2400 elements. [Difficult]
• /javascripts/index.js has a cache time of 1 minute. If we had a longer cache time, the performance of the page would be slightly higher. [Difficult]
• btn-mktg and btn-outline-mktg doesn't meet contrast requirements
• [aria-hidden="true"] elements contain focusable descendents [Easy]
• Heading elements are not sequentially ordered. [Easy]
  Appears to be from the right sidebar, the h4 need to be h3.
• Form elements missing labels. [Medium]
  I think this might be the search?
• The octicon link in the upper left corner has no name for screenreaders.
• All pages are missing <!doctype html> and <meta charSet="utf-8">
• Many pages are missing meta descriptions [Difficult]
• The searching octocat SVG is pretty heavy on the page, and looks like the markup hasn't been optimized.
• Add rel="noopener" to external links, including https://github.com [Easy]

What article on docs.github.com is affected?

What part(s) of the article would you like to see updated?

Additional information

Update some typos on quickstart.md

What feature or product is affected?

Actions!

What is the new or expected behavior?

Corrected shell command details (I think)!

How is the old or inaccurate behavior currently documented?

We received a report from a user

the docs state the shell commands that they run https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#using-a-specific-shell

for pwsh - pwsh -command "& '{0}'"
for powershell - powershell -command "& '{0}'".

however in runs it seems that the commands are not that example

/usr/bin/pwsh -command ". '{0}'"

So the difference seems to be . vs &? If you run this workflow:

name: check shell output
on:
  push:
jobs:
  pwsh:
    runs-on: windows-latest
    steps:
    - name: windows pwsh command
      shell: pwsh
      run: Write-Host 'Hello, World pwsh!'

  powershell:
    runs-on: windows-latest
    steps:
    - name: windows powershell command
      shell: powershell
      run: Write-Host 'Hello, World powershell!'

I think this is what you see in the log output for pwsh:

Run Write-Host 'Hello, World pwsh!'
  Write-Host 'Hello, World pwsh!'
  shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"

And for powershell:

Run Write-Host 'Hello, World powershell!'
  Write-Host 'Hello, World powershell!'
  shell: C:\windows\System32\WindowsPowerShell\v1.0\powershell.EXE -command ". '{0}'"

So -command ". '{0}'" in both cases but the docs shows -command "& '{0}'" in both cases?

Audience

Users who are building GitHub Actions workflows and using pwsh or powershell.

Ignore this @github/docs-content, I'm testing some automation!

Content strategy plan

Content plan

The lack of a mention of Windows in the Downloading the CodeQL runner section could make the user doubt whether Windows is supported by the runner.

Audience

Anyone installing the CodeQL runner who wants to verify that it will work in their system.

Content to update

Currently, Windows is not mentioned in this section because you don't need to make any particular changes to the downloaded file to make it executable.

Having discussed this with the user who gave this feedback, the recommended fix is to add an explanatory sentence to the end of the section. Something like:

On Windows, the codeql-runner-win.exe file usually requires no change to permissions.

Questions

None outstanding.

Issue overview

Hiyo 👋! User reporting a typo in https://developer.github.com/apps/quickstart-guides/setting-up-your-development-environment/#step-4-prepare-the-runtime-environment:

I noticed a typo in the Developer Docs: https://developer.github.com/apps/quickstart-guides/setting-up-your-development-environment/

In Step 4, in the example .env file at the end, PRIVATE_KEY should be GITHUB_PRIVATE_KEY

So this is the example .env file at the end of step 4.

I think they're right? The template code to start from that we mention in the Prerequisites section uses GITHUB_PRIVATE_KEY:

https://github.com/github-developer/github-app-template/blob/d73485c3ef88d351fbd45b11666c045b319f7f49/.env-example#L1

Products affected by this issue

• REST API
• GraphQL API
• Apps
• GitHub Actions
• GitHub Marketplace
• Webhooks

/cc @github/product-docs-ecosystem

What feature or product is affected?

• REST API

What is the new or expected behavior?

Example

https://docs.github.com/en/rest/reference/repos#check-if-vulnerability-alerts-are-enabled-for-a-repository

would become

https://docs.github.com/en/rest/reference/repos#check-vulnerability-alerts

See OpenAPI spec at https://github.com/github/openapi/blob/347c7c385184352692d4118b7e8a266ccf9b7db7/definitions/operations/repos/check-vulnerability-alerts.yml#L6

How is the old or inaccurate behavior currently documented?

n/a

Who does this affect?

Every change to an #anchor name for endpoint titles requires a change in the code, due to the error handlers which include a URL to the documentation. The endpoint titles are more prone to changes, while operation IDs should be changed much less frequently, as they are consider a breaking change to some of the OpenAPI consumers, while the "summary" key is not.

The problem with the title changes might also be amplified once translations are introduced.

@zeke sent me here, we shortly discussed it today:

What is the impact to users?

n/a

Content strategy and implementation

tbd

Content strategy plan

Content plan

Currently the topic on archiving repositories does not mention code scanning: About archiving repositories.

Audience

Users who are considering archiving a repository will want to know exactly how this affects the repository.

Content to update

Currently "About archiving repositories" says:

When a repository is archived, its issues, pull requests, code, labels, milestones, projects, wiki, releases, commits, tags, branches, reactions, and comments become read-only.

Update this to include "code scanning alerts".

Questions

None outstanding.

What is the current behavior?

I cloned the repo, did npm install and npm test and got a number of failures shown below.

Note this was with Node 12.18.3 (npm 6.14.6) on Mac OS 10.15.7

expect(received).toBe(expected) // Object.is equality

Expected: 200
Received: 404

  567 | describe('static assets', () => {
  568 |   test('fonts', async () => {
> 569 |     expect((await get('/dist/fonts/Inter-Medium.woff')).statusCode).toBe(200)
      |                                                                     ^
  570 |     expect((await get('/dist/fonts/Inter-Regular.woff')).statusCode).toBe(200)
  571 |   })
  572 | })

  at Object.<anonymous> (tests/rendering/server.js:569:69)
      at runMicrotasks (<anonymous>)

expect(received).toBe(expected) // Object.is equality

Expected: 200
Received: 404

  665 |   it('compiles and sets the right content-type header', async () => {
  666 |     const res = await get('/dist/index.css')
> 667 |     expect(res.statusCode).toBe(200)
      |                            ^
  668 |     expect(res.headers['content-type']).toBe('text/css; charset=UTF-8')
  669 |   })
  670 | })

  at Object.<anonymous> (tests/rendering/server.js:667:28)
      at runMicrotasks (<anonymous>)

expect(received).toBe(expected) // Object.is equality

Expected: 200
Received: 404

  678 | 
  679 |   it('returns a 200 response', async () => {
> 680 |     expect(res.statusCode).toBe(200)
      |                            ^
  681 |   })
  682 | 
  683 |   it('sets the right content-type header', async () => {

  at Object.<anonymous> (tests/rendering/server.js:680:28)
      at runMicrotasks (<anonymous>)

expect(received).toBe(expected) // Object.is equality

Expected: "application/javascript; charset=UTF-8"
Received: "text/html; charset=utf-8"

  682 | 
  683 |   it('sets the right content-type header', async () => {
> 684 |     expect(res.headers['content-type']).toBe('application/javascript; charset=UTF-8')
      |                                         ^
  685 |   })
  686 | 
  687 |   // TODO: configure webpack to create production bundle in the test env

  at Object.<anonymous> (tests/rendering/server.js:684:41)
      at runMicrotasks (<anonymous>)

console.log
  data should NOT have additional properties, data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data should have required property 'type', data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data should have required property 'url', data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data.url should match format "uri", data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data should have required property 'vote', data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data.vote should be equal to one of the allowed values, data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data.email should match format "email", data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data.comment should be string, data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data.category should be equal to one of the allowed values, data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data should NOT have additional properties, data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data should NOT have additional properties, data should NOT have additional properties, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data should NOT have additional properties, data should have required property 'test', data should match exactly one schema in oneOf

  at middleware/events.js:24:56

console.log
  data should NOT have additional properties, data.group should be equal to one of the allowed values, data should match exactly one schema in oneOf

  at middleware/events.js:24:56

expect(received).toBe(expected) // Object.is equality

Expected: 200
Received: 404

  567 | describe('static assets', () => {
  568 |   test('fonts', async () => {
> 569 |     expect((await get('/dist/fonts/Inter-Medium.woff')).statusCode).toBe(200)
      |                                                                     ^
  570 |     expect((await get('/dist/fonts/Inter-Regular.woff')).statusCode).toBe(200)
  571 |   })
  572 | })

  at Object.<anonymous> (tests/rendering/server.js:569:69)
      at runMicrotasks (<anonymous>)

expect(received).toBe(expected) // Object.is equality

Expected: 200
Received: 404

  665 |   it('compiles and sets the right content-type header', async () => {
  666 |     const res = await get('/dist/index.css')
> 667 |     expect(res.statusCode).toBe(200)
      |                            ^
  668 |     expect(res.headers['content-type']).toBe('text/css; charset=UTF-8')
  669 |   })
  670 | })

  at Object.<anonymous> (tests/rendering/server.js:667:28)
      at runMicrotasks (<anonymous>)

expect(received).toBe(expected) // Object.is equality

Expected: 200
Received: 404

  678 | 
  679 |   it('returns a 200 response', async () => {
> 680 |     expect(res.statusCode).toBe(200)
      |                            ^
  681 |   })
  682 | 
  683 |   it('sets the right content-type header', async () => {

  at Object.<anonymous> (tests/rendering/server.js:680:28)
      at runMicrotasks (<anonymous>)

expect(received).toBe(expected) // Object.is equality

Expected: "application/javascript; charset=UTF-8"
Received: "text/html; charset=utf-8"

  682 | 
  683 |   it('sets the right content-type header', async () => {
> 684 |     expect(res.headers['content-type']).toBe('application/javascript; charset=UTF-8')
      |                                         ^
  685 |   })
  686 | 
  687 |   // TODO: configure webpack to create production bundle in the test env

  at Object.<anonymous> (tests/rendering/server.js:684:41)
      at runMicrotasks (<anonymous>)

</details>

cc: @github/docs-engineering 

Content to update

In https://docs.github.com/en/github/searching-for-information-on-github/about-searching-on-github

• Change "Use our powerful search tools" to something like "Use search" to be more accurate and less subjective
• At the end of the first section add information that
  • Currently our search doesn't support exact matching
  • when searching in code files search will only return the first two results in each file

Issue overview

This relates to the Changing your primary email address article. A user found that they could not change their primary email address to an email that is already set to be their backup email address.

Content strategy plan

• Add some text before the procedure that you cannot choose your backup email address as your primary.
• To work around this, we recommend setting backup to "allow all verified emails"

When I run tests locally using npm test on master:

$ npm test

> [email protected] test C:\2_Semmle\Repositories\help-docs
> jest && standard && npm run check-deps

FAIL tests/unit/products.js (31.288 s)
  ● products module › every product is valid

    Custom message:
      {
      "product": {
        "id": "github",
        "name": "GitHub.com",
        "href": "/github",
        "dir": "content/github",
        "toc": "content\\github\\index.md",
        "wip": false,
        "hasEnterpriseUserVersions": true
      },
      "errors": [
        {
          "attribute": "pattern",
          "property": "toc",
          "expected": "^content/.*?index.md$",
          "actual": "content\\github\\index.md",
          "message": "invalid input"
        }
      ]
    }

    expect(received).toBe(expected) // Object.is equality

    Expected: true
    Received: false

      14 |       const { valid, errors } = revalidator.validate(product, schema)
      15 |       const expectation = JSON.stringify({ product, errors }, null, 2)
    > 16 |       expect(valid, expectation).toBe(true)
         |                                  ^
      17 |     })
      18 |   })
      19 | })

      at forEach (tests/unit/products.js:16:34)
          at Array.forEach (<anonymous>)
      at Object.<anonymous> (tests/unit/products.js:13:29)

PASS tests/routing/deprecated-enterprise-versions.js (33.404 s)
PASS tests/unit/toc-links.js (43.006 s)
FAIL tests/rendering/server.js (57.626 s)
  ● stylesheets › compiles and sets the right content-type header

    expect(received).toBe(expected) // Object.is equality

    Expected: 200
    Received: 301

      740 |   it('compiles and sets the right content-type header', async () => {
      741 |     const res = await get('/dist/index.css')
    > 742 |     expect(res.statusCode).toBe(200)
          |                            ^
      743 |     expect(res.headers['content-type']).toBe('text/css; charset=UTF-8')
      744 |   })
      745 | })

      at Object.<anonymous> (tests/rendering/server.js:742:28)

  ● client-side JavaScript bundle › returns a 200 response

    expect(received).toBe(expected) // Object.is equality

    Expected: 200
    Received: 301

      753 |
      754 |   it('returns a 200 response', async () => {
    > 755 |     expect(res.statusCode).toBe(200)
          |                            ^
      756 |   })
      757 |
      758 |   it('sets the right content-type header', async () => {

      at Object.<anonymous> (tests/rendering/server.js:755:28)

  ● client-side JavaScript bundle › sets the right content-type header

    expect(received).toBe(expected) // Object.is equality

    Expected: "application/javascript; charset=UTF-8"
    Received: "text/plain; charset=utf-8"

      757 |
      758 |   it('sets the right content-type header', async () => {
    > 759 |     expect(res.headers['content-type']).toBe('application/javascript; charset=UTF-8')
          |                                         ^
      760 |   })
      761 |
      762 |   // TODO: configure webpack to create production bundle in the test env

      at Object.<anonymous> (tests/rendering/server.js:759:41)

PASS tests/rendering/header.js (28.09 s)
PASS tests/content/site-tree.js (29.112 s)
PASS tests/rendering/breadcrumbs.js (31.095 s)
FAIL tests/content/article-links.js (82.541 s)
  ● article links › in "content\actions\hosting-your-own-runners\monitoring-and-troubleshooting-self-hosted-runners.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [962]: Starting
      - [962]: Started
      - [962]: Started
      - [962]: √
      - [962]: 2020-02-11
      - [962]: 2020-02-11
      - [962]: 2020-02-11

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 7

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\enterprise\admin\enterprise-management\migrating-from-github-enterprise-1110x-to-2123.md" › URLs must not contain a hard-coded version number

    Custom message:
      Found article links with hard-coded version numbers:
      - [Upgrading to the latest release](/enterprise/11.10.340/admin/articles/upgrading-to-the-latest-release/)
      - [Provisioning and Installation](/enterprise/2.1/admin/guides/installation/provisioning-and-installation/)
      - [Provisioning and Installation](/enterprise/2.1/admin/guides/installation/provisioning-and-installation/)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 3

      180 |
      181 |         const errorMessage = formatLinkError(versionLinkErrorText, matches)
    > 182 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      183 |       })
      184 |
      185 |       test('URLs must not contain a hard-coded domain name', async () => {

      at Object.<anonymous> (tests/content/article-links.js:182:46)

  ● article links › in "content\enterprise\admin\user-management\configuring-email-for-notifications.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [13210]: connect
      - [13210]: 51DC9163323:
      - [13216]: 51DC9163323:
      - [17250]: 51DC9163323:
      - [13217]: 51DC9163323:
      - [17250]: 51DC9163323:
      - [13210]: disconnect

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 7

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\building-a-strong-community\editing-wiki-content.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [Link Text](full-URL-of-wiki-page)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\building-a-strong-community\manually-creating-a-single-issue-template-for-your-repository.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [DATE]: [FEATURE

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\enforcing-best-practices-with-github-policies\constraints.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [a-z]([a-z]|-)
      - [a-z]([a-z]|-)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 2

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\enforcing-best-practices-with-github-policies\overview.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [A-Z]([a-z]|-)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\finding-security-vulnerabilities-and-errors-in-your-code\sarif-support-for-code-scanning.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [here](1)
      - [here](2)
      - [ruleIndex](1)
      - [ruleID](2)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 4

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\rest\overview\libraries.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [pithub-github] ([CPAN][pithub-cpan])
      - [net-github-github] ([CPAN][net-github-cpan])

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 2

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "data\reusables\repositories\relative-links.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [Contribution guidelines for this project](docs/CONTRIBUTING.md)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

(node:7752) [DEP0066] DeprecationWarning: OutgoingMessage.prototype._headers is deprecated
PASS tests/routing/top-developer-site-path-redirects.js (29.88 s)
PASS tests/routing/redirects.js (29.404 s)
PASS tests/content/site-data.js (33.601 s)
PASS tests/rendering/page-titles.js (30.475 s)
PASS tests/rendering/sidebar.js (31.603 s)
PASS tests/routing/developer-site-redirects.js (28.341 s)
PASS tests/rendering/footer.js (27.494 s)
PASS tests/content/graphql.js (29.668 s)
PASS tests/rendering/curated-homepage-links.js (27.603 s)
PASS tests/content/webhooks.js (26.777 s)
PASS tests/content/featured-links.js (27.765 s)
PASS tests/routing/language-code-redirects.js (32.3 s)
PASS tests/links-and-images/links-and-images.js (150.636 s)
PASS tests/rendering/head.js (27.813 s)
PASS tests/rendering/rest.js (26.164 s)
PASS tests/unit/pages.js (18.399 s)
PASS tests/content/glossary.js (11.873 s)
PASS tests/content/site-data-references.js (14.73 s)
PASS tests/content/crowdin-config.js (10.643 s)
PASS tests/unit/liquid.js
PASS tests/unit/page.js
PASS tests/content/liquid-line-breaks.js (24.988 s)
PASS tests/unit/find-page.js
PASS tests/rendering/robots-txt.js
PASS tests/unit/algolia/parse-page-sections-into-records.js
PASS tests/content/remove-liquid-statements.js
PASS tests/routing/middleware/redirects/help-to-docs.js
PASS tests/unit/enterprise-versions.js
PASS tests/unit/permalink.js
PASS tests/content/gitignore.js
PASS tests/meta/orphan-tests.js
PASS tests/unit/languages.js
PASS tests/unit/product-names.js
PASS tests/content/algolia-search.js
FAIL tests/content/category-pages.js (6.286 s)
  ● category pages › category index "github\getting-started-with-github\index.md" › contains all expected articles

    Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error: Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.

      at mapper (node_modules/jest-jasmine2/build/queueRunner.js:29:45)

  ● category pages › category index "github\getting-started-with-github\index.md" › does not any unexpected articles

    Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error: Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.

      at mapper (node_modules/jest-jasmine2/build/queueRunner.js:29:45)

PASS tests/unit/liquid-helpers.js (10.572 s)
PASS tests/links-and-images/developer-links-and-images.js (736.398 s)
A worker process has failed to exit gracefully and has been force exited. This is likely caused by tests leaking due to improper teardown. Try running with --runInBand --detectOpenHandles to find leaks.

Summary of all failing tests
FAIL tests/unit/products.js (31.288 s)
  ● products module › every product is valid

    Custom message:
      {
      "product": {
        "id": "github",
        "name": "GitHub.com",
        "href": "/github",
        "dir": "content/github",
        "toc": "content\\github\\index.md",
        "wip": false,
        "hasEnterpriseUserVersions": true
      },
      "errors": [
        {
          "attribute": "pattern",
          "property": "toc",
          "expected": "^content/.*?index.md$",
          "actual": "content\\github\\index.md",
          "message": "invalid input"
        }
      ]
    }

    expect(received).toBe(expected) // Object.is equality

    Expected: true
    Received: false

      14 |       const { valid, errors } = revalidator.validate(product, schema)
      15 |       const expectation = JSON.stringify({ product, errors }, null, 2)
    > 16 |       expect(valid, expectation).toBe(true)
         |                                  ^
      17 |     })
      18 |   })
      19 | })

      at forEach (tests/unit/products.js:16:34)
          at Array.forEach (<anonymous>)
      at Object.<anonymous> (tests/unit/products.js:13:29)

FAIL tests/rendering/server.js (57.626 s)
  ● stylesheets › compiles and sets the right content-type header

    expect(received).toBe(expected) // Object.is equality

    Expected: 200
    Received: 301

      740 |   it('compiles and sets the right content-type header', async () => {
      741 |     const res = await get('/dist/index.css')
    > 742 |     expect(res.statusCode).toBe(200)
          |                            ^
      743 |     expect(res.headers['content-type']).toBe('text/css; charset=UTF-8')
      744 |   })
      745 | })

      at Object.<anonymous> (tests/rendering/server.js:742:28)

  ● client-side JavaScript bundle › returns a 200 response

    expect(received).toBe(expected) // Object.is equality

    Expected: 200
    Received: 301

      753 |
      754 |   it('returns a 200 response', async () => {
    > 755 |     expect(res.statusCode).toBe(200)
          |                            ^
      756 |   })
      757 |
      758 |   it('sets the right content-type header', async () => {

      at Object.<anonymous> (tests/rendering/server.js:755:28)

  ● client-side JavaScript bundle › sets the right content-type header

    expect(received).toBe(expected) // Object.is equality

    Expected: "application/javascript; charset=UTF-8"
    Received: "text/plain; charset=utf-8"

      757 |
      758 |   it('sets the right content-type header', async () => {
    > 759 |     expect(res.headers['content-type']).toBe('application/javascript; charset=UTF-8')
          |                                         ^
      760 |   })
      761 |
      762 |   // TODO: configure webpack to create production bundle in the test env

      at Object.<anonymous> (tests/rendering/server.js:759:41)

FAIL tests/content/article-links.js (82.541 s)
  ● article links › in "content\actions\hosting-your-own-runners\monitoring-and-troubleshooting-self-hosted-runners.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [962]: Starting
      - [962]: Started
      - [962]: Started
      - [962]: √
      - [962]: 2020-02-11
      - [962]: 2020-02-11
      - [962]: 2020-02-11

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 7

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\enterprise\admin\enterprise-management\migrating-from-github-enterprise-1110x-to-2123.md" › URLs must not contain a hard-coded version number

    Custom message:
      Found article links with hard-coded version numbers:
      - [Upgrading to the latest release](/enterprise/11.10.340/admin/articles/upgrading-to-the-latest-release/)
      - [Provisioning and Installation](/enterprise/2.1/admin/guides/installation/provisioning-and-installation/)
      - [Provisioning and Installation](/enterprise/2.1/admin/guides/installation/provisioning-and-installation/)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 3

      180 |
      181 |         const errorMessage = formatLinkError(versionLinkErrorText, matches)
    > 182 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      183 |       })
      184 |
      185 |       test('URLs must not contain a hard-coded domain name', async () => {

      at Object.<anonymous> (tests/content/article-links.js:182:46)

  ● article links › in "content\enterprise\admin\user-management\configuring-email-for-notifications.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [13210]: connect
      - [13210]: 51DC9163323:
      - [13216]: 51DC9163323:
      - [17250]: 51DC9163323:
      - [13217]: 51DC9163323:
      - [17250]: 51DC9163323:
      - [13210]: disconnect

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 7

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\building-a-strong-community\editing-wiki-content.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [Link Text](full-URL-of-wiki-page)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\building-a-strong-community\manually-creating-a-single-issue-template-for-your-repository.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [DATE]: [FEATURE

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\enforcing-best-practices-with-github-policies\constraints.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [a-z]([a-z]|-)
      - [a-z]([a-z]|-)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 2

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\enforcing-best-practices-with-github-policies\overview.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [A-Z]([a-z]|-)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\github\finding-security-vulnerabilities-and-errors-in-your-code\sarif-support-for-code-scanning.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [here](1)
      - [here](2)
      - [ruleIndex](1)
      - [ruleID](2)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 4

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "content\rest\overview\libraries.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [pithub-github] ([CPAN][pithub-cpan])
      - [net-github-github] ([CPAN][net-github-cpan])

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 2

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

  ● article links › in "data\reusables\repositories\relative-links.md" › relative URLs must start with "/"

    Custom message:
      Found unexpected relative article links:
      - [Contribution guidelines for this project](docs/CONTRIBUTING.md)

    expect(received).toBe(expected) // Object.is equality

    Expected: 0
    Received: 1

      159 |
      160 |         const errorMessage = formatLinkError(relativeArticleLinkErrorText, matches)
    > 161 |         expect(matches.length, errorMessage).toBe(0)
          |                                              ^
      162 |       })
      163 |
      164 |       test('URLs must not contain a hard-coded language code', async () => {

      at Object.<anonymous> (tests/content/article-links.js:161:46)

FAIL tests/content/category-pages.js (6.286 s)
  ● category pages › category index "github\getting-started-with-github\index.md" › contains all expected articles

    Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error: Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.

      at mapper (node_modules/jest-jasmine2/build/queueRunner.js:29:45)

  ● category pages › category index "github\getting-started-with-github\index.md" › does not any unexpected articles

    Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.Error: Timeout - Async callback was not invoked within the 5000 ms timeout specified by jest.setTimeout.

      at mapper (node_modules/jest-jasmine2/build/queueRunner.js:29:45)


Test Suites: 4 failed, 41 passed, 45 total
Tests:       16 failed, 7 skipped, 2 todo, 14879 passed, 14904 total
Snapshots:   0 total
Time:        741.238 s, estimated 781 s
Ran all test suites.
npm ERR! Test failed.  See above for more details.

Content strategy plan

On the https://help.github.com/packages/using-github-packages-with-your-projects-ecosystem/configuring-gradle-for-use-with-github-packages#installing-a-package page, there are two examples with the typo "Grady Groovy."

Content plan

Summarize the issue, the impact on GitHub users, and the documentation changes we'll make to resolve the issue.

Audience

Describe the audience for the change.

Content to update

On the https://help.github.com/packages/using-github-packages-with-your-projects-ecosystem/configuring-gradle-for-use-with-github-packages#installing-a-package page, let's fix the typo "Grady Groovy," which should be "Gradle Groovy."

Questions

If you have any questions after writing a plan, ask them here!

What feature or product is affected?

Email notifications documentation

What is the new or expected behavior?

Documentation shows a Send as author checkbox in step 6. This feature was removed, so we should delete the step.

How is the old or inaccurate behavior currently documented?

Current document:
https://docs.github.com/en/enterprise/2.20/user/github/administering-a-repository/about-email-notifications-for-pushes-to-your-repository

Who does this affect?

GitHub users on .com and enterprise

Content strategy plan

When I looked through your Actions documentation for an "event type" property, I saw github.event and github.event_path in the table but no github.event.type or similar. I found github.event_name eventually, but now I wonder why the rows are ordered like they are instead of being alphabetically sorted by the relevant column. That would make it easier to spot values in cases like mine.

https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context

It might be nice to make the list alphabetical to aid in searching.

Content plan

Summarize the issue, the impact on GitHub users, and the documentation changes we'll make to resolve the issue.

Audience

People using GitHub Actions workflows.

Content to update

Let's update the properties in the tables on this page: https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions#github-context

Questions

If you have any questions after writing a plan, ask them here!