3 days ago
We’ve encountered a critical issue in our CI/CD pipeline where calling the GraphQL variableUpsert mutation to update environment variables triggers an automatic deployment of our environment.
Historically, this wasn’t the case. We’ve been using variableUpsert in production for several months, and only recently started seeing duplicate deployments—one triggered by GitHub Actions (expected), and a second, unwanted one triggered by the variable update via your GraphQL API.
Problem:
When we update environment variables during preview environment setup, an unexpected deployment is now automatically triggered causing our CI/CD to fail.
We update atleast 1-5 variables on deployment (github-actions). We do it like this
mutation variableUpsert {
variableUpsert(
input: {
projectId: "${projectId}"
environmentId: "${environmentId}"
serviceId: "${serviceId}"
name: "${key}"
value: "${value}"
}
)
}and that occurs per variable updates so if we update 5 variables, there will be also 5 unwanted deployments.
Our ask:
Is there any work around with that?
Any official documentation that we can read about this?
We’d prefer to avoid using the CLI in CI if possible, but if there’s an officially supported way to update variables without triggering a redeploy, we’d love to implement it.
0 Replies
3 days ago
I think you are looking for variableCollectionUpsert
qq, does variableCollectionUpsert prevents automatic deploy upon variable updates?
@Brody qq, does variableCollectionUpsert prevents automatic deploy upon variable updates?
3 days ago
Since it will only be one mutation for setting multiple variables, it would only be one deploy.
am sorry im still confused, i understand the part that im doing the update per variable so that's why im having multiple deploys.
but if i do the variableCollectionUpsert it'll still do the automatic deployment when the variable updates? or no?
because if yes, then our problem still occurs.
1. dev commit
2. github action
2.1 github action executing our script for updating variables (triggers deployment)
3. deploymentif we use the variableCollectionUpsert in our script for updating variables and it still do the automatic deploy then we will still have 2 deployment at the end.
3 days ago
That is correct, at least one new deployment is non-negotiable here, since a deployment is needed so the application can see the new variables.
Setting variables without deploying is a bit pointless, since the already running deployment will never be able to read them.
I see, so there's nothing we can do or add to prevent to deploys it? because i saw this as i was browsing for any solutions -> https://community.doppler.com/t/railway-integration-spams-deploys-on-sync/1881/2
it mentions "Railway also added an additional skipDeploys option to their variable upsert API operations that allowed us to disable this behavior"
3 days ago
You can use skipDeploys, but then the running deployment would never see the new variables. I can't imagine you are operating in a scenario where you are okay with setting variables but not using them?
so you are saying the variables aren't really updated if they are not deployed?
then you guys changed how updating variable works? because previously i think the variable is updated but was not deployed (need manually). I thought the manual to automatic deploy was the only change? did i misunderstood that?
3 days ago
so you are saying the variables aren't really updated if they are not deployed?
Correct, we do not support updating the environment variables of live deployments, nor have we ever. A new deployment is needed to use the newly set variables.
3 days ago
Or, put another way, a deployment will use the variables available at the time of deployment, and there is no way to add or change the variables a live deployment uses without creating a new deployment to use the newly added variables.
yup, i know this part.
so let's put it this way;
theoretically let's say I use the skipDeploys upon updating the variables and then at the final of our CI (GITHUB-ACTION) it deploys it, would that deployment catch the updates I did?
I think you are assuming that we are not going to deploy it once we update it. we do, we just dont want it to deploy immediately right after, we added the setting variable in the middle so we can have those api keys from supabase and then at the end of our CI (GITHUB-ACTION) it will finally deploy it.
im trying also to understand skipDeploys purpose here, because it seems to me if the variables aren't really updated, then skipDeploys is useless right?
im sorry, pls bear with me, i just want to fully understand this thing. thanks for your patience @Brody
3 days ago
Thank you for the extra context. If you have something at the end of your CI that is going to kick off another deploy, then the added variables with skipped deploys will be used in the final deployment, since a new deployment will use whatever variables are set in the service variables.
I wasn't aware that you had a final step that would kick off a final deployment.
that's wonderful! thanks @Brody , i guess i should've explained it better or mentioned the last part of our CI deploys it.
and we are going to use the variableCollectionUpsert it's much better for updating multiple variables i guess, thanks for the suggestion!
and also do guys have an official documentation for the skipDeploys?
do i just add it together with the query like this? like another param
{
query: mutation // contains the graphsql mutation query
skipDeploys: true,
}3 days ago
We don't really have extensive written documentation since GraphQL is kind of self-documenting, and for that, there is our GraphQL playground.
(3rd button down on the left menu bar)
3 days ago
No problem!
2 days ago
!s
Status changed to Solved brody • 2 days ago