Handling anvil.yaml in a git workflow

To follow up on a question I posted a while back on git workflow and anvil.yaml:

If you have cloned a local copy of the git repository for an app, you can tell git to ignore changes to anvil.yaml by running this command:

git update-index --skip-worktree anvil.yaml

This will then allow you to set additional remotes in that repository which point to different copies of the app at anvil.

This differs from using a .gitignore file because it only operates on your local repository and, therefore, the file doesn’t get deleted on a pull or push.

3 Likes

So, an example workflow might be:

  • Create a copy of an app using the anvil clone link (call that new copy ‘dev-app’)
  • Create a local repository for the app using the git clone command
  • run git update-index --skip-worktree anvil.yaml in that local repository
  • get the git url for the dev-app and add it as a remote in the local repository using git remote add
  • Create branches, make changes, pull and push to both remotes as desired!
2 Likes

This also allows you to collaborate with others on a free plan by using a github/gitlab/bitbucket repository as an additional remote.

2 Likes

Here is blog post Git update-index --skip-worktree, and how I used to hate config files covering the same strategy

2 Likes

@owen.campbell, @mcmasty Very useful info, thx.

How do you handle the situation when you change the schema of the data table in the DEV app? Pulling down the new version of anvil.yaml will give an error (as mentioned in https://compiledsuccessfully.dev/git-skip-worktree/)?
Currently I’d git unskip anvil.yaml, pull the file, git skip it again.
When deploying I’d git force push the app to PROD and manually fix the data table schema.

I avoid doing that because there isn’t any ability to run a migration on the hosted app. (Hence this feature request that you might want to upvote).

For changes to data table schema, I handle them manually on the prod side and only use a git workflow for the app’s code. I’d really like not to have to do this!

I half wrote up my worklfow in this gist which might be of interest.

That gist is useful. Contains a lot of git black magic :wink:

1 Like