A shell script puts commands you would otherwise type in a terminal into a file you can run again. It is useful for repeated development commands and for deployment steps that must work both locally and in an automated workflow. section 4.3.5 section 8.9.3
A minimal script contains one command: echo "Hello world!". Run the file with ./index.sh to check that it works. section 8.7.5
Before running a new script as ./index.sh, mark it executable with chmod +x ./index.sh. If it will run from a Git repository, commit and push the executable-file change. On Windows, run these shell scripts from a WSL2 Linux terminal rather than the regular Windows terminal. section 8.7.5
Wrap related commands as the task grows:
- For daily development, up.sh can run docker compose up --build; down.sh can run docker compose down --volumes. A reboot script can chain the down and up commands. section 4.3.5
- For deployment, separate scripts can build a Docker image, log in to a container registry and push the image, then apply Kubernetes configuration. section 8.9.3
- Use environment variables for values such as the registry, image version and registry credentials. Set the required values before testing the scripts locally. section 8.9.3
The deployment script uses envsubst to fill environment-variable values into a Kubernetes YAML file, then pipes the result to kubectl apply. section 8.9.3
Get the manual deployment working locally before putting its scripts into GitHub Actions. Local runs make command failures easier to diagnose and let you retest deployment changes. An automated workflow can then invoke the same scripts; it does not need to hold every command inline. section 8.9.3 section 8.5
A script is not mandatory for a tiny workflow: GitHub Actions can run one command or several commands directly in its YAML file. Keeping substantial deployment commands in scripts is more valuable when they need separate local testing. section 8.7.7 section 8.9.3
