Github Pages Deployment

[JayRovacsek]

Currently the Github pages deployment stems from the 'master' branch - is the project open to this being moved to an alternate branch is generally common (but not required) pattern? This would have a benefit of not including a large number of commits as result of the build/publish process in the development (master) branch

[neozenith]

Not sure I follow what you mean here? But reducing the volume of commits with our janking hombrewed automated CMS is very welcomed

[neozenith]

This is related to #92

[neozenith]

Looking into this further, the current setup is using branch based deployment.

Which in August 2022 got converted to a default Jekyll based GHAction. 🤮

Also I think part of what @JayRovacsek is describing is that the convention is the published branch is gh-pages and that branch should be purely the deployed output of artifacts.

Whilst main is the source code to generate the website.

It seems it could be streamlined to a more minimal GH Actions workflow.

https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site#publishing-with-a-custom-github-actions-workflow

which is effectively these GH Actions / Steps

• https://github.com/actions/checkout
• npm run build
• https://github.com/actions/upload-pages-artifact
• https://github.com/actions/deploy-pages

which should deploy to a github-pages Environment

this doesn’t address the many commits to update the “CMS” though.

[neozenith]

Actually it would address the many commits issue (sort of).

If gh-pages is the deployment branch, then it is purely built artefacts as commits. This is the branch that’ll keep auto updating the nightly events scraping.

main will be purely source code changes.

[JayRovacsek]

I need to clean it up a fair bit, but have got this change-set (intent is to remove some of it)

It appears to deploy correctly, I've resolved migration requirements for stuff like scss and the ability to deploy via actions seems viable (example workflow run that worked)

With the above, we can move the generation of meetup details into the build process so we can remove bot added event content I suspect 🥳

We should also be able to move the scheduled run on this to a much faster cadence as (off memory and will confirm) workflow runs are free for OSS repos and we aren't adding to the repo size with this approach

I feel that it might be worthwhile rewriting history to remove all the bot added commits - but keen for feedback on this 🙇

Forgot a link to live example; https://jayrovacsek.github.io/newwwie.com/

[JayRovacsek]

Events does seem to be broken on deploy 🤔

[JayRovacsek]

Resolved now, I need to clean up that work before I create a PR, but I believe it'll close #89, #119 & #92

[neozenith]

Closed with #139