Clarify CNAME record value for private Pages sites in the subdomain section - #45865
Open
7kaji wants to merge 1 commit into
Open
Clarify CNAME record value for private Pages sites in the subdomain section#458657kaji wants to merge 1 commit into
7kaji wants to merge 1 commit into
Conversation
Contributor
How to review these changes 👓Thank you for your contribution. To review these changes, choose one of the following options: A Hubber will need to deploy your changes internally to review. Table of review linksNote: Please update the URL for your staging server or codespace. The table shows the files in the
Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server 🤖 This comment is automatically generated. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why:
Closes:
There is no existing issue for this. It is a one-paragraph follow-up to a change the maintainers made themselves, so I opened a pull request directly. Happy to file an issue first if you would prefer that.
The "Configuring an apex domain and the
wwwsubdomain variant" section says that theCNAMErecord values are the same for publicly and privately published sites. That sentence was added in commitc76a1f56. The "Configuring a subdomain" section has no equivalent statement, even though that is where Changing the visibility of your GitHub Pages site sends the reader right after showing them the site's unique*.pages.github.iosubdomain.What's being changed (if available, include any code snippets, screenshots, or gifs):
This adds one paragraph to "Configuring a subdomain", directly after the
CNAMEstep. The first and third sentences reuse the wording of the apex andwwwsection. The second sentence is new: it names the mistake the reader is most likely to make, because the unique subdomain is the only Pages URL shown in the repository settings for a privately published site.Written as a paragraph rather than an alert: the section already has three alerts, the next line is a warning, and the change linked above used a paragraph too.
The link uses
/enterprise-cloud@latest/because the target article is GitHub Enterprise Cloud only, while this one is versioned for both Free, Pro & Team and Enterprise Cloud.SME review requested for the second sentence. It follows from the existing instruction that "The
CNAMErecord should always point to<user>.github.ioor<organization>.github.io", andcname_to_github_user_domain?in github/pages-health-check does not match*.pages.github.io, but I have not found it stated by GitHub directly.Check off the following: