@@ -216,12 +216,19 @@ The template processes the following steps:
1. look for a specific `deployment-$env.yml` in your project (e.g. `deployment-staging.yml` for staging environment),
2. fallbacks to default `deployment.yml`.
3. _optionally_ executes the `k8s-post-apply.sh` script in your project to perform specific environment post-initialization stuff,
4. _optionally_ executes the `k8s-readiness-check.sh` to wait & check for the application to be ready (if not found, the template assumes the application was successfully started).
:warning: `k8s-pre-apply.sh`,`k8s-post-apply.sh`or `k8s-readiness-check.sh`needs to be executable, you can add flag execution with: `git update-index --chmod=+x k8s-pre-apply.sh`
:warning: `k8s-pre-apply.sh` or `k8s-post-apply.sh` needs to be executable, you can add flag execution with: `git update-index --chmod=+x k8s-pre-apply.sh`
All scripts and Kubernetes deployment files may use [dynamic variables](#dynamic-variables).
#### readiness
After deployment (either script-based or template-based), the GitLab CI template _optionally_ executes the `k8s-readiness-check.sh` hook script to wait & check for the application to be ready (if not found, the template assumes the application was successfully started).
:warning: `k8s-readiness-check.sh` needs to be executable, you can add flag execution with: `git update-index --chmod=+x k8s-pre-apply.sh`
Your script may use [dynamic variables](#dynamic-variables).
### Cleanup jobs
The GitLab CI template for Kubernetes supports two policies for destroying an environment (actually only review environments):
