Changing a projects deployment from local cli to a github branch based deployment
When I did [what I described in the title] the project startup wouldn't use the existing kv instance, instead it seemed to give me a new instance. Thankfully reverting back to deployctl based deployment got me back on my old data (it's backed up to s3 as well so no worries there) but I was wondering if this was a known issue (or intended), or if there was some way for me to ensure that I can switch to github deployments without migrating data. Maybe migrating data between kv instances is easier than i realize as well and I just haven't gotten that far, either way any helpful nudges are appreciated 🙂
In case anyone is interested in reproducing this scenario:
- create deno deployment that saves some data
- deploy it manually via cli
- switch to github based deployment (minimalist options, I just created a private repo and pushed everything to the main branch and had it deploy off that)
- notice it's a fresh kv instance that does not contain the old data from the first deployctl based deployment
2 Replies
When you switch from a local CLI-based deployment to a GitHub branch-based deployment, it's important to ensure that your KV database is correctly linked to your project so that you don't end up with a new instance and lose access to your existing data.
The documentation states that for GitHub deployments, there are separate databases for production and preview deployments. When you redeploy a deployment to production using
deployctl, it will automatically configure it to use the production database by default. However, if you want to use a different database, such as the preview database or a custom database, you can specify it using the --db option.
Here's a snippet from the documentation regarding the --db option:
If you're switching to a GitHub-based deployment, you need to ensure that your project is configured to use the correct database. If you have a custom database, you can set it by UUID:
It's also mentioned that when a deployment is created, it inherits the environment variables of the project, and these variables cannot be changed for that deployment. To set new environment variables or to change the database, you need to redeploy using the appropriate options.
For GitHub Actions, you need to ensure that the GitHub integration mode is set to GitHub Actions on the Deno Deploy side. You may need to unlink first if you have an existing project that’s linked with the “Automatic” mode.
Here's a relevant excerpt:
```
On the Deno Deploy side change the GitHub integration mode to GitHub Actions.
You need to unlink first, if you have an existing project that’s linked with
the “Automatic”mode.
const kv = await Deno.openKv("https://api.deno.com/databases/<database-id>/connect");
```
This allows you to interact with your KV data outside of Deno Deploy, which could be useful for data migration tasks.
In summary, to avoid creating a new KV instance when switching to GitHub deployments, ensure that your deployment is configured to use the correct KV database. Check your GitHub Actions workflow and Deno Deploy project settings to make sure they reference the existing KV database. If you need to migrate data, you can use the command line to connect to your KV instance and perform the necessary operations. 🦕