GitHub creates a new ref when a pull request is created. The ref points to a merge commit, which is the merged code between the source and target branches of the pull request. The PR validation pipeline builds the commit this ref points to. (from here)
This causes a problem for my pipeline with Chromatic: these commits are problematic for a bunch of reasons. The biggest one is as they don't exist in the git history, we lose track of baseline acceptances you do on them.
Is there a way to configure GitHub and/or Azure DevOps build pipeline to trigger build for PR but for normal linear commit in PR branch, not merge of it with target branch?
Is there a way to configure GitHub and/or Azure DevOps build pipeline to trigger build for PR but for normal linear commit in PR branch, not merge of it with target branch?
I am afraid there is no such way to trigger build for PR but for normal linear commit in PR branch.
Just like what you pointed, PR validation pipeline is used to build the merged code between the source and target branches.
If you do not want to build the code merge of it with target branch, you can just set the build pipeline with CI trigger enable for the source branch instead of the PR build for the PR validation pipeline.
Related
My use case is this, I want to 'protect' main by denying all PRs that come from branches other than 'dev'. I am trying to build this functionality into a yaml file in GitHub actions. I tried to use the GitHub context ${{github.ref}} to isolate the source branch of the PR. While the value provided works for merge requests, github.ref on PRs stores an entirely different value (the PR number, instead of the branch name).
Is there a way to isolate the source branch of a PR, in a yaml script? The goal is to have my script check the source branch, and error if the source branch is not 'dev'.
I am currently building an Azure DevOps CI/CD pipeline and if it fails, I don't want to keep the code that lead to the fail in my repository. So, if the pipeline fails, I want the repo to be reverted to the last version before that commit. I can't find any help on that. How does this option look like and how can I add this option to my .yaml file?
Thank you so much.
Normally, you can use the git revert command to revert some existing commits.
In your pipeline, you can check out the git repository and the branch where you made the changes. Then run the git revert command to 'undo' some commits.
For more details, you can reference the following articles:
Git - git-revert Documentation
Git Revert
However, as #GeralexGR has suggested, it is recommended that you'd better create a develop branch based on the default branch (main/master) and make changes on this branch. Then build and test the code on the develop branch. Once everything is good on the develop branch, you can create a Pull Request to merge the changes from the develop branch to the default branch.
I have a Release pipeline (Classic version) with artifact set to a Azure Git repo. The default branch is set to master branch. Every time someone creates a new release, latest version of master branch is copied to the Dev Ops agent and release tasks will run.
Is it possible to allow specification of branch at release creation time?
If I don't misunderstand, you would like to trigger release pipeline with specific branches.
You could try to add Branch filters.
A release will be triggered only if the Git push contains a commit on
the specified branch. For example, selecting "master" will trigger a
release for a Git push which contains one or more commits to the
master branch. To trigger a release for any commit to branches under
features/, enter "features/". To trigger a release for commits to all
branches, enter "". Note that all specified filters will be OR'ed.
For example, an artifact matching at least one filter condition would
be sufficient to trigger a release.
If you mean triggerring stages with specific branches, Artifact filters can do.
For more information, please refer to this document.
I am trying to do the following:
A developer (e.g.: James) could be working on this private branch (e.g.: james/add-custom-logger) for a while before sending out a PR.
Once James sends out a PR, I would like to automatically trigger a build for that PR branch.
I am struggling to figure out how to do this in VSTS builds.
I know that I could setup build triggers based on branches like feature/* and could ask all developers to follow that pattern, so in this case it would be feature/james/add-custom-logger.
But I don't want to trigger those branches until a pull request is sent for those branches.
Any ideas on how to achieve this?
Maybe branch policies fit your scenario. If james always creates the PR to the same branch - for example 'master' - you can create a branch policy for 'master'. Go to Repos > Branches > ... (More Actions) > Branch policies > Build validation > Add build policy
https://learn.microsoft.com/en-us/vsts/repos/git/branch-policies?view=vsts#build-validation
https://learn.microsoft.com/en-us/vsts/pipelines/build/ci-build-git?view=vsts&tabs=yaml#validate-pull-requests
To put it in "BDD" terms:
Background:
Given I'm contributing to a GH repo
When I create a pull request
Then Travis should build the latest commit
When I push to an existing pull request
Then Travis should build the latest commit
When I merge a pull request to master
Then Travis should build master
I was confused by Travis-CI's "build pushes" and "build PRs" settings, as:
Enabling both causes each Pull Request to be build twice by Travis
once for the commit on that branch
and once again for the merge commit of that branch into its destination
Enabling just "build PRs" causes PRs to be built, but doesn't result in post-merge builds (i.e. on master).
Enabling "pushes" brute-force satisfies the above criteria by building all pushes to the repo. You can try to finagle things by white- & black-listing branches, but that will probably bite you unless you're rigorously disciplined with branch names.
This is explained more in Travis-CI docs and GH issue #3241.
Anyone know a configuration that satisfies the above criteria?
I eventually found another GH issue (#2111) which gave me the idea to try enabling both PRs & pushes, but with a whitelist to restrict pushes to a specific branch. This seems to satisfy the criteria for my workflow. Here's what I did:
Enable both PRs & branch pushes in the Travis settings for the repo:
Change .travis.yml to white-list master branch (i.e. only build pushes to master):
branches:
only:
- master
Test it by creating a PR with the .travis.yml change, and another PR with some empty commits to verify it works for forks too.
Verify successful merge commit build from master.
Just found in travis docs
Add to .travis.yml
if: type = push
alternatively:
if: type = pull_request
Assuming you want to build all PRs, something like the following will do the trick. Enable both branch and PR builds on the settings page, and put this line as the first line in your travis.yml:
if: (type = push AND branch IN (master, dev)) OR (type = pull_request AND NOT branch =~ /no-ci/)
This will attempt a push build on all pushes and a PR build on all pushes to an open PR, but will filter out any that don't meet the condition. You might need to modify this a bit - the clause about not building branches with no-ci somewhere in their name is obviously optional, and you may not have two branches that you always want to run builds on.
You can read more on conditions and conditional builds on Travis's site.
The whitelist approach described in the accepted answer has some significant limitations. In particular, it doesn't support non-redundantly building arbitrary branches without opening a PR.
I opened an issue asking for a better solution.
You can use next workflow if you want to test not only master branch but some others branches too:
Keep both "Build pushes" and "Build pull requests" ON
Add branches:except directive to your .travis.yml:
branches:
except:
- /^pr\..*/
In this configuration:
any commit to branch feature-A will trigger the build
any commit to branch pr.feature-A will not trigger the build
if branch pr.feature-A is used in opened pull request then build will be triggered
Workflow example
temporary WIP branch shared between several developers: wip.feature-A, any commit to this branch will trigger the build
when branch is ready to be merged to master you can rename it from wip.feature-A to pr.feature-A and open pull request
if while reviewing pull request you want to apply new fixes, just push to pr.feature-A
On all the steps above only one build will be triggered.
For one of the repositories, I was working with, here is what I wanted:
There is an origin repo which is the main repo which does all the releases.
I wanted that all the pull requests coming to master branch of origin should be built with Travis only once irrespective of the fact that it comes from a forked repo or any other branch of the origin itself.
For this case, this works like a charm
if: (type == push) OR (type == pull_request AND fork == true)