Add note to include deployment as typical trigger when using this action?

[vincerubinetti]

I know technically this would be a change to the starter workflows repository, but since I think it only applies when you're using this action, I've created the issue here.

One thing I was wondering about is how to make this action run whenever the baseurl of the GitHub Pages site changed. As far as I can tell, that would happen when 1) GitHub Pages is first enabled, 2) when the repo name changes, or 3) the custom domain field changes. It doesn't seem like there are any workflow triggers that hook into a repo's settings, but there is the deployment trigger, which (as I interpret it, and in my testing) runs after each time the repo's GitHub Pages is deployed (is there any other kind of "deployment"?).

As such, if you're using this action to get the most up to date baseurl, I think you need to run it on the deployment trigger. Unfortunately this means that if you're making a commit based off of the change -- e.g. updating baseurl in _config.yaml -- then pages will build once, then run this action, then make the commit which will make pages build again. So you get duplicate builds, but I don't see a way around it unless GitHub adds more triggers.

Anyway, maybe you could add a note about using this trigger to the readme here?

Or maybe there's a better way that I don't know of?

[JamesMGreene]

Perhaps this deserves some clarification.

This is:

A GitHub Action to enable Pages and...

(see #40 (comment) for ℹ️ on ☝🏻)

...extract various metadata about a site. It can also be used to configure various static site generators we support as starter workflows.

The goal of this Action is not to update your repository contents, though you could use it that way for supported static site generator configuration file modification. 🤔

This Action's intent is to:

• (a) optionally enable Pages for Actions-based deployments, if it is not already enabled
  • Again, this feature is currently disabled right now; see #40 (comment)
• (b) offer various site metadata to be used within your Actions workflows as needed, especially for deployment purposes
• (c) temporarily modify the configuration files of supported static site generators only for the duration of a workflow run so that configuration is included when building an artifact to be deployed, such as in the Pages starter workflows

Your site URLs should not be changing without input from the repository owner, such as when applying a custom domain name or changing the visibility of the Pages site, so I'm not sure how valuable it would be to be able to have a workflow specifically trigger on such modifications. The correct version of the site should arguably already have been deployed at that point, unless it's newly enabled. 🤔

That said, as far as I know, you are correct that there currently are not applicable event triggers available for those scenarios as moving to deploying with GitHub Actions did change some of that event exposure. We should probably review those soon. 😕

[vincerubinetti]

Hmm I'm a little confused by those last paragraphs. Let me just provide some context of what I'm doing, so you see where I'm coming from.

I'm building a website template for people who are often non-technical. The biggest pain points I discovered were 1) baseurl and 2) hooking up Netlify. People did not understand what baseurl was, when/how to set it, or even that it was necessary for their website to work. Pull request previews were a needed feature, so I had instructions for how to hook up Netlify, but it was cumbersome and confusing. Thus, my goal is to use GitHub Actions to automate as much as humanly possible for the user. This includes automatically changing baseurl when needed, do pr previews right on GitHub, and also things like initializing the readme, setting the repo description/homepage, etc. I would've loved to also enable GitHub Pages for them, but alas the security bug.

Because I need to do pr previews directly in GitHub, and it's not built-in yet, I'm having to use rossjrw/pr-preview-action, which means that I must use pages in the classic way, with a gh-pages branch.

It sounds like this action is more geared toward the new "build Pages from Actions" method, where we have a workflow that (as I understand it) GitHub runs "intelligently" whenever it needs to (a change in repo content, or a user changing the Pages url in the repo settings), and thus that workflow can always be sure it's building the site with the correct baseurl.

In my case, I need to have a normal workflow that listens for pushes or other standard triggers, then builds the site and pushes it to the gh-pages branch. The deployment trigger is the only way I can see to listen for Pages domain changes in a standard workflow.

A secondary point... it sounds like you recommend always pulling the latest Pages url at build time, rather than having it statically in the repo in a _config.yaml file or whatever. I guess I could do this in my approach just by adding deployment as a trigger to the build workflow. However, I might argue the latter is better, as it's more explicit (not hidden magic going on in the workflow at build time), and building the site locally on your computer will more closely reflect the actual deployment environment. I'm still on the fence though.

Sorry for long winded discussion. In summary, I think the deployment trigger is only needed if you're building Pages the "classic" way, and this action emphasize the "new" way, which I think is fine (but some sort of clarifying note might be prudent). Feel free to close the issue.