I am confused why the following 2 things happen:
When I push some commits to my feature_foo branch, 2 workflows (builds) are run: the primary workflow against the latest commit, and deploy workflow against my last PR, both on feature_foo. I expected only the primary workflow to be run as I haven't issued a PR yet
2 identical email notifications are sent to me from artifacts+\<my-bitrise-project-id\>#bitrise.io within the same minute. I understand that a PR can lead to two builds (as a PR is technically a push), but doubt that is the issue here as I've not created a PR yet.
Here is my current bitrise.yml trigger map:
trigger_map:
- push_branch: "*"
workflow: primary
- pull_request_source_branch: "*"
pull_request_target_branch: feature
workflow: deployment-staging
- tag: "v*.*.*"
workflow: deployment-production
By the way, this is my desired 3-workflow setup:
Run integration tests (primary workflow) on 2 occasions:
Code push to * (any branch)
Pull requests to feature branch (when the PR is created i.e. pre-merged state so contributors can preview the potential effect of their proposed changes)
Run deployment (deploy workflow) to staging when PRs from * to feature branch are merged
Run deployment (deploy workflow) to production when tags v*.*.* are pushed
What is the correct bitrise.yml config to achieve this? The docs do not indicate how we can differentiate PRs by state (issued vs merged). I want to deploy only after the code has been reviewed.
Thanks
If you open the PR will that trigger another build? Are you sure the PR isn't opened yet?
To answer
I want to deploy only after the code has been reviewed.
I guess you mean when the PR is reviewed and merged into the target branch e.g. into master.
For that you can use a config like this: https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/#dont-start-two-builds-for-pull-requests-from-the-same-repository
trigger_map:
- push_branch: master
workflow: deploy
- pull_request_target_branch: "*"
workflow: primary
This will run a build using the workflow called primary when you open the PR and every time you update the PR. Typically you want to run some automated tests in this case, in the primary workflow (unit/ui tests, linters and/or doing maybe a test build).
Then when you merge the PR (in this case into the master branch) it'll trigger a build using the deploy workflow (as technically a merge generates a commit/push event).
I hope this helps, let me know if you have any questions!
Viktor's answer is sufficient, but I wanted to add some more findings that might be relevant to someone else:
When I push some commits to my feature_foo branch, 2 workflows (builds) are run: the primary workflow against the latest commit, and deploy workflow against my last PR, both on feature_foo
I believe this happened because I had an open PR and pushed additional commits to the source branch of that PR. Based on my trigger map (shared above on the OP) at that time, it would run a deploy-staging workflow. The trigger map shared by Viktor makes more sense for my use case
2 identical email notifications are sent to me from artifacts+\#bitrise.io within the same minute
Turns out Bitrise sends both a signed and an unsigned APK (for whatever) in two separate emails
Related
If I create a feature branch that has changes to workflow, is there a way to test it before merge? I have added on pull request to workflow but it has no effect.
If you want to test a workflow implementation or workflow update on a branch, before merging it, an easy way is to use the push trigger with the branches subtype:
on:
push:
branches: [<BRANCH_NAME>]
A workflow with this implementation will trigger for every push / update to the branch you're testing (for every commit pushed after opening the pull request as well).
Then, once you have validated the workflow using this implementation, just comment or remove the trigger to use the one you wish to maintain after the merge.
I am currently setting up a CI system that will check for a passing deployment against a test environment as part of a pre-merge pull request check. This system is using Bamboo and Bitbucket, and will stop devs from merging their feature branches into the main branch if this validation fails. However, I am running into the (possibly common on my project) corner case of multiple pull requests being open at the same time, passing validation, and then being merged. In this scenario the PRs might all separately pass validation while all of them combined would break the build (I.E: PR#1 modifies a method name referenced by PR#2).
Is there a way to configure Bitbucket / Bamboo to rerun builds on pull requests if the target branch has been modified since the check last ran?
On git (bitbucket) level you could make sure to synchronize any feature or bugfix branch with an outgoing pull request by merging the latest common target branch (for example develop) immediately after a successful pull request merge to this target. This way you invalidate the 'latest' build result on feature or bugfix branches and they would be re-built because their git commit hash has changed. If any re-build of the feature branch fails, it won't be merged.
Ulrich
// Izymes - our mission is to eliminate boring from work. We build apps that turbo-charge team velocity through contextual automation.
I have an Teamcity server with a bitbucket server repository. On the Teamcity is a build pipeline which is used to validate pull requests setup. And basically it works as expected. But while new pull requests are triggered within a minute, when I commit changes on a pull request it can take up to an hour until Teamcity has the changes in the build configuration page. As soon as it does find them, it triggers the build as expected.
It also doesn't make a difference if I select the "check for pending changes" in the Actions menu.
Strangely on my other build pipline, which builds changes on the master branch new commits are triggered within the minute as well.
Pull Request Build Feature:
My branch specifications:
The "Changes checking" settings:
And the trigger:
We use TeamCity Professional 2019.2 (build 71499)
EDIT1: I just realized that there are two different views for changes: one for the branch and one for the pull request. The changes do show up in the branch for the pull request very quickly, but not in the one for the pullrequest.
Branch view:
Pull Request view:
As a reference those screenshots where made 16:32.
EDIT2: I used this article to set it up: https://www.jetbrains.com/help/teamcity/2019.2/pull-requests.html
EDIT3: I just found out that I can trigger the build with browser the pull request on the Bitbucket Server page. No idea how that works though.
It seems this is by design of Bitbucket Server:
https://community.atlassian.com/t5/Bitbucket-questions/Change-pull-request-refs-after-Commit-instead-of-after-Approval/qaq-p/194702
TLDR: The Refs on pullrequest branches are not updated immediately, due to performance consideration. The easiest way to trigger it is to view the PullRequest on the Bitbucket Server website.
Comments, and ref updates to the master will also trigger it when I understoot that correctly.
We have an app (let’s call it the main repo) on GitLab CE, that has a production build & deploy pipeline, which is only triggered when a tag is deployed. This is achieved in .gitlab-ci.yml via:
only:
- /^v.*$/
except:
- branches
We also have two other (let’s call them side) repositories (e.g. translations and utils). What I’d like to achieve is to rerun the latest (semver) tag’s pipeline of main, when either of those other side repositories’ master branches receives a push. A small detail is that one of the repositories is on GitHub, but I’d be happy to get them working on GitLab first and then work from there.
I presume I’d need to use the GitLab API to trigger the pipeline. What I’ve currently set up for the side repo on GitLab is a webhook integration for push events:
https://gitlab.com/api/v4/projects/{{ID}}/ref/master/trigger/pipeline?token={{TOKEN}}, where ID is the ID of the main project and TOKEN a deploy token for it.
However, this will only trigger a master pipeline for our main repo. How could I get this to (also) rerun the latest tag’s pipeline (or the latest tagged pipeline)?
Secondly, how would I go about triggering this on GitHub?
Either you can create new pipeline specifying ref which can be branches or tags, so in this case you need to know the exact tag value https://docs.gitlab.com/ee/api/pipelines.html#create-a-new-pipeline
Or you can retry already the executed pipeline by providing its id which you can get from https://docs.gitlab.com/ee/api/pipelines.html#list-project-pipelines by sorting by id and filtering by ref but it'll give you the last pipeline with a tag /^v.*$/ which may not match with the specific version you need.
I created a webhook in jenkins and connected it to github webhook & services.
I came upon the following issue When the build is completed, the pom.xml is updated with the version and tag . This triggers build job again and its goes into a loop until, I manually stop it .
I have set the build trigger to "Build when a change is pushed to GitHub"
I would like to find out how to stop the build trigger when the pom.xml is updated only as part of the build?
In the source code management job configuration section add Additional Behaviors and select Polling ignores commits from certain users and provide the user name your Jenkins job uses to checkin pom.xml. You can also use Polling ignores commits in certain paths and provide path to pom.xml.
I'd suggest not committing the version update to the master branch but create a separate tag every time. Something like this:
v1 v2 v3
/ / /
--A----B----C (master)
I got this approach from Real-World Strategies for Continuous Delivery with Maven and Jenkins video (corresponding slides) - it contains other tips on setting up build pipelines with Maven as well.