You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But that's the nuclear option, because -- if I understand it properly -- it's going to be injected as a build arg AND it'll be popped into the env vars for the containers (requiring a restarting all pods).
But what about if I only want to use the git sha as a build variable? I have a client that uses it to configure settings for some application integrations, and this lets the track what data comes from what version of their code they've deployed.
This means something like LAGOON_BUILD_NAME isn't going to work for them, since it's not explicitly tied to a version of the code deployed, just to the deployment (i.e. multiple deployments of the same exact code result in different LAGOON_BUILD_NAMEs)
Could we, perhaps, change the behaviour of this to allow the user to select the scope of the GIT_SHA?
Here https://docs.lagoon.sh/using-lagoon-the-basics/lagoon-yml/#environment_variablesgit_sha we say that if it's true it gets injected, but we could change that to also, say, take a scope (so, true/build/runtime/both).
This should be trivial to implement.
I'm keen to hear any ideas that let us achieve something similar - although this change to the GIT_SHA behaviour seems to be only a small tweak, that also brings it in line with how with think about env vars generally.
The text was updated successfully, but these errors were encountered:
I have some questions regarding the GIT_SHA environment variable.
Currently, we're going this, right
build-deploy-tool/legacy/build-deploy.sh
Line 47 in 38694d1
But that's the nuclear option, because -- if I understand it properly -- it's going to be injected as a build arg AND it'll be popped into the env vars for the containers (requiring a restarting all pods).
But what about if I only want to use the git sha as a build variable? I have a client that uses it to configure settings for some application integrations, and this lets the track what data comes from what version of their code they've deployed.
This means something like LAGOON_BUILD_NAME isn't going to work for them, since it's not explicitly tied to a version of the code deployed, just to the deployment (i.e. multiple deployments of the same exact code result in different LAGOON_BUILD_NAMEs)
Could we, perhaps, change the behaviour of this to allow the user to select the scope of the GIT_SHA?
Here https://docs.lagoon.sh/using-lagoon-the-basics/lagoon-yml/#environment_variablesgit_sha we say that if it's
true
it gets injected, but we could change that to also, say, take a scope (so, true/build/runtime/both).This should be trivial to implement.
I'm keen to hear any ideas that let us achieve something similar - although this change to the GIT_SHA behaviour seems to be only a small tweak, that also brings it in line with how with think about env vars generally.
The text was updated successfully, but these errors were encountered: