An environment variable is a named value supplied when a program runs. It lets the same microservice start with different settings without editing its code. A Node.js HTTP service can read `process.env.PORT` to choose its listening port. section 2.6.6
Set a port before starting the service
Set `PORT=3000` in the terminal, then run `node src/index.js`. Use `export PORT=3000` in a Unix-style shell or `set PORT=3000` in Windows Command Prompt. If `PORT` is missing, the service throws an error naming the required variable instead of starting with an unintended configuration. section 2.6.6
A service may need several values before it can start. A metadata service, for example, requires `PORT` for its web server, `DBHOST` and `DBNAME` for MongoDB, and `RABBIT` for RabbitMQ. Set the required values before running `npm start` or the development script `npm run start:dev`. section 10.5.1
env:
VERSION: ${{ github.sha }} #1
CONTAINER_REGISTRY: ${{ secrets.CONTAINER_REGISTRY }} #2
REGISTRY_UN: ${{ secrets.REGISTRY_UN }} #3
REGISTRY_PW: ${{ secrets.REGISTRY_PW }} #3
The workflow `env` mapping shows two sources for values passed to deployment scripts: `github.sha` supplies `VERSION`, while GitHub secrets supply registry settings and credentials. section 8.9.7 section 8.9.8
Keep sensitive deployment values in GitHub secrets rather than hardcoding them in workflow YAML or shell scripts. This also makes the deployment code easier to reuse. In a production deployment, `CONTAINER_REGISTRY` supplies a registry address to the shell script; `envsubst` inserts it into templated Kubernetes configuration before `kubectl` applies that configuration. section 8.9.7 section 10.9.2
When a deployment fails, check the GitHub Actions workflow history and read its error messages. Verify that every required variable is set, then compare local and production values if the process works locally but fails after deployment. Testing the deployment process locally can shorten this investigation. section 8.9.10
