I work with a local copy of my code (1). I make changes. I can run `hugo` to build my page. And then I want to push my code to 1/ and the public folder content to 2/.
QUESTION
How could I achieve the desired state properly?
I experimented with subtrees today, but I had to force the push to the public folder. I am lacking git experience here. But it did not feel right. Therefore I am reaching out here. Topic “is-it-possible-to-use-hugo-in-codeberg-page-repositories” touched on this topic, but I am only allowed to provide two links.
Thank you very much in advance. This forum has always been very helpful for me.
David
If I get your hint right, then the main point is that codeberg page is in maintenance mode. Do I understand that correctly?
From what I know, all necessary updates have been performed on codeberg side. It is just the documentation which needs to get updated on their end. So, I think it is valid to think about codeberg pages setups again.
If they remove the “maintenance mode” warning, we can consider adding a guide to our documentation. I say consider because the previously documented setup process was, as least to me, complicated and confusing.
Fair point.
Let’s revisit this topic when the status is clear and documentation is updated.
Thank you for your feedback.
Last question:
Do you think that Codeberg should have a good documentation on how to host Hugo based websites on Codeberg pages? Or do think it is more fitting for Hugo to document how hosting on Codeberg could work?
Honest question.
For mainstream services used by a sizeable percentage of our user base (that’s the subjective aspect of this) such as Cloudflare, GitLab Pages, GitHub Pages, Netlify, Render, and Vercel, I think we should provide documentation:
User Flow: When I first started working with Hugo, as soon as I finished the quick start guide my next question was, “How can I automate build and deploy?” Having the answer in our docs makes for a better experience.
Support: It reduces the number of “this isn’t working” topics on this forum.
Control: When something changes, either on the service side or on our side, we control the documentation and can immediately update as needed.
Keep in mind that for every guide we provide there are costs: creation, maintenance, testing, testing, and more testing. I maintain repositories for test sites hosted with Cloudflare, GitLab Pages, GitHub Pages, Netlify, Render, and Vercel, and I frequently… test them. I really don’t want to add another one to the mix unless there’s a decent ROI.
Along the lines of “a sizeable percentage of our user base”, I have been thinking about removing the guides for AWS Amplify, Azure Static Web Apps, and Firebase. I know, these are major players, but they are not major players within our userbase.