We are managing to change our CI/CD process on github. Previously we were using one branch by environment (Test and Production).
Now, we would like to have the same build deployed on all environment. So we are using one main branch which build and allow to deploy on Test environement and if it succeed and approved to prodution.
So far so good.
Most of the time, we are deploying in Test environment only. For this cases, we are rejecting or cancelling the workflow after deploying to Test but our actions and Pull request are all in failled state.
The question is, how could we manually skipped the production deployment without having the status of Github action being failed.
Thanks in advance
Related
We have Vercel preview deployments setup for every pull request in Github.
On every pull request the code gets deployed to a Vercel test / acc / prod environment which are coupled to different backends.
For every pull request we want to run some (Cypress) tests against it, but only against the Vercel test environment.
We have this working by using the deployment_status event and specifying it should only run when the environment is test.
jobs:
cypress:
if: github.event.deployment_status.environment == 'Preview – Test'
This will result in a skipped Github run for acc / prod and a pass/fail for the test environment.
However Github only lists the last run in the PR Github checks, this can be either the skipped or the pass/fail run and is depending on which preview environment gets deployed last.
Is there a way to enforce that Github only lists the relevant run?
I tried making that run dynamic and making the test one mandatory but the check still get's overridden if test was not the last deployed Vercel environment.
Reusing same environment rule within same workflow
Running our workflow in Github, we split our tasks up into 2 jobs; Building docker image & attach tags and deploying to AWS using CodeDeploy. The reason for splitting the tasks up is to avoid creating new tags whenever our deployment fails.
However... using environment protection rules creates a roadblock as every job needs to be approved(even though we already ran the same environment previously)
The deployment job is a conditional job, meaning it depends on the success of the Build job.
Is there any way to get around this?
Github workflow
I'm working on a project where we have a front end application. This application has a second entry point I've added for our login application. So I've started setting up a new pipeline for building it. Upon a successful build & push of the login-app artifact I want the login server to also trigger a build. The backend .net app for the login server will serve the built angular app from its public folder, so hence the reason to trigger the pipeline.
In each of the repos we have three branches that we deploy from: qa, uat, and prod. So when a qa build runs for the frontend, I want the qa branch of the login server to run. Same with uat -> uat and prod -> prod. Based on the information here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers?view=azure-devops#branch-considerations it doesn't sound like I can use the pipeline triggers for this. Is there another approach we could take?
If you don't use pipeline completion triggers in yaml, you could consider to use build completion trigger(Classic).
In the other hand, you could install external free extenion: Trigger Build Task or Trigger Azure DevOps Pipeline, so there will be additional available task to trigger a new build when this build is done.
Of course, you could directly use Rest API: Builds - Queue to queue a build.
We have a web application in an Azure DevOps repo and there's a branch policy on the master branch that kicks off a build when a pull request is created. This validates that it compiles and performs code quality checks and the like.
We also have some integration tests (using Mocha and Selenium) that live in another repo. I would like to run the integration tests when a PR against master is created.
As far as I know I cannot have the same build pull from two different repos (without using extensions and it seems cleaner to me to have two separe builds anyway). So I thought I would have another build just to run the integration tests. The build that pulls from the webapp repo would have a final step where it would deploy to an integration tests environment and then the second build would get the latest version of the integration tests and run them against the integration tests environment. I created a Build Completion trigger on the integration tests build that is triggered by the completion of the webapp build.
The problem is that when I queue the webapp build manually, it will launch the integration tests build when done. But when the webapp build is queued by an incoming PR, the integration tests build does not get triggered.
Is this a bug in Azure DevOps or am I going about this wrong?
Also in my side builds from PR doesn't trigger another builds (with Build Completion trigger), I don't know if it's a bug or it's by design.
Anyway, there is a workaround - the final step in the first build will trigger the second build. how? with Trigger Build task.
You just need to change the branch because it will be a merge branch from the PR that doesn't exist in the tests repository:
You can also do it without install extensions with PowerShell task and the Rest API.
We are using Github + CircleCI + Heroku with automatic deploys setup.
From time to time there are deploy errors that are not captured by CI (deployment fails event though CI run is fine). We have review apps set up for all our PRs.
It would be great if the PR would indicate this and stop us from merging if the deployment of the review app fails (that usually means the deployment of the staging/production app would also fail).
I could not find any documentation on this. The only possible way I see is to use the GitHub API to add a custom check for this.
Anyone solved this issue?
We have made a GitHub Action to test the deployment status of a Heroku Review App: https://github.com/marketplace/actions/heroku-review-app-deployment-status.
This can be used in the GitHub workflow to test the deployment status.
UPDATE: We wrote a nice blog post about different approaches to verify Review App deployment status.
Link: https://blog.niteo.co/staging-like-its-2020/
You can use Github's protected branches for this https://help.github.com/en/articles/enabling-required-status-checks
Navigate to your repository's settings -> Branches -> Add Protection Rule -> Select "Require Status Checks Before Merging" and select "CircleCI".
In order for this to work you need to cause CI to fail if your deployment fails. If you get a failure from Heroku, you should run any command that will return exit 1 as a status code, which will fail CI for you.