Details
I handle infrastructure code (Terraform) in a mono-repo, which necessitates the deployment of numerous projects across various environments from a single repository.
I managed to implement a separate branch-deployment gate for each project using distinct triggers:
trigger:
if: |
github.event.issue.pull_request
runs-on: ubuntu-latest
steps:
- name: Gate branch deployment
id: branch-deploy
uses: github/[email protected]
with:
trigger: .deploy ${{ inputs.project_name }}
noop_trigger: planThe above configuration produces the following IssueOps interface:
.deploy foo dev/staging/prod
.deploy foo plan dev/staging/prod
.deploy bar dev/staging/prod
.deploy bar plan dev/staging/prod
However, given multiple projects, specified environments, i.e., dev/staging/prod, are "shared" (from the branch-deploy action's perspective), which implies that whenever I deploy to project foo, corresponding Github environments are being locked and altered with deployment status, preventing me against deploying to the boo project from other pull requests.
Consequently, in a mono-repo setup, one must distinguish Github environments by project, e.g., using a prefix: foo-dev vs. bar-dev, foo-prod vs. bar-prod, etc.
That is possible to implement by a combination of environment and environment_targets input variables:
environment: foo-dev
environment_targets: foo-dev,foo-staging,foo-prod
However, with the current design of the branch-deploy action, the IssueOps interface would look like this:
.deploy foo foo-dev
.deploy bar bar-dev
... which seems inconvenient and unreadable as one has to repeat the project name twice.
I wonder if we could introduce an additional parameter, e.g., environment_prefix, that would alter the behavior of the branch-deploy action internally so that the action, given an environment dev (from issue comment), prefixes it internally with environment_prefix and only the prefixed Github environment is used for further processing. In other words, it would be great to somehow separate input environments from Github environments.
environment: dev
environment_targets: dev,staging,prod
environment_prefix: foo
That would be a significant enabler towards adopting the action into existing mono-repo configurations.
Details
I handle infrastructure code (Terraform) in a mono-repo, which necessitates the deployment of numerous projects across various environments from a single repository.
I managed to implement a separate branch-deployment gate for each project using distinct triggers:
The above configuration produces the following IssueOps interface:
However, given multiple projects, specified environments, i.e.,
dev/staging/prod, are "shared" (from thebranch-deployaction's perspective), which implies that whenever I deploy to projectfoo, corresponding Github environments are being locked and altered with deployment status, preventing me against deploying to thebooproject from other pull requests.Consequently, in a mono-repo setup, one must distinguish Github environments by project, e.g., using a prefix:
foo-devvs.bar-dev,foo-prodvs.bar-prod, etc.That is possible to implement by a combination of
environmentandenvironment_targetsinput variables:However, with the current design of the
branch-deployaction, the IssueOps interface would look like this:... which seems inconvenient and unreadable as one has to repeat the project name twice.
I wonder if we could introduce an additional parameter, e.g.,
environment_prefix, that would alter the behavior of thebranch-deployaction internally so that the action, given an environmentdev(from issue comment), prefixes it internally withenvironment_prefixand only the prefixed Github environment is used for further processing. In other words, it would be great to somehow separate input environments from Github environments.That would be a significant enabler towards adopting the action into existing mono-repo configurations.