Support deployments for multiple packages in a monorepo context #38092
Replies: 8 comments 5 replies
-
|
This is great documentation on using jobs. There is a flag for needs:, which can be used to set jobs that depend on each other. If the jobs don't depend on each other, you can always setup multiple actions with multiple yml files and utilize the security/secrets flow to pass the env vars. Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
|
We have this exact same problem. Would like to use Github Deployment Status APIs with a monorepo. Ideally, there would be a Right now, there is However, a blessed https://docs.github.com/en/rest/deployments/deployments?apiVersion=2022-11-28#create-a-deployment |
Beta Was this translation helpful? Give feedback.
-
|
This would also be useful if you're deploying the same component multiple times in a single environment, for example, if you build the component and then deploy it to multiple regions using a matrix job. The different regions aren't really "different environments" (prod-us-west-2 and prod-eu-west-1 are still both "production"), so it'd be nice to be able to distinguish them while maintaining a single "environment". |
Beta Was this translation helpful? Give feedback.
-
|
Dealing with this same problem. |
Beta Was this translation helpful? Give feedback.
-
|
I've been exploring using Github deployments and we also have teams using monorepos so multiple apps per repo. In my case, I'm using the |
Beta Was this translation helpful? Give feedback.
-
|
Similar issue where I'm using a matrix deployment to deploy 3-4 different cloud run jobs from the same "environment"; one of them ends up being "active" and the others "inactive". If I want to keep the deploys happening in parallel, and track the The called deploy workflow: This is called via: I guess I could make an "environment" per job, but this doesn't seem ideal. Anyone have a workaround that works for this situation? |
Beta Was this translation helpful? Give feedback.
-
|
Here is a simple workaround for those of you who just want to prevent "Inactive" status in the Deployments tab: just add a dummy job that relies on other jobs to complete, at at the end of your workflow 😛 jobs:
deploy-service1-dev:
uses: ./.github/workflows/_deploy-service1.yml
with:
env: dev
deploy-service2-dev:
uses: ./.github/workflows/_deploy-service2.yml
with:
env: dev
deploy-service3-dev:
uses: ./.github/workflows/_deploy-service3.yml
with:
env: dev
# Dummy job that executes after all other jobs have finished
deploy-complete-dev:
needs: [deploy-service1-dev, deploy-service2-dev, deploy-service3-dev]
runs-on: ubuntu-latest
environment: dev # This ensures that this job will do the final deployment to this environment
if: always()
steps:
- name: Check Deployment Status
run: |
if [ "${{ contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled') }}" = "true" ]; then
echo "One or more deployment jobs failed"
exit 1
fi
- name: Deployment Complete
run: echo "All services have been successfully deployed to dev environment" |
Beta Was this translation helpful? Give feedback.
-
|
@antonosmond here propose a nice workaround : setting the task field to the project you're deploying with a custom action like this one https://github.com/marketplace/actions/deployment-action However, it would be great to improve the deploy-foo:
environment: production/foo
deploy-bar:
environment: production/barI'm not sure if this is the intended way to use |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
-
In Github Actions there is the
environmentconfiguration at the job level, that can be used to use environment secrets and creates a Github Deployment in that environment.That's great, but it does not work well with monorepos. We have multiple components in our repo, that each have their own deployment job, that is in a component-specific workflow, and all these deploy jobs are run in parallel.
This results in "inactive" deployments, when it's actually the active deployment of a different component.
We could name our environments
component_envbut then we would not be able to share environment secrets.There appears to be a
taskargument in the Github Deployments API but it does not seem to exist in a Github Actions context, and I'm not even sure it would solve the issue?Beta Was this translation helpful? Give feedback.
All reactions