Aha, that makes sense! The intended workflow is that everyone’s secrets get merged together in the
secrets section, so you have one source tree that works unmodified in everyone’s checkout of the app. If you’re having trouble accomplishing this with GitHub PRs (ie if GitHub is complaining about conflicts), you can use Anvil’s merger to handle it. The rest of this post dives into how this works, and how you can use Anvil’s merger even if you’re using GitHub to enforce code review.
More detail follows:
How this works is that the
value in your YAML above is keyed by the app ID. This means you can store values for a secret corresponding to several different apps in the same
anvil.yaml, and run the same source code checked out in a number of different apps: Anvil will pick the correct one for whichever app this source code is currently running in.
My guess is that you’ve avoided doing this because you’ve previously tried merging two versions of an app, from two different contributors, with separate secret values, and GitHub has complained about conflicts. However, Anvil has a content-aware merge system that knows how to merge Anvil apps, and it should handle this sort of thing with no problems.
So if you’re seeing conflicts in GitHub, try doing a “backward merge”. That is to say, before submitting or merging a PR in GitHub, use Anvil to merge changes from the target branch (usually
master) into the PR branch first. That way, the changes from the source and target branches are merged with Anvil’s merge algorithm – which knows how to handle YAML config, components on forms, etc – rather than GitHub’s default algorithm, which only knows about text. When GitHub comes to merge the PR branch into the target branch, it will now go smoothly because Anvil has already done most of the work.
This technique is also useful for resolving conflicts in drag-and-drop form design. For example, if I edited the text on
button_1, and you moved
button_1 from one container to another, GitHub will see that as a huge merge conflict. However, Anvil’s merge algorithm knows about the semantics of components in
form_template.yaml, so it will realise that those two changes were independent, and perform the merge without complaining.
TL;DR: If GitHub complains about the PR, try a back-merge in Anvil first!