I have a multi-stage pipeline, where after successful deploy to QA environment, API tests and E2E tests are run (both of them are in separate repos).
A bug in E2E tests had made them fail, so we fixed it, merged the changes and re-run the E2E stage. The problem is that re-run runs the previous commit (before fixes). The only way we know to run latest commit of E2E tests would be to run all the pipeline again, but it'd take too much time because of long duration of previous stages.
Is there a possibility to re-run latest commit without running the whole multi-stage pipeline?
Is there a possibility to re-run latest commit without running the whole multi-stage pipeline?
Nope. A pipeline run is anchored on the commit which you selected when starting the pipeline. No matter how many times you restart it (or stages of it), it uses the same commit.
//Edit: Actually, depending on your pipeline logic, you could run a new pipeline with only selected stages:
The problem was resolved by adding git pull origin master step at the beginning.
- ${{ if ne(parameters.checkoutRepository, 'self') }}:
- script: git pull origin master
displayName: Update repository
Related
I have a ADO git repo with a YAML-based build pipeline that builds a docker image, runs some tests using Docker Compose, and then pushes the image and a helm chart to an ACR.
I'd like the have the build/test part run on PRs too. I have created a second pipeline that's just the first half of the normal build, and assigned it as a Build Validation pipeline for a branch.
However, I don't seem to be able to get the triggers right. If I have trigger: none in the test pipeline, it never triggers. If I have branch names, it is also run on merge alongside the normal build pipeline. How is this supposed to work? The docs define all the individual parts, but not really how they are expected to interact!
Am I supposed to have a multistage pipeline and use that somehow for the validation? (it's just 4 Steps in one Job in one Stage currently).
I am hoping to avoid building the same image too many times, or storing untested images anywhere outside the build agent.
I make it work with the following configuration:
In my YAML pipeline, I set the trigger: none.
In branch policies of a branch, I create a build validation with automatic trigger:
Then I create a pull request to that branch, and the pipeline runs automatically:
There are two possible mistakes:
The "Manual" trigger is selected in build validation, so that the pipeline needs to be run manually rather than triggered automatically.
The branch with branch policy set should be the same branch as the target branch of pull request.
I have a azure-pipelines.yaml Pipeline A for my .NET Application with 3 stages.
Stage 1: Restore, Build, Unit test, Publish artifact
Stage 2: Consume artifact, build Docker image, push it to Artifact
Repository
Stage 3: Perform bash script
This works fine with normal Continuous Integration-trigger, but now I would like to add PR-trigger too.
Is it possible to only perform Stage 1 (only restore, build, unit test, publish artifact) with PR then put it "on hold" until the PR is completed. And after completion, continue with Stage 2 and consume the published artifact and continue build docker image etc?
Or am I better off setting up a completely new pipeline?
Thanks for any guidance!
This is not possible. However IMHO you don't need this. All waht you need to is to run first stage on PR trigger to validate state of you code. And then when it marge to main branch, the CI trigge rpicks this up and runs all stages.
To limit first stage to just PR trigger you need to use this condition on stage level:
and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
Please add this to 2nd and 3rd stage.
I am setting a CI/CD pipeline on Azure devops.
This one gets executed when a Build for the master branch is completed.
I was asked to set the stages of the image above, which description is the next one:
Development, QA and Production : Publish the build artifacts on a server (each one).
Testing: Execute some automated test with katalon studio.
My problem is that, when I create a Development branch this pipeline cannot be executed for the build, because the pipeline is just executed when I commit to the master branch, then I create another CI/CD pipeline for Development branch, remove Development stage from Master CI/CD pipeline and incorporate it in this new pipeline.
My question is... is that correct ? , what´s the best estrategy for git branching when you have this kind of pipelines?
My problem is that, when I create a Development branch this pipeline
cannot be executed for the build, because the pipeline is just
executed when I commit to the master branch, then I create another
CI/CD pipeline for Development branch
For this issue, you don't need to do that. You only need to add the Development branch to the Branch filters of Continuous Integration in build Triggers.
Then add the Development branch to the Build branch filters of the Continuous deployment trigger.
After this setting, when you commit to development branch, build and release pipeline will also be triggered.
I have a two builds in my pipeline for different solutions within the same repository. Solution1 is triggered by commits in git, and Solution2 is triggered whenever a build of Solution1 is complete.
The problem I am having is that my initial git trigger is looking for any branch that matches the pattern of release/*. That works as intended, but the Solution2 build is just using whatever is configured as the Default branch in the "Get sources" task on the build pipeline. I have to set that default to a branch, can't use a pattern.
I initially set this up with both triggering from git with the release/* pattern, that worked but since I only have one build agent it caused issues occasionally where the release step would trigger before both builds were completed. Trying to configure this multi phase build so I can just trigger the release on the last build phase.
Is there a way to have my build on Solution2 still be triggered by build completion but use whatever branch triggered the build of Solution1?
First
Install https://marketplace.visualstudio.com/items?itemName=benjhuser.tfs-extensions-build-tasks
Then
If you switch off Solution2 triggering
Finally
Edit Solution 1 pipeline and configure the new the "Trigger Build" task at the end of the pipeline.
Then when solution1 completed it will trigger Solution2 from that task, against the same branch.
I am using TravisCI's Build Stages to separate my job to two stages:
Build and test on multiple environments.
Build and deploy if stage 1 pass.
And I want to Travis to run the jobs on commits to two GitHub branches, master and dev, and pull requests to master and dev. However, I only want to run the stage two when a commit to master happens.
Is there a way to completely ignore stage 2 in commits to branches that are not master, and on pull requests?
This is what my .travis.yml looks like at the time of writing this:
https://github.com/SammyIsra/photostream-react/blob/c354a62c3cc963b345a5c2fb95658c90ddc39d21/.travis.yml
Update:
this seems to not be possible as of yet. However, the TravisCI team may be working on something like that, as of this comment on the Build Stages feedback board. Whenever I learn that it was added as a feature, or that it will definitely not be possible ever, I will change this question.
There doesn't seem to be a way to ignore specific branches when triggering jobs in the build stages section, however it looks like there's a way to only fire your deployments on pushes to master.
In your build stage script section, you could wrap the npm run build command in a quick Bash if statement to test the environment variable which shows what branch you're on:
if [ TRAVIS_BRANCH == "master" ]; then npm run build; fi
Then, in your Surge deploy section, you can restrict the deployment to a particular branch with:
deploy:
...
on: master
And basically the same for the NPM deployment:
deploy:
...
on:
branch: master
Note: I've not tried any of this myself, so it may or may not work in combination with the new build stages functionality.