-
Notifications
You must be signed in to change notification settings - Fork 1
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
PR staging deployments for Pages #15
Conversation
…m docs/ so we're going to do some guess and checking here
|
@rossjrw hope you don't mind me tagging you in here but I'm having trouble understanding what about the config needs to change for the preview link to come up as https://numist.github.io/highlight-css/pr-preview/pr-15/ (instead of https://numist.github.io/highlight-css/docs/pr-preview/pr-15/, which doesn't exist) It looks like changing |
No worries @numist. If my understanding of what you're trying to do is correct, you're deploying to GitHub Pages from the I think this is a difficult way of going about things. That's not to say it's wrong, or that I know any better than you about what's best for your codebase. But I think it might cause you a couple of issues down the line. Consider this situation:
You could probably avoid this happening by careful application of ignore rules, manual steps to delete junk files, etc. But IMO it's a lot easier to avoid that happening in the first place. One rule I personally try to stick to is that the main branch should only contain files written by humans. For my repos that use GitHub Pages, I deploy from the I notice that you had a Given that your site now includes a mix of human-written and machine-generated files, I think you should be deploying your Pages site from a staging branch e.g. So here's what I'd do: I would create two Actions workflows - one to deploy the Pages site to the gh-pages branch on push to main, and another to handle previews. I like https://github.com/JamesIves/github-pages-deploy-action, so that would look something like this:
# .github/workflows/build.yml
name: build
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Deploy
uses: JamesIves/github-pages-deploy-action@v4
with:
branch: gh-pages
folder: docs/
clean-exclude: pr-preview/
# .github/workflows/preview.yml
name: preview PRs
on:
pull_request:
types:
- opened
- reopened
- synchronize
- closed
paths:
- docs/**
- .github/workflows/preview.yml
concurrency: preview-${{ github.ref }}
jobs:
deploy-preview:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Deploy preview
uses: rossjrw/pr-preview-action@v1
with:
source-dir: docs/ Then configure your Pages site to be deployed from |
Basically yes, though what's even weirder is that the ultimate goal is for all files except
To your point, probably the "rebuild succeeded" check is all thats really necessary and a preview system that checks previews into the repository is not especially compatible with this scheme; I've just suffered too much drycoding Markdown + Liquid and would love to stop committing incomplete sins to |
Fixes #12