chore(ci): Use actions/deploy-pages for Cargo Contributor Guide deployment#16876
chore(ci): Use actions/deploy-pages for Cargo Contributor Guide deployment#16876ehuss merged 2 commits intorust-lang:masterfrom
actions/deploy-pages for Cargo Contributor Guide deployment#16876Conversation
rustbot
added
A-infrastructure
|
r? @weihanglo rustbot has assigned @weihanglo. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
Sorry, I removed from queue because I saw this |
|
Specifically, I'm uncertain about how the sequence of changes will affect things with the CNAME file. The GitHub docs are not terribly clear. I'm guessing what might happen with merging this is that:
Does that all sound accurate? I'm not confident of any of those steps. We previously verified the domain. Will changing the settings affect that verification? |
the |
admittedly, I wasn't aware of that and https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site sounds like you are correct. in that case the PR should probably drop the CNAME file in favor of setting the custom domain in the repo settings 🤔 |
|
I'll drop a note with infra to see if they can be available to make the settings change. |
…loyment Replace git worktree-based deployment with the official `actions/upload-pages-artifact` and `actions/deploy-pages` actions. This requires changing the repository's Pages settings from "Deploy from a branch" to "GitHub Actions".
`CNAME` files are apparently ignored if GitHub Pages are deployed via GitHub Actions and instead the custom domain needs to be set in the repository settings.
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
I've rebased and added a second commit which drops the |
|
Also, I double-checked that there is already a gh-pages Environment in the team database. The deploy action creates one automatically if it doesn't exist, which can be awkward. AFAIK, that shouldn't be a problem. |
|
Checked with infra, and seems we should be good. |
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
rustbot
removed
the
S-waiting-on-review
|
awesome, thanks for pushing this over the finish line @ehuss :) |
Update cargo submodule 9 commits in 7ecf0285ebb408d596e4a8ac76a0980d8edb7005..06ac0e7c05770a8c7bbf67bdd12fa1a1eefdc8ae 2026-04-18 15:34:11 +0000 to 2026-04-21 15:33:56 +0000 - test(git): add regression test for full-hash GitHub fast path (rust-lang/cargo#16919) - fix(help): add `.1` extension to man page temp file (rust-lang/cargo#16917) - Fix flaky test: sparse_blocking_count (rust-lang/cargo#16916) - Fix flaky test compile_offline_while_transitive_dep_not_cached (rust-lang/cargo#16915) - Fix test fetch_all_platform_dependencies_when_no_target_is_given (rust-lang/cargo#16914) - chore(ci): Use `actions/deploy-pages` for Cargo Contributor Guide deployment (rust-lang/cargo#16876) - Convert GitHub fast path to use http_async (rust-lang/cargo#16912) - refactor(network): convert .crate downloads to use http_async (rust-lang/cargo#16902) - fix(tests): flaky test local_poll_adapter deferred_success (rust-lang/cargo#16909) r? ghost
5 participants
This replaces the
gh-pagesgit branch deployment with the officialactions/upload-pages-artifactandactions/deploy-pagesactions.It requires changing the repository's Pages settings from "Deploy from a branch" to "GitHub Actions" as described also in rust-lang/rfcs#3419, which has used a similar setup for a while now.
I've tested the
buildjob in my forked repo and verified that the artifact contents match the current content of thegh-pagesbranch. I did not test thedeployjob with my fork repo, but since it is the same as in e.g. therfcsrepo I don't expect any issues from that.