Github Integration ignores .shopifyignore

Github Integration ignores .shopifyignore

maybach391
Shopify Partner
7 0 4

I’m using the Shopify <> Github integration for the main branch. We have build files, which shouldn’t be in the repository. We are using a Github Action, which creates and deploys the build files to the live theme. That leads to, that the Github integration adding the build files back to the repository, although the `.shopifyignore` listing these files explicit.

 

.shopifyignore:

package.json
src/
assets/checkout.bundle.js
assets/checkout.bundle.js.map
assets/checkout-legacy.bundle.js
assets/checkout-legacy.bundle.js.map
assets/components.bundle.js
assets/components.bundle.js.map
assets/components-legacy.bundle.js
assets/components-legacy.bundle.js.map
assets/index.css
assets/index.css.map

maybach391_0-1705929668733.png

 

These files are of course also in the .gitignore and we don’t commit these. But Shopify is still pushing these back into the repository.

 

Replies 2 (2)

maybach391
Shopify Partner
7 0 4

I got an update from the Shopify Plus Support:

The Shopify Support says its the expected behaviour, since the Github <> Shopify Integration is just a 1:1 mirror of the Github repository and ignores the content of config files (e.g. the .shopifyignore).

 

So unfortunately there is no workaround currently besides deactivate the Github Integration. 😕 Maybe the Integration will get an update.

noliver
Shopify Partner
3 0 3

Also encountering this issue. What we are doing as a workaround is: 

  • Theme syncs to `production` branch via GitHub integration. This could be your live theme, or you could keep it unpublished and duplicate + publish the duplicate, so that content changes can be staged before being published, but everything is still tracked in version control.
  • `release` branch is used as a staging area to keep build files out of `main`
  • To create a new release, a pull request is created for `main` => `release`. A GitHub Actions workflow syncs `production` to `release` using devmasx/merge-branch@master. This ensures that the latest changes from Shopify are shown on top of your changes. Conflicts will cause the workflow to fail and will need to be manually resolved by merging `production` into `release` locally.
  • When the pull request is merged, the sync workflow above runs again. This is to ensure any changes that may have occurred on Shopify after the PR was opened are captured. After that, the assets are built and the theme is deployed via the CLI. An input variable is used to set the `--environment` flag, so you can change the target theme as needed without touching the main workflow logic. This causes the GH integration to kick in and update production branch with the changes that were deployed via CLI. 
  • As long as `release` / `production` are not merged back to main, the build files are segregated and don't end up back in `main`.

It works ok, but does require some manual conflict resolution. It's way overly complicated for something that should be relatively straightforward. Deploying a single theme with a build step to multiple shops is a very common use case, but unfortunately Shopify has pushed for a strongly opinionated theme development system (no build process), and a backwards way of thinking about theme content management (content / settings data being stored in theme files instead of a separate data layer that is abstracted from the theme), so this is where we end up.