- My goal: Changes that get merged into the main branch should immediately appear in the Retool app. All merged PRs should go through the release process before being available in the production environment.
- Issue: If a PR is created (or last edited ?) in the production environment in Retool, when the PR is approved and merged into the main branch, the change goes directly into all releases which is not ideal. We want all merged PRs to be revealed to our end users only when a release is published.
- Steps I've taken to troubleshoot: It’s hard to troubleshoot since any attempts to figure this out may effect our production release.
- Additional info: (Cloud or Self-hosted, Screenshots). We are working in a self-hosted instance of Retool. Our work-around:
If the url listed after “Preview all changes here” in the PR points to production, the issue will occur. To fix the PR, we have to start editing the app, set the environment to development, change something, commit that change. Then, if we go back to the PR, the url will point to development which means the PR can be approved and merged. At the point, the change is in the main branch but won’t appear for users until a release is created (and for our end users, published).
Doh. “My Goal” should read: “Changes that get merged into the main branch shouldn’t immediately appear in the Retool app.”
Hi Chris,
Thanks for that breakdown — I had assumed you meant that!
For the end user, it should be the case that they only gain access to the new changes once they have been released from the preview view of the app. I’ve tested this on our side, and it’s working as expected.
To confirm the steps:
-
A new branch is created from main, edits are made, and a PR is pushed into the source branch (production in this case).
-
The app is viewed in preview mode — changes are compared, and a release is made. See screenshots attached.
-
The end user can then see the updated version.
That said, this process only applies to the end user. Any further development work or new branches a created are created from the source branch, not from a version. And so all the merged PRs are visible to editors.
If this is not the case could you share more specifics on your steps of how the PR is being merged into the source branch and how this is being shown in your ‘live’ releases.
Within the release modal, accessed from the app preview, you should be able to view the release history which will include the merges from source control and when they were moved to live. Please see the screenshot below where you can see the most recent merge and how it has now been included in the live release. I would hope this should give a good indication as to what might be happening here.
For a more detailed explanation, here’s a great breakdown of how releases and can source control work together: 
Using Releases, App Versioning & Source Control Together.
Thank you!
Ollie
The process you described is how we understood it to work, but in this one case, we are experiencing something different. It all seems to hinge around which environment the last changes were made in. If Development, then it works as described. If Production, the changes go live immediately without waiting for a release to be created. I was hoping it might be a version issue, but we are using Retool version 3.284.1. Any other ideas?
Another detail: the instance where I've seen this happen is when replacing an image component with an html component.
Frustratingly, I haven’t been able to reproduce the issue in a different app. So, was it specific to the original app or the commit itself? We don’t know.