Set a sensible default for NIGHTWATCH_DEPLOY.#293
Conversation
jessarcher
force-pushed
the
deploy-config-default
branch
from
2e089ba to
5a8cc67
Compare
jessarcher
force-pushed
the
deploy-config-default
branch
from
5a8cc67 to
82f3586
Compare
| 'enabled' => env('NIGHTWATCH_ENABLED', true), | ||
| 'token' => env('NIGHTWATCH_TOKEN'), | ||
| 'deployment' => env('NIGHTWATCH_DEPLOY'), | ||
| 'deployment' => env('NIGHTWATCH_DEPLOY', rescue(static fn () => trim((string) shell_exec('git describe --tags --always 2>/dev/null')), '', false)), |
There was a problem hiding this comment.
We should look at environment variables in the first instance and only fallback to exec if there is nothing else.
- Forge:
FORGE_DEPLOY_COMMIT - Vapor?
- Cloud?
- Any other common environment variable used 3rd-party platforms? We've usually opted not to support these, but I wonder if we should.
GITHUB_SHA, for example.
If you don't have config cached, we will run this on every request. Do we care about that? I'm sure there are plenty of apps out there that don't cache config, routes, etc.
There was a problem hiding this comment.
I believe Vapor's is VAPOR_COMMIT_HASH
There was a problem hiding this comment.
I think the shell_exec within config files is not a good idea, especially as a default. Mostly for the caching notes from Tim, but I've also worked places that remove git on deploy. I think it might be a good thing to document about the deployments feature for users to add themselves.
Otherwise, I think some env vars to fall through would be the best thing here.
What makes sense to me, in order:
NIGHTWATCH_DEPLOY- allow a NW specific value that can be set by usersLARAVEL_CLOUD_COMMIT- cloud as the new default go-to for deploymentsFORGE_DEPLOY_COMMIT- as the second option for deploymentsVAPOR_COMMIT_HASH- possibly not even add this one as its semi deprecated isn't it?
I've verified all these env vars against each product as well. See linear for other relevant env vars.
The problem with our first party SaaS is tags do not show up in any for us to reference, its all off commits. Perhaps for a better experience between them all, that is a good idea to stay with commit SHA.
I also haven't, yet, tested if those vars are available after the deploy in the running code (when not caching config).
3 participants
This PR sets a sensible default for the
NIGHTWATCH_DEPLOYconfiguration option.It will attempt to get a human-friendly tag from git, and will fall back to getting a short hash.
Examples:
v1.15.2- Exact tag matchv1.15.2-1-g2451327- Changes have been committed since last tag2fd2adb- No tag availableIf
gitorshell_execis not available, it will safely fall back to an empty string.There is a performance implication from running these commands, but this is solved by config caching which should always be performed on production systems.