I am using Shopify Online Store 2.0 with Github integration. I am wanting to use one master branch that will be used across multiple stores. All the stores will be identical with small changes being made with liquid conditions.
This all works fine apart from the theme settings config files. I want a unique settings_data.json file for each site as the sites will have different content, but with the same codebase. When I make a change in the theme settings it then pushes this change to Github which then updates the theme settings for all the other sites.
What is the best approach for dealing with this? Does anyone have a workflow strategy that they can share that solves this issue?
Also currently looking for a good workflow for this.
as an agency, we want to have one GitHub repo with our āmainā default theme and have custom configurations of that theme be used across many client builds. When we add new features to our main repo, it would be great if all the clients using that theme could get the updates.
right now weāve got it setup as a ātemplateā repo and we start new repos per client. Hard to keep the client sites up to date as we implement new base features though.
I am thinking about having different branches the live themes on each store, connected to the same Github repository, so that the changes through the theme customizer are being kept track of.
The problem presents itself when wanting to work on a specific feature: which branch do I create the feature from (what is the real source of truth)?
Thinking it might be easier just to have a different repository for each store, even though it increases the time to manage any change to the code
@RossellaF The solution I ended up coming up with is having all our Stores connect to the same repository.
Our branching strategy is having a different live branch for each site that will serve as the live theme.
For my specific use case, the majority of the code would be identical apart from the custom content being loaded on them via the Customiser (apart from a few small changes). So my solution was creating a Github workflow. We create the branch, complete the development work, then push to the Release branch. I setup a Github Workflow to exclude the settings_data.json and settings_schema.json files. Then on push to the release branch it runs a bunch of git commands (not the cleanest) to checkout each of the live branches for each site and push all the changes excluding the settings files to all of our Live themes at the same time. This doesnāt overwrite the customiser settings.
Saying this, there are a couple of liquid conditions for unique code for Tracking and other small bits, but other than that this solution worked the best for me. Definitely improvements can be made though!
I see. So technically you donāt have the Github integration set up, but you replicate that functionality with Github workflow instead. What happens if you need to create a new custom section? Do you add the code from the Shopify code editor directly?
We are using the Github integration for our live themes. Each live theme has itās own Github branch (live/store-name). We do the development work on another branch and push to a branch called āReleaseā. The Github workflow triggers when something is pushed to the āReleaseā branch. From there, that workflow pushes all the code changes excluding the setting files to all the other ālive/store-nameā branches. As we have the Github Integration set up, it then updates all the code on Shopify (without overwriting the settings files!).
Struggling with this solution. Iām pretty novice with GitHub so please correct me if Iām wrong with any of this:
GitHub: main pushing theme files to several live branches using a workflow with paths-ignore excluding config and templates directories.
The issue (I think!), is that a directory (e.g. templates) specified in a GitHub workflow with paths-ignore references the directory of the changed files, not the destination directory. So a file changed outside of ātemplatesā will trigger the workflow, but one changed inside ātemplatesā will not. But when the workflow IS triggered, it updates all directories including ātemplatesā. So for me this workflow hasnāt solved the issue of preventing the JSON settings files in the live branches from being overwritten.
I really hope Iām 100% wrong and have set something up incorrectly ā please let me know if so!..
I did end up with a pretty good solution which has been working so far. It takes a bit of setup and uses github actions. This is just a rundown of what it involves..
Create a main repository, along with another repository for each storefront.
Each repository will start out identical to one another.
Each repository will have 5 branches: master, production, staging, preliminary-production, preliminary-staging.
The main repository has a github action that triggers on push to either staging or production branches.
The workflow contains a job for each child theme and runs one after another.
The workflow described in each job is roughly as follows:
An environment/container is created with rsync and git installed and configured.
A source directory is created containing all files of the repository (the main repository which is running this action).
A destination directory is created by cloning the child theme repository that this current job relates to.
The branch of the destination directory will then need to be switched to the preliminary branch that you are pushing to (ie. preliminary-production).
Rsync is used to sync the files from /source to /destination. The important part here is to exclude the directories of āconfigā and ātemplatesā as these are specific to the storefront theme configuration.
The changes that are now present in the preliminary branch of /destination now get committed, merged, and pushed.
The preliminary branch is then merged into the main branch (ie. preliminary-production to production) and pushed.
Check the action logs in github to make sure it was successful and there were no merge conflicts.
In the event of merge conflicts, manually fix them in your editor. This shouldnāt happen unless code is changed outside of this workflow and you end up with merge issues.
Basically, youāre only ever making changes to the main repository. The rest is handled by the action workflow.
I have had all the struggles outlined in this entire thread. Could you share a repo with your solution? It would be lovely to be able to dig into and understand.
It seems that this workflow specifically includes the theme .json files in the merge? (or I may be reading it wrong? Iām not super familiar with gitworkflows) ā my issue is that .json files need to be excluded to maintain any individual site settingsā¦
I havenāt dug into the action in that repo, but youāre right, you want to exclude the json files in the config directory. I outlined this in one of my previous replies.
No no. It specifically excludes all the settings files, even to the level where it leaves in the settings_schema so you can publish new changes to the schema to all live stores.
It is literally made exactly for this scenario.
