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.
Related
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 defined a clean-up stage in Gitlab CI scipt that is used to automatically shut down the instance after the branch's testing, and I would like to have this stage being automatically triggered once I merged this branch into the master through the merge request in Gitlab, how should I implement this?
If the merge goes into develop you could use
cleanup:
stage: cleanup
only:
- develop
That way it'd be trigger by the merge rather than the merge request.
Anyhow, I'd say that what you aim to do should be done directly in the same pipeline and not wait until it is merged though
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
We have 3 main branches: development, releases/xyz and master. This mirrors the flow from development through release candidates to production.
I want to trigger a job only when a merge request is made from releases/* to master. I need to block all other merge requests to master e.g. to prevent a merge directly from development to master.
Does Gitlab CI support a trigger ONLY when branch is master AND the originating branch matches releases/* ?
GitLab does not support triggering a pipeline for merge commits only so far. Therefore it does also not support triggering a pipeline only for some merge commits.
There are two ways you might differentiate merge commits from normal commits:
Merge commits have multiple parents.
Merge commits have a standardized commit message in regular cases.
GitLab does not support filtering based on number of parents nor on the commit message (except for skipping CI with [skip ci] or [ci skip]).
You could find more information about support filtering options in the documentation for only and except options of GitLab CI/CD Pipeline Configuration.
I want to use the Gitlab api to create a commit to create several commits on a single branch, but I'm worried that Gitlab's CI will activate for each commit.
Will creating a commit using the repository/commits api trigger CI? If not, is there a way to manually trigger CI when I'm done? If it will, is there a way to supress it, like git push -o ci.skip (see here)
A commit created by an API call is treated as a regular git commit. This means it will trigger your CI if it matches the conditions of your .gitlab-ci.yml file.
If you want to skip the CI add [skip ci] to your commit message.