-
Notifications
You must be signed in to change notification settings - Fork 145
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
gh-pages build on push, not release #430
Conversation
Looks like it's not as simple as changing to on-push. |
Hi @tjex - nice catch! My reasoning behind only rebuilding on release was so that documentation doesn't get out of sync with the application features. I believe this could be extended to also include pattern matching so that README updates trigger a rebuild. There might be a place for that down the road, but while documentation gets updated (and maybe eventually overhauled) rebuilding the site on every push is probably better. |
That is an unusual error... especially considering we have the zk/.github/workflows/gh-pages.yml Lines 8 to 11 in 739d2d4
Did anyone make changes to the Actions settings at the organization level since we last deployed to Pages? |
Not at the organisation level. We actually never had any secrets / tokens at the org level. But it was to do with homebrew. Thing is, apart from the homebrew secret. We don't have any other tokens...? So I'm actually a bit confused how pages even deployed in the first place 🫤 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we shouldn't deploy on PR. Only if main
is updated
Great work all! That was a snappy turn around 💫 |
The gh pages fix from #387 setup deployment / build to occur on release publishing.
The documentation / readme is therefore stuck until the next zk semver release.
I think it's better to have the page rebuild on push / merge, as documentation updates are seemingly frequent.
@hugginsio what do you think?