Over here at Umbraco DevRel Towers, we’re working away on a new Umbraco community website. You lot are up to so many great things and we are very aware that the current site just doesn’t do you, or your activities, justice!
A deal-breaker for the new site is that the community can contribute to the codebase and help us make it a site to be proud of. We also want to drink our own champagne (much more fun than eating dog food!) and host this site in Umbraco Cloud.
Cloud already has the Umbraco CI/CD Flow that enables you to develop using a separate repository - I call it the “working” repository - and to automate the updating of the Cloud repository using e.g. GitHub Actions or Azure DevOps. The benefit of this approach is that you can follow the same branching strategies and code review processes as your other projects and work on all your codebases in the one place, e.g. GitHub.
However, this working repository will contain some sensitive data that should not be visible to unauthenticated people: specifically the license key files, and the umbraco-cloud.json file. You can’t just make the repository public and open for contributions!
So we’ve come up with a good way of working that does not have any sensitive data in the working repository. Or at least we think we’ve come up with a good way. We’d really appreciate more folks casting their eyes over it and trying the contribution workflow for themselves.
We have built a simple Cloud site with an accompanying public GitHub repository so you can see what we’re proposing. When we push to the main branch, a GitHub action pushes to Umbraco Cloud to update the repository and deploy to the live site.
There are some limitations, but we think they are easy to live with if it means the community can contribute!
You will never sync from the Cloud repository back to the working one, so version upgrades will need to be done manually on the working repository. We are happy with this! Although perhaps it is possible - raise an issue and explain to us if you think so!
When working locally you won’t be able to restore content from, or indeed transfer content to, other environments as you usually do with Cloud. Ok, we can use Deploy’s Import/Export feature instead! See issue #4
Do you want to help test this or review the GitHub action?
Go to the repository and read the readme and / or watch the recent DevRel Deep Dive where Seb & I walk you through the contribution workflow.
If you’re wondering what was involved in setting this up - perhaps you have your own Cloud site that you’d like to make open source - then checkout the setup instructions in the GitHub repo. The Cloud site I started with had just a home page (document type, template and content node). But this approach should work for cloud sites with far more!
And of course please let me know if you have any improvements to suggest!
Top comments (0)