Combine with `actions/deploy-pages`

[astrojuanlu]

This workflow seems to target the "classic" GitHub Pages experience. However, nowadays there's also the newer workflow using https://github.com/marketplace/actions/deploy-github-pages-site

I'm trying to combine the two actions but so far I've been unsuccessful: either nothing happens, or I'm getting errors coming from actions/deploy-pages saying Branch "..." is not allowed to deploy to github-pages due to environment protection rules.

Do you have an example on how to use rossjrw/pr-preview-action with the new workflow?

[rossjrw]

I'm afraid I don't currently have any examples - the above workflow is new to me! I'll make sure to assess whether the two can be reconciled at some point in the future - thanks for bringing it up.

[vincerubinetti]

I wonder if the new "Pages from Actions" option would even support something like this? Also, if people haven't seen this yet, GitHub is supposedly working on integrating this feature directly into GitHub. It'd be nice to not have to link Netlify to repos anymore!

[MattF-NSIDC]

I wonder if the new "Pages from Actions" option would even support something like this?

I think it's much harder with the "Pages from Actions" workflow, and requires sacrificing atomicity. With "Pages from branch", you can add a subdirectory easily to the gh-pages branch. With "Pages from Actions", all deployments are atomic, like Netlify deploys, which is great. Until you want to do something like add a directory to a deployed site. That might look like:

• Download the currently-deployed site (how?);
• add a subdirectory to the local copy;
• push that new directory structure as a pages artifact;
• actions/deploy-pages.

But now when your next atomic production deploy comes through, the preview is overwritten! Not as simple as I first thought to work around this. So I went with Netlify.

I'm hoping the feature GitHub is working on enables both atomic preview deploys (like Netlify) and atomic production deploys that can't step on each-others' toes, e.g. previews deploy to preview-pr-N.mysite.github.io or something 🤷

[rossjrw]

Noting that I've looked into this a little further, detailing some thoughts here: https://github.com/orgs/community/discussions/30113#discussioncomment-7650234

I'm not sure that the artifact-based deployment method has the versatility to support this action. @MattF-NSIDC raises some excellent points and I think I would have come to the same conclusions.

Looking at the 'preview' parameter of actions/deploy-pages that MattF linked, it looks like that parameter gets sent to the /repos/{owner}/{repo}/pages/deployments octokit endpoint as part of the payload. Octokit docs state 'The payload parameter is available for any extra information that a deployment system might need'... so I actually have no idea where that parameter ends up being used or what it does.

It sounds like the actions/deploy-pages maintainers don't have a timeline for it either (actions/deploy-pages#180) so I'm not particularly hopeful. If it does end up working how MattF hypothesises I'll probably jump ship to it straight away, but I'm not going to dwell on it in the meantime.

But now when your next atomic production deploy comes through, the preview is overwritten! Not as simple as I first thought to work around this.

Ironically the ideal solution to this IMO would be something Git-based... maybe the deployment artifact could be a Git repository? Maybe streamline that to be a branch of the current repository? What if you could deploy Pages directly from a branch? 😛