Small set of fixes - Githubissues

uwhackweek / jupyterbook-template

Template repository for UW Hackweek JupyterBook websites

http://book-template.hackweek.io/

MIT License

9 stars 6 forks source link

Small set of fixes #147

Closed jomey closed 7 months ago

jomey commented 7 months ago

List of changes:

Updated the SnowEx url and years in the README
Fixed a typo
Add .css files to the ignore list for the QA/QC GH action

github-actions[bot] commented 7 months ago

🚀 Deployed on https://deploy-preview-147--hackweek-template.netlify.app

jomey commented 7 months ago

Hm ... We should have triggered a build here since there were changes to the book.

JessicaS11 commented 7 months ago

We should have triggered a build here since there were changes to the book.

Should we have, given the preview tag was added after the changes were merged (and the branch deleted) and the branch protection is on main?

Recap: The branch protection for main is for "Build and test on OS - ${{ matrix.os }}". That job lives in build_website.yaml and (1) is only triggered by "preview" tag; (2) is for PR targets to main.

I think we set it up this way because we were waiting forever for the book to rebuild in PRs when we made small modifications to the splash page or something. Using the "preview" label trigger allowed us to still require the test to pass in event PRs via "require all checks to pass"... it looks like you can now choose to copy branch protection rules when you create a new repo from the template, but could not when we created this template. @scottyhq @jomey Thoughts on how (if) we want to modify this structure?

jomey commented 6 months ago

Here my current understanding of this workflow:

Builds should be triggered upon labeling and pushing to a branch with target 'main' based on this action configuration
To reduce the run time for small changes, we added caching of book files after an successful build

The first bullet is the part where I am wondering why it didn't trigger, since one file is part of the defined changed paths.

Maybe this could be part of a re-visit of the template and ensure we have the actions triggered when we expect them to be.

JessicaS11 commented 6 months ago

Builds should be triggered upon labeling and pushing to a branch with target 'main' based on this action configuration

That's my understanding too, but we (in this order):

pushed to a branch with a target 'main'
merged the branch and deleted it
added the 'preview' label.

In which case, did we actually meet the "labeling AND pushing to... target 'main'" requirements to trigger the workflow? I'm thinking we should mock up a new PR that's got the same files changed but add the preview tag right away. If it doesn't trigger the workflow, then we've got a problem. Otherwise, it may be on us for not-completely-literal thinking. ;-)