Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish dev-docs with Github Pages artifacts (2nd attempt) #10892

Merged
merged 5 commits into from
Jan 2, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 24 additions & 9 deletions .github/workflows/docs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -5,13 +5,30 @@ on:
branches:
- 'main'

# Allows running the action manually.
workflow_dispatch:

env:
CARGO_TERM_COLOR: always
RUSTDOCFLAGS: --html-in-header header.html

# Sets the permissions to allow deploying to Github pages.
permissions:
contents: read
pages: write
id-token: write

# Only allow one deployment to run at a time, however it will not cancel in-progress runs.
concurrency:
group: "pages"
cancel-in-progress: false
Comment on lines +21 to +24
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this choice? Cancelling would make sense here, we only care about the last version

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the example for using pages artifacts, the following comment is provided about the concurrency setting:

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.

My best guess is that perhaps cancelling the deploy job while it's still uploading to Github pages could be bad, but I've never tested it. (See docs on concurrency.)

I think it would be best to leave this. The developer docs don't seem like a time-sensitive thing. If this is a risk of messing up Github pages, I don't think it's worth the couple of extra minutes saved.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of adding that for now, but it doesn't really matter


jobs:
build-and-deploy:
runs-on: ubuntu-latest
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
- name: Checkout
uses: actions/checkout@v4
Expand All @@ -37,19 +54,17 @@ jobs:
# - A top level redirect to the bevy crate documentation
# - A CNAME file for redirecting the docs domain to the API reference
# - A robots.txt file to forbid any crawling of the site (to defer to the docs.rs site on search engines).
# - A .nojekyll file to disable Jekyll GitHub Pages builds.
- name: Finalize documentation
run: |
echo "<meta http-equiv=\"refresh\" content=\"0; url=bevy/index.html\">" > target/doc/index.html
echo "dev-docs.bevyengine.org" > target/doc/CNAME
echo "User-Agent: *\nDisallow: /" > target/doc/robots.txt
touch target/doc/.nojekyll

- name: Deploy
if: github.repository == 'bevyengine/bevy'
uses: JamesIves/github-pages-deploy-action@v4
- name: Upload site artifact
uses: actions/upload-pages-artifact@v1
with:
branch: gh-pages
folder: target/doc
single-commit: true
force: true
path: target/doc

- name: Deploy to Github Pages
id: deployment
uses: actions/deploy-pages@v2