More flexible types of jobs tied to environments
Problem to solve
We currently equate a job that declares an environment as a deployment, but now that we have environment-specific variables, there are cases where I want to do other non-deployment jobs and still need those variables. e.g. helm status to check in on the status of the deployment after the fact. Especially for chatops jobs. Today, this is impossible without the undesirable side effect of creating a deployment record for these manual job runs.
Further details
When using Kubernetes clusters that are tied to environments, the cluster credentials will only be exposed for deployment jobs.
We should provide for multiple types of jobs, other than deployments, that are tied to an environment, so they get access to the environment-specific variables. Perhaps we add a new keyword to jobs to declare that it's a deployment. We currently infer that it's a deployment because it mentions the environment (and that it's not a stop job). Decoupling deployment from environment could also allow users to declare other jobs as deployment, even if they don't want it recorded in our deployment history. This has marginal value by itself, but in other issues where we've discussed auto-canceling redundant jobs, it's important not to stop a deployment job otherwise you could leave production in a broken state. But today we can't really trust that everyone is using environment declarations to indicate deployments. The explicit deployment indicator could be used in this case.
For now, all we need is to indicate deployment, stop, and other. But perhaps other explicit types would be valuable. One possibility is to merge this with declaring a job as a chatops job. Are there other types of jobs we need to declare?
Proposal
What does success look like, and how can we measure that?
(If no way to measure success, link to an issue that will implement a way to measure this)