I'm working on a solution that has a yaml build pipeline that does the following
>restore
>build
>test
>publish test
>publish test coverage
>publish source code
And I want to implement a policy in a branch that does the following: whenever a developer creates a pull request to develop branch, that action triggers a build to ensure that the code the developer is trying to merge to develop builds and passes all tests
My question is: as a best practice, should I reuse the build pipeline that I already have, or should I create a new pipeline for that specific job?
Hi Rodrigo you can use the same pipeline as long as you don't have some specific requirements. You can make use of conditions or stages in pipeline yaml to make it robust reuse.
for more information
https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=schema%2Cparameter-schema
Related
For my team where we have partner teams providing us SW pieces that need to be integrated on HW systems and tested together, our code footprint is small and hence churn is small, while number of changes from partner teams is frequent. In such a scenario, I see the need to trigger the release part of the yaml many more times than the build part. Is multi-stage pipelines the way to go? I want to trigger new release instances using RestAPI invoke only the Release stages on the YAML file, using AzureDevOps Rest API.
Regards,
You don't have to use multi-stage pipelines to be able to trigger repeated releases, it just makes the management of the pipeline cleaner.
It's possible to create a pipeline that include a build stage and release stages for each of your environments, trigger the build stage (manually or based on a CI trigger), and then from that Pipeline "Run", deploy as many times as you see fit to whatever environments you like. That can be done from API or portal.
It's also possible to create a pipeline that is "release-only" - that is, it gets created manually, or as the result of seeing a specified build having been run.
Personally, I like the multi-stage build because it's a little easier to see what build created the release that you're deploying around. It's not a requirement, though.
I have a project that runs a pipeline with a few jobs/stages in it. I have the project set up to create merge requests when I push to another branch. Those jobs kick off after the merge request is published. Is there any way to start the pipeline before the merge request is published?
EDIT
Here is what I ended up adding based on the accepted answer.
workflow:
rules:
- when: always
If you want to use the basic configuration, I'd probably take a look at workflow:rules in Gitlab's pipeline configuration reference:
The top-level workflow: keyword determines whether or not a pipeline is created. It accepts a single rules: keyword that is similar to rules: defined in jobs. Use it to define what can trigger a new pipeline.
Here you could use the merge_request_event-rule:
For pipelines created when a merge request is created or updated. Required to enable merge request pipelines, merged results pipelines, and merge trains.
Gitlab also offers Pipelines for merge requests, which could be a better fit for your specific use-case. Keep in mind that not every user can trigger a pipeline if the relevant branch is protected.
I am using Azure DevOps and I have a single build pipeline with a number of steps including PublishBuildArtifacts defined in the azure-pipelines.yml file.
I have pointed the same pipeline for the Build Validation (Validate code by pre-merging and building pull request changes.) from the master branch's build policies option. However, for this PR build run, I don't to run certain tasks like PublishBuildArtifacts.
How can I achieve this? I can think of one way which is to create a separate pipeline for PR and also a separate azure-pipelines-pr.yml file and not adding those tasks in that file. But this feels like an approach with redundancy to me. Is there any better way to achieve this?
You can add a custom condition for the publish artifacts step:
and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))
Now the step will run only when the build reason is not pull request.
Is any possibility to test created Azure Pipelines? From UI or your yaml definition of pipelines?
Mean that I have some yamls pipelines or pipelines defined from UI and I want to ensure by some tests(Unit Tests e.x.) that all have defined variables, build, test, and package parts or something else in each pipeline.
And verify pipelines configurations after some changes of them or after adding some new repos/branches if it's required.
Thanks...
Is any possibility to test created Azure Pipelines? From UI or your
yaml definition of pipelines?
If you want a out of box feature to achieve this, sorry to say, No, there hasn't.
BUT, the work around is using API to check them.
Client API.
You could write a simple script to get Builds definition with Client API.
In this simple script, you first get the whole definition:
List<BuildDefinitionReference> buildDefinitions = new List<BuildDefinitionReference>();
Then you could apply your customized check/test into this definition with scripts. In one word, write some test classes/methods. After the script complete, you can import it into VSTS, and then use task to run those tests part. Only this test succeed, then your builds could be executed.
So, at this time, it need you add 2 agent jobs into your pipeline, the first one is used to run your script test(names test agent job). And the second agent job is the one you want to check. In the second agent job, set its condition as:
At this time, only the test succeed, this current job can be ran.
Or, if you don't want the builds you want to check would be broken because of the test, please consider about using Build completion trigger. Set a separate pipeline to run the test. In the pipeline you want to check, set it can be run only when the test pipeline finished.
Rest API
You could use rest api with powershell which very similar with the above description. Use api to get builds definition, and then write some check powershell script.
I more recommend you to put the test at a separate pipeline. Then the API could only get the part you want check, not including the test part.
I'm trying to setup Azure Pipelines for a CI setup and I'm using the YAML syntax to get started. However, I was wondering if it is possible to script the flow at "runtime"? Like you can do in Jenkins script: spawn builds etc.
Depending on the commit I want to have a vastly different flow.
This is because I currently have a mono-repo setup with Conan libraries and I want to rebuild the libraries that are necessary depending on the commit, thus the build-flow is not the same for each commit. I want to spawn jobs so I can take advantage of parallel building on several agents.
For your issue ,do you refer to trigger builds based on specified commits? If so, you can trigger builds by adding tag trigger in yaml. You can create tags on the commits. If the tag created meets the trigger condition of the tag trigger in yaml , then the build will be triggered.
trigger:
tags:
include:
- v2.*