If I deploy to prod from the latest release branch forked from dev how can I integrate PR to review code?
Also, if I would like to run a test integration pipeline automatically when a pull request is done to link the result to the pull request and improve the code review process is it possible with this kind of branch strategy?
At the moment I have the following branch strategy:
master
test
dev
features
Features are detached from dev, then merged in dev when they are ready.
When a set of features are ready I create a PR from dev to test and my test pipeline runs and shows the result inside the PR to improve the code review process.
When code is merged into a test after PR a pipeline ships it to the test environment and another test pipeline runs to test APIs from the outside.
Then code is merged to prod and shipped to prod.
Related
I need to build a Gitlab CI pipeline manually but not using latest of my master branch, but using a specific commitID.
I have tried running pipeline manually by using variable as below and passing its value but of no use.
Input variable key: CI_COMMIT_SHA
At the time of this writing, GitLab only supports branch/tag pipelines, merge request pipelines and scheduled pipelines. You can't run a GitLab pipeline for a specific commit, since the same commit may belong to multiple branches.
To do what you want, you need to create a branch from the commit you want to run the pipeline for. Then you can run the manual pipeline on that branch.
See this answer for step-by-step instructions on how to create a branch from a commit directly in the GitLab UI.
Use the existing (created by Gitlab CI) workspace to run the .gitlab-ci.yml and from there checkout the code again in a different directory using commitID, and perform all the operations there.
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 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 am using the new Jenkins pipeline DSL which I really like. My Jenkinsfile is probably fairly typical and compiles / unit tests code in the master branch of GIT using maven, does a docker build, deploys to staging etc. Towards the end of the pipeline there is a manual step where a user has to confirm if a build goes to production e.g.
stage name: 'Production Deploy', concurrency:1
input 'Do you want to deploy to production?'
node {
sh "./bin/production-deploy.sh"
}
However, the build blocks until someone accepts / declines. Is there a way to automatically decline the input if someone else kicks the build off (by merging code to the master branch)?
I sugest you separate the Continuos Integration pipeline of Continuos Delivery pipeline. In the CI pipeline you build, test, deploy from develop stage to staging stage, then someone validate the staging deploy and when all staging tests are OK in a next step you execute the DC pipeline; is when you deploy to production stage. in that way you have an independent livecycle develoment process and an independent delivery process.
[FYI - I am not looking to upgrade our Heroku account to Enterprise to take advantage of app grouping. We are a small team]
I am a collaborator on a heroku app. I was tasked with setting up dev-staging-production environments for the app and I am getting confused on how to setup Auto Deploy correctly with the GitHub-Heroku integration guide. I have been already given admin access to the original git repo.
From the 'owner' account on the production app I created two separate apps (dev and staging).
Now, I have 3 apps that I am a collaborator of:
(1) app.domain.com
(2) app-dev.domain.com
(3) app-staging.domain.com
I have created 3 remotes pointing to the 3 generated heroku-git repos:
live
dev
staging
I can push to the 3 Heroku apps easily by:
git push live master
git push dev master
git push staging master
BUT I want to setup auto-deploy for dev-staging apps.
I have pushed an "auto" branch onto dev and staging remote. My intention is for Heroku to detect pushes to that branch and "auto" deploy the code. But, heroku only detects pushes to "master" branch afaik.
git push dev release auto
git push staging release auto
But when I go to administer the Heroku dev-staging apps I only see the "master" branch in the Auto-deploy section. Shouldn't I also see the "auto" branch? Is the reason I am not seeing it because I didn't push auto as a remote branch on the ORIGINAL git repo? In which case, how do I structure this stuff as code lives in 2 separate environments (Heroku repo and GitHub repo)?
Ultimately, the plan is to setup some form of Continuous Integration and get tests run before releases happen across the dev-staging-production zones.
Am I overthinking this or is there a better way to get this stuff working? Appreciate it!
Heroku only tracks changes on the remote master Branch.
https://devcenter.heroku.com/articles/git#deploying-from-a-branch-besides-master
To push your dev branch to the Heroku master remote branch:
git push dev release:master
You may need to use the -f flag to force push (be careful!)
I think auto deploy on Heroku works only on default branch (usually named master), and you probably want to look into Heroku feature called pipelines. I've not used it myself yet and it's in beta stage, but it sounds like exactly what you're looking for. Not sure if I read it right, but it sounds like you created 3 individual projects, instead of branches in 1 project? How do you manage moving changes from one stage to another?
As for the CI setup I guess it depends on the kind of testing you're doing and the workflow. I'm in the middle of creating such process in my workplace, and what I will be proposing is as follows:
Devs develop and test on their local machines on feature branches before commiting and merging onto DEV branch
Commiting or merging onto the DEV branch triggers CI server, runs the build and perform PHPUnit and Behat tests
Successful build is being deployed to a server (possibly Heroku or any hosting provider that will support automated deployments) for QA.
Once tested and approved we can move the code onto STAGING branch repeat CI proccess and on success move to MASTER and go live.
We're using gilab.com to host our project and perform tests (CI server is included as standard even with free account), deploy dev and staging state for QA to Heroku, and finally host live version with a dedicated enterprise level provider.