search

berkeley-cdss / course-site-myst

A MyST-based course website template
0 stars 1 forks source link

instructions conflict with existing action #2

Open ryanlovett opened 11 months ago

ryanlovett commented 11 months ago

Quoted from @paciorek in #1 :

  • Because we say to make a commit before running myst init --gh-pages, MyST tries a deployment that fails based on deploy.yml, so the user will get an email indicating that failure (e.g., here's a failure from my test).
  • When one runs myst init --gh-pages it tells the user they need a new name for the deployment yml file, and then one would have two GH actions.
  • I wonder if we should provide the details of what the user needs to do after myst init --gh-pages.
  • MyST tells the user to "Enable GH pages" but it's not clear what to do to do that. I don't think the user needs to do anything specific for this.
  • MyST says to use GHA as the source. We may want to warn the user that it's ok that this is in Beta.
paciorek commented 10 months ago

Yeah, I thought we could remove the myst init --gh-pages step and tell the user at the step before making any commits to go to https://github.com/example/stat555/settings/pages and under Build and deployment select "GitHub Actions" as the source, noting it is listed as being in beta.

That sort-of works, but the initial commit when the repo is forked on the GH website does trigger a failed action and an email to the user.

We could add a warning to the user that this will happen (and would happen whenever they make a commit if they haven't followed step X (where step X is the one where they set the source for GH pages).

Part of the awkwardness here is that a user might not want the website to be public initially. So we might want to tell the user how to avoid this. We could tell them to move deploy.yml aside until they want things public. Then they would also not get the messages about failed runs.