Actions Kubernetes

[ObsidianCompiler]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Misc

Discussion Details

In a GitHub Actions workflow that manages the deployment of a microservice to Kubernetes, how can you ensure that:

build and test jobs run only if the code passes quality checks (linting, unit tests, integration tests), deployment happens securely using shared secrets across multiple environments (staging and production), and rollback is triggered automatically on failure, without introducing circular dependencies between reusable workflows? 

[Paol0B]

To solve this scenario, you need a carefully designed workflow architecture:

Conditional job execution Use needs to make the deploy job dependent on the success of linting and testing jobs. Example: deploy job → needs: [lint, unit-test, integration-test]. If any fail, deploy won’t run. Add if: conditions to restrict deployment to specific branches or tags (e.g., only main or release tags). Secure secret management Store secrets in GitHub Environments (staging, production) with approval gates and fine-grained permissions. Use organization-level secrets or external vaults (HashiCorp Vault, Azure Key Vault) to avoid duplication across repos. Mask secrets in logs and scope them only to jobs that require them. Pin third-party actions to commit SHAs to avoid supply chain risks. Automatic rollback Integrate deployment steps with kubectl rollout status or Helm to monitor success. On failure, trigger kubectl rollout undo to revert to the previous version. Define rollback as a separate job that runs only on failure (if: failure()). Avoiding circular dependencies Split workflows into reusable modules: Workflow A → build & test Workflow B → deploy (called only if A succeeds) Ensure workflows are chained in one direction (A → B), never referencing each other back and forth.