Issue with secret keys when cloning from Github into Anvil

Anvil Q&A
#1

Hello everyone,

I’m encountering a problem with an Anvil project that I need to share with multiple collaborators. To streamline the process, I’ve backed up the project on Github so that each collaborator can clone it into their Anvil platform.

The issue I’m running into is that the secret keys get overwritten with each commit. I’ve noticed that the anvil.yml file encrypts them differently for each user, which has been causing some challenges for me, and I’m keen to find a solution.

I’m aware that one approach might be to directly share the app from Anvil, but the reason I opted not to is that I need each collaborator to have separate databases.

Has anyone faced a similar problem or have any suggestions on how to handle this? Any guidance would be greatly appreciated.

Thanks in advance!

#2

Depending on what your collaborators actually do with the project (logically and physically), this might be of use: Depending On Other Apps

#3

Wait, er, what? This definitely shouldn’t happen. The intended behaviour (as documented) is that each Anvil app (ie, in your workflow, each user’s copy of the application) needs its own secrets set up separately. This keeps secrets private to each app. However, once set up, secrets shouldn’t be overwritten by anyone else!

Are you able to send a link to the app, with a timeline of what happened with each commit and where the secrets needed restoring, to support@anvil.works? We’ll take a look.

#4

Thank you for your quick response, and I apologize for the confusion. I may have not explained myself correctly.

The issue isn’t that the secrets are being overwritten with each commit. The problem is that the anvil.yaml file, which contains the encrypted “secrets” key, is different for each user. As this file is part of the commit, the versions pushed are always different for each user. This is what’s causing the inconsistency.

anvil.yaml has this key “secrets”, but also other keys needed for the settings:

secrets:
  TITLE_KEY:
    value: {D4GI...5IQ: nRusOM...smkUMZVstw=}
    type: secret

So, when another user clone from github, the secrets are empty on their app. They fill them and when push to github inconsistencies appear.

If the secrets were in a separate file, we could simply add it to .gitignore and prevent it from being part of the repository, thus avoiding the problem.

Is there a recommended approach for handling this situation within Anvil?

Thank you again for your assistance.

#5

Hi @albert,

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!

1 Like
#6

Thank you for the detailed explanation.

I tried following the procedure you recommended, performing a Backward Merge. However, after resolving the conflicts, I’ve noticed that the keys disappear again in the app cloned from Anvil collaborator. Does what I’m describing make sense to you? Is this expected behavior, or am I missing something?

I appreciate your help and patience in advance.