So we are currently just deploying master but are running into issues where we want to deploy the commit/build in which all our testing was ran on. This is normally a snapshop of master at 4:30pm. We run our build configuation for all tests automatically at 4:30pm (lets call this build config ALLTESTS), so we can control how this commit/build is marked in the ALLTESTS config.
We separate testing and deploy, so when a deploy is executed (either manually or automatically) it should only pick a branch/tag/commit/build that has been marked. Adding the tests to our deploy build config is not a viable solution.
Originally I had planned on using Git tags. A tag called deploy would be deleted and added to certain commits and then when the deployment is triggered that commit would be deployed.
The issue I ran into here is that there isnt an easy way to manually add git tags in a build step. Should I just write command-line build step that uses git commands remove the tag deploy from whatever commit has it and to add it to commit that is running?
Is there a better teamcity way to do this? I have successfully got teamcity tags to work via REST API but I am not sure if those fit the need either.
I suppose I could write powershell to parse the rest API to get the build id that was last successful in ALLTESTS and then feed that into the deploy somehow. How would I go about getting a build number and using that as the basis of deploy?
Should I just write command-line build step that uses git commands remove the tag deploy from whatever commit has it and to add it to commit that is running?
Quick answer is no. You can actually use something like this:
git tag -f deploy <commit-sha>
And have your tag updated to the given commit.
Cheers.
Related
I'm trying to migrate old fashioned Jenkins DSL jobs (in Groovy) to the new descriptive pipeline form.
Since I'm very new to the pipeline and I could not find any answer to my noob problem, I'll firstly describe my scenario here:
Supposing I have 3 DSL jobs, one to build and save the artifact generated in a repository like Artifactory, another to tag the master branch and the last one is used to deploy to prod. All jobs use the same Git repository.
The building job is usually run many times during development. It can be triggered manually or as a response to events in the Git repo, e.g. merge requests and pushes.
For simplicity, let's assume the tagging job only needs to tag the master branch in the repo. This will only be run once in a while, manually, when we are pretty sure the master branch will go to prod.
Artifact gets deployed using a third job, also manually.
So here are my questions:
As I understand we can only have one file per branch in the repo, so how can I configure such a setup using a pipeline defined in only one Jenkinsfile?
How can I manually trigger the tagging job only (meaning compile/test/generate the artifact without uploading and then if everything tests ok, tag the version)?
In this situation, will it be easier for me if I just implement the building job in the pipeline and keep the others as DSL scripts?
Many thanks for any suggestions!
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 investigating adding an app.json file to my heroku pipeline to enable review apps.
Heroku offers the ability to generate one from your existing app setup, but I do not see any way to prevent it from automatically committing it to our repository's master branch.
I need to be able to see it before it gets committed to the master branch because we require at least two staff members to review all changes to the master branch (which triggers an automatic staging build) for SOC-2 security compliance.
Is there a way that I can see what it would generate without committing it to the repository?
I tried forking the repo and connecting the fork to it's own pipeline, but because it did not have any of our heroku add-ons or environment, it would not work for our production pipeline.
I am hesitant to just build the app.json file manually - it seems more prone to error. I would much prefer to get the automatically generated file and selectively remove items.
As a punchline to this story, I ended up investing enough time into the forked repository on it's own pipeline to demonstrate a POC
When you generate your app.json file, it should take you to a secondary screen that has the full app.json in plaintext at the bottom.
Why not open a PR with its contents in your project root. Once it's detected on the repository Heroku shouldn't ask you to regenerate it again.
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.
I am trying to use bamboo to manage my release procedure and just wondering if this is feasible:
The developer finished the integration test at local environment
The developer create a specific tag, e.g. "UAT_1.0.0" and pushed the tag to bitbucket
Bamboo sensed that there is an new tag "UAT_1.0.0" has been created on bitbucket and then start the building process; after that it will deploy the war file to the UAT server
Tester signed off the UAT and created a tag "REL_1.0.0" and pushed the tag to bitbucket
Bamboo sensed the new tag "REL_1.0.0" and start the building process. After build finished, it deploy the war file to the PROD server
It looks like the "Repository triggers the build when changes are committed" is to best way to implement the process. But I can't find out the way to move any further. Any idea?
Yes you can do this (Only if you can deploy custom plugins to it).
You need to build custom triggers as plugins for bamboo.
Get/Install the SDK
Create a plugin. See here.
If you have access to bamboo's source code I suggest you look into classes DependencyTriggerReason, InitialbuildTriggerReason, ScheduledTriggerReason. You need to create a class implementing TriggerReason. You should start with this tutorial if you are new to developing bamboo plugins.
Deploy it to bamboo.
A bit late but... I found a solution. You need to put a "negative" regular expression in the "Exclude changesets" section in the repository configuration, that include the word that you want.
The regular expression is like :
^(?!.test).$
like that: repository configuration
with this, bamboo will only build commits with this word in the message.
Now, if your commit is like "commit for test", bamboo will build it