Shopify Github integration - support for multiple stores

Partner Discussions
1

Shopifolks: Is there anything on the roadmap for managing a theme codebase on multiple stores using the Github integration?

Currently it requires quite complex Github workflows (or other external scripts) to handle discrepancies and unique JSON files per store using various branch strategies.

A quick (not perfect) solution could be that the integration supports .shopifyignore and simply ignore JSON files in the integration.

Generally what I’m looking for is a structure like

  • main
  • */production branches linked to the theme on n stores
  • feat/*, fix/* or whatever feature branches that I’m working on

I’m still considering DevKit, but not there yet.

If someone found the perfect general Github workflow handling the following, please let me know :yum:

  • Pushing theme-code files (not content/settings) to */production branches (github integration branches) on main merge/push
  • Not sharing JSON-changes from */production integration-branches to main or other */production branches
  • Sharing theme-code changes from */production to main and rest of the production branches.
1 Like
2

Hey Curzey,

Would this community built tool help?

Shopkeeper makes it easy to manage multiple Shopify stores from a single codebase. In particular, it makes it easy to switch between store instances and manage theme settings.

It uses a .shopkeeper folder at the root of your project to store buckets of settings.

4

Thanks Liam,

I took a look at it yesterday - and it does look promising. So do Devkit very much.

Though I was hoping it could be simplified a lot. I would appreciate not having to maintain such custom workflows simply for managing a theme on expansion stores. It’s very limited how much I do work with this, so the current more manual method does work - it’s just not optimal :blush:

Working with a single store using the CLI and default Github integration works just fine, at least for me.

1 Like
5

Totally understand the value of easily being able to switch between stores - as far as I know there’s no immediate plan to natively support multiple store switching, but I’ve connected with the product team on this.

This could also be a good question to ask during the next Twitter AMA with the Liquid team

6

Thanks for the twitter link. Will try that.

A subtle way of “supporting” it, could still be to simply make .shopifyignore work in the integration (or another similar file to allow for different rules).

7

I’ve setup something with Github Workflows myself, the largest “group” I have is 8 stores, whereby changes are automatically copied and compiled from the primary store when released.

8

If you’re willing to share, I’d like to see the workflows :raised_hands: Also understand if not…

9

Would really appreciate this feature.

Currently have many stores on a similar codebase, would love to be able to share new sections and features across all stores and keep the json settings local to each store.

10

Yup here’s a simplified example of a Github Action I’ve setup


"on":
  push:
    branches:
      - main
    paths:
      - 'snippets/**'
      - 'sections/**'
      - 'config/settings_schema.json'
      - 'templates/*.liquid'
      - 'readme.md'
      - '.shopifyignore'
      - '.gitignore'

jobs:
  deploy:
    concurrency: ci-${{ github.ref }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Create Output Folder ready for transfer
        run:  |
              mkdir output

              mkdir output/snippets
              rm -rf snippets/*custom*.liquid
              cp -r snippets output

              mkdir output/sections
              rm -rf sections/*.json
              rm -rf sections/*custom*.liquid
              cp -r sections output

              mkdir output/templates
              rm -rf templates/*.json
              cp -r templates output

              mkdir output/config
              cp config/settings_schema.json output/config

              mkdir output/assets
              cp -r assets/icon-* output/assets

              cp readme.md output/readme.md
              cp .shopifyignore output/.shopifyignore
              cp .gitignore output/.gitignore

      - name: Send changes to Repo A
        uses: JamesIves/github-pages-deploy-action@v4.6.1
        with:
          branch: production
          repository-name: REPO-WORKSPACE/REPO-A
          folder: output
          token: ${{ secrets.PAT }}
          clean: false

      - name: Send changes to Repo B
        uses: JamesIves/github-pages-deploy-action@v4.6.1
        with:
          branch: production
          repository-name: REPO-WORKSPACE/REPO-B
          folder: output
          token: ${{ secrets.PAT }}
          clean: false
3 Likes
11

Thanks for sharing - will try to work from this. Looks more simple than what I was brewing

1 Like
12

Using .shopifyignore for JSON files sounds good. For syncing themes across branches and stores, workflows or DevKit help, but it’s tedious. Skyvia might simplify multi-store integration

13

I’m using a setup with Buddy, I have a main and staging branches which contains the source code, then each store has two repositories, again one for main (live theme) and the other a staging theme, these only contain the theme files and are also connected via the Github integration (allows to track any template/settings changes).

Then in Buddy the pipeline simply runs an npm run build (as I have a setup using Vite) and it then uses the Shopify CLI integration to push across all the stores.

2 Likes
14

Finally had time to look more into this.

When the different expansion stores has different JSON files etc; how do you handle the annoying Github note “This branch is n commit behind main.”? Do you just ignore it?

Also, I guess you have something similar setup to sync the other way? In case a third party, or the client, actually updates some code via “Edit code” in Shopify.

15

Also, I guess you have something similar setup to sync the other way? In case a third party, or the client, actually updates some code via “Edit code” in Shopify.

This is why I have independent branches for each store, so it tracks the changes that clients make in the customiser.

1 Like
16

Yeah, same - my question was more regarding if people has a workflow to merge those change into main and the other branches/stores. Can’t figure if that makes sense or not.

I have a setup like
main: theme code source of truth
store1/production: the linked theme on store1
store2/production: the linked theme on store2

pushes to main merges theme code to */production branches

image
image517×159 34.2 KB

This makes sense because of the discrepancy in the JSON/content files, but it still triggers me :smiley:

17

I don’t ever push any JSON files into those branches, they’re isolated. I’ve just done another setup with Github Actions which actually uses the CLI to pull the content from a store before doing a push, again so nothing is overwritten.

1 Like
18

Oh my thought was to directly use the Shopify Github integration that automatically two way syncs the store theme code and the connected branch :smiley:

And then sync theme code files between main and store-connected branches :blush:

19

I just use Shopify’s built in Github integration

20

Assuming you have a connection structure like mentioned above, the built in Github integration would sync to the connected branch.

Usecase:

  • Client / 3rd party adds a data attribute to an element in a /section file. They need it for a gtag listener - or whatever
  • Shopify built in Github integration syncs this change to the connected branch

In my case, and what I was originally opening the discussion for, I want the change to sync into the theme code source of truth main. Firstly because I dont want to overwrite it next time a main push modifies that file, but also because the other connected stores (branches) should also get this change.

Not neccesarily asking for any direct solutions here, as I now have a good base for it and easily could build this. Just trying to explain the full usecase – and IMO missing opportunity in the current integration – for the context of this discussion thread :pray:

Also thanks for contributing!

21

Ah I see! So the way I have it setup is I have one store which is “Main” any changes to that get synced to the others as/when a certain files get changed.

Theoretically there’s nothing actually stopping you from having that Github action on the “child stores” too, whereby they then push the change to the “Main” store.

I’ve actually done this for a B2B Store, whereby it pushes back to the main store (but on a B2B branch so I can check before merging).

You could however run into a race condition… i.e.
Store A has product template updated to include a new className
Store B has product template updated to include a new data attribute

Whichever one wins the race will be the resulting final code - that’s why I generally have a main / parent store and child stores.

Theme.liquid I exclude from the sync as this is often where most Apps inject additional code into the theme.

Not sure if that helps?

1 Like