Open huntercaron opened 1 month ago
As for why I am using both, Github deploys feel much slower, and when having to hot-fix something you want to be able to get the fix out before spending the time to ensure your git history is in good shape
I ran into this yesterday. It was a BIG problem for me when I went to do a deploy using deployctl deploy --prod
and all of a sudden my prod domain showed all preview data.
I had to push a build via Github in order to get my domain to show the main (non-preview) data again.
With Deno Deploy, calling
kv.set()
/kv.get()
from production uses "preview" KV database, rather than the main database as expected. This only happens on production deploys made withdeployctl --prod
, if Github integration is also active.Reproduction Steps
kv.set(["key", "id"], data)
on that production deployment will store to preview databaseAdditional Info
deployctl --prod
and switched to github deploymentsReproduction To test this, I created a new minimal setup that stores into the KV. It stores a random number for a given slug, and is enough to reproduce the above
When running this code on a Deno Deploy project that has the Github integration set up and has its latest prod deploy created via the
deployctl
tool, it will store into the preview database. You can verify in the dashboard. Side note: without a preview branch, I wouldn't even expect this database to exist.Version: Deno Deploy / Deno 1.45.1