I have reproduced the issue on the latest CLI version.
Yes, I am on the latest version
I have searched existing posts and this report is not a duplicate.
Yes, this isn’t a duplicate
In which of these areas are you experiencing a problem?
Theme
Expected behavior
I’d like to set up a Github Action which will trigger on a new pull request.
This would checkout the branch files containing theme files, use the Shopify CLI to create a theme instance in a store, then attach theme preview and editor links in the Github pull request.
This is so reviewers in Github can review proposed changes quickly.
I want to use:
shopify theme push --json --development
Access to the store for the CLI would be via a Theme Access Password that’s unique to the action on that GH repo.
The docs don’t seem to describe what the --development flag does very clearly:
-d, --development env: SHOPIFY_FLAG_DEVELOPMENT
Push theme files from your remote development theme.
What I want to happen:
PR is created in a Github repo
Action runs and sets up a hidden development theme instance that is unique to that PR
PR is updated with a link to the theme preview and editor
If any other PRs are opened in the same repo / with the same Theme Access Password, we still get unique theme instances each time (i.e. we don’t just overwrite a single dev theme instance each time)
I suspect this can’t be guaranteed, and I’ll have to create a merchant visible theme then somehow automate the deletion of that theme when the PR is merged or closed.
But it would be great if we didn’t have to do that, and that the command above would keep making new unique theme instances each time it is called. It’s fine for those dev theme instances to be auto-deleted by Shopify after a period of inactivity on them for garbage collection purposes.
Keen to hear the best practice for this before we set anything up!
You’re right to question the --development flag. It can get a little wonky especially when being triggered from CI. We have a similar flow in our repos that looks like this:
Generate a theme name based on the Git branch (making sure to keep it within Shopify theme name limits)
Delete existing theme with that name (say you’ve pushed to the PR again)
Push the theme with -d
Parse the output to create environment variables for next steps
Rename the theme
Add comment to PR
Sprinkled throughout there are bits of error handling and other things specific to our workflows.
The push-then-rename flow was really done as a temporary thing. This is a common enough flow that we should more appropriately handle it from the CLI. I’ll make sure to get an issue tracked for this.
The docs for shopify theme pushdon’t seem to (clearly) mention anything about where you can specify the name of the theme in conjunction with --development?
Don’t we still have the issue where a development theme using the same access token is going to get overwritten the next time the same command is run (on a different PR, for example). It’s a bit unclear how this works, actually.
If there is a way to generate new dev theme instances which are guaranteed not to be overwritten, and just get auto-deleted by Shopify if unused for say 30 days, that would be the ideal. I’d rather not have merchant-visible theme instances, because this uses up merchant theme instance limits and also creates clutter / confusion for merchants
Any further insight on what works today with regards to this would be great!
You can’t at the moment, that’s why I mention that our flow uses a “rename” step. I’m going to add a change to the Shopify CLI to allow passing a name to the theme push command which will greatly simplify this part.
I’ll make it so that passing a --name flag always creates a new theme since if you wanted to updated an existing theme you’d use the --theme flag.
Creates a new development theme - always new, never replaces any existing development theme associated with the auth key/user
As it’s a development theme, it’s hidden from the merchant and doesn’t require them to have theme slots remaining (some store plans are limited on how many theme instances you can have, or have used them all up)
Returns json containing the preview link and editor link, and other values as they do currently
Theme gets auto-deleted after a period of time (how long?)
I’m just thinking about how best to manage removal of theme instances created when a PR gets more pushes to the branch. We can configure the Github action to run another shopify theme push command, but there will still be comments on the PR with links to the old theme instances. I guess we could scan through the comments and find theme IDs to delete but seems a little risky.
Also just thinking it might be more intuitive to bake this functionality into shopify theme share instead? As sharing a theme is exactly what we are trying to achieve. You’d have to make the --development , -json and the potential –-nameflags available to that command.
For PR comments you should be able to check if a comment exists already (github.rest.issues.listComments and then search through them) and then you can either edit the comment or create a new one depending on the result. This shouldn’t be too risky!
You could also potentially check for the existence of the development theme first and then push to it to overwrite it. That would require making sure you have deterministic theme names that can’t clash with other PRs which might not be safe.
I plan on talking to the team a little bit more to make sure we’re all on the same page but I think adding --name to theme push is the easiest/clearest path.