rewrite/possible-PR that I accidentally did

[knzconnor]

master...knzai:zola-deploy-action:master

So I meant to just add in the ability to keep history on gh-pages... and I got carried away.

This is a complete rewrite into decomposed composite actions. Let me know if this direction is of any interest, or I should spin it off as a separate project.

Next (well after fixing history on gh-pages) I'd probably break it down a bit more and see if I could use an existing deploy-to-gh action and make this just zola that could be used with that, or push to sfto/whatever, or heroku (why? cause people) etc. If it were just zola CLI and solid, we could ask zola team to move it under their org as the official actions/zola!

Let me know thoughts and interest. If you want make me a collab and I'll make a PR with any required changed.

[knzconnor]

Oh, I was probably going to also move test-site into a branch (and add an option for build from branch).

Maybe get funky and make sub-actions via subtree and branches. could have the build and check things be stand-alone in case people wanted to use them via action-name@syntax but still live in the main repo to not need an extra submodudule checkout

[shalzz]

Can you please describe the changes you are proposing to make, in addition to having history on the deployment branch?

From a quick look it looks like a major change in the way variables are defined and provided to the action, so it would be better to have it as a separate/new action so that we don't break the workflow of people already using this action.

[knzai]

To start, not erasing peoples repositories (based on some comment I saw in Discourse) if they get it wrong. No unwarned force pushes in an action!? Or overall forcing history erasure (that was why I started my refactor). And in the process isolating the action to be just the zola pieces for easier maintenance (and leaving github token issues to the checkout or deploy step to simplify the code and usage). And using a composite action for composability etc (see zola-cli@check).

It seems like most of the open issues go away if you don't do the git push step manually yourself: cross host auth tokens, history, etc are simpler just relying on a checkout action and pushing to that, much less using an action to even manage that. Originally I just did the checkout then mv .git to the content folder shuffle, but it was even simpler when I stopped managing that piece manually myself.

In the end I just ended up refactoring my own to use James Ivey's more generic and broadly used "deploy to gh-pages" for that step and focused on the zola. :)

Since you have the repo that is referenced in documents, and I started with that I'm happy to push any changes upstream of course. But as it's a much different approach at this point, so if you decide it's not a direction you like, I gave you a shoutout in the acknowledgements (even if I'm not sure there's an original line left).

Cheers

https://github.com/knzai/zola-build
https://github.com/knzai/zola-cli