I need to show version number including three figures
1. Using pom version (done)
2. Commit number from Git (done)
3. Build number from Bamboo ( worst part :( )
I tried to make one property file with placeholders as bamboo.properties in my project. I am expecting that when Bamboo prepares the build it will replace those properties and include that file in war. Later I will read those properties and expose to Web Layer.
Am I doing right? Because I need that my other team members should able to make build locally without Bamboo?
bamboo.properties:
bamboo.buildKey=${bamboo.buildKey}
bamboo.buildResultsUrl=${bamboo.buildResultsUrl}
bamboo.buildNumber=${bamboo.buildNumber}
bamboo.buildPlanName=${bamboo.buildPlanName}
bamboo.buildTimeStamp=${bamboo.buildTimeStamp}
Here is how we achieve above after long time.
Pom version
A simple maven property that can be accessed.
Commit id from git
Since in this project we are using git only, there is a maven plugin that gives you information about commit number. With the help of it you can retrieve Git commit id. For details please look for
git-commit-id-plugin
For bamboo there is environment variable that you need to configure in bamboo settings (For me this has done by client as he owns it). But after it we access it in our env as "<bamboo.build.no>"
Thanks
Related
We have a Subversion repository setup in this manor:
http://svn.vegicorp.net/svn/toast/api/trunk
http://svn.vegicorp.net/svn/toast/api/1.0
http://svn.vegicorp.net/svn/toast/data/trunk
http://svn.vegicorp.net/svn/toast/data/branches/1.2
http://svn.vegicorp.net/svn/toast/data/branches/1.3
I've setup a Jenkins Multi-Pipeline build for the entire toast project including all sub-projects -- each sub-project is a jarfile. What I want is for Jenkins to fire off a new build each time any file is changed in one of the toast projects. That project should rebuild. This way, if we create a new sub-project in toast or a new branch in one of the toast sub-projects, Jenkins will automatically create a new build for that.
Here's my Jenkins Multi-Branch setup:
Branch Sources
Subversion
Project Repository Base: http://svn.vegicorp.net/svn/toast
Credentials: builder/*****
Include Branches: */trunk, */branches/*
Exclude Branches: */private
Property Strategy: All branches get the same properties
Build Configuration
Mode: By Jenkinsfile
Build Triggers (None selected)
Trigger builds remotely (e.g., from scripts) Help for feature: Trigger * builds remotely (e.g., from scripts)
Build periodically Help for feature: Build periodically
Build when another project is promoted
Maven Dependency Update Trigger Help for feature: Maven Dependency Update Trigger
Periodically if not otherwise run
Note that the list of Build Triggers list does not include Poll SCM. Changes in the repository does not trigger any build. Jenkinsfiles are located at the root of each sub-project. If I force a reindex, all changed sub-projects get built and all new branches are found. I did originally checked Periodically and reindexed every minute to pick up a change, but that's klutzy and it seems to cause Jenkins to consume memory.
Triggering a build on an SCM change should be pretty basic, but I don't see a configuration parameter for this like I do with standard jobs. I also can't seem to go into sub-projects and set those to trigger builds either.
There must be something really, really simple that I am missing.
Configuration:
Jenkins 2.19
Pipeline 2.3
Pipeline API: 2.3
Pipeline Groovy: 2.17
Pipeline Job: 2.6
Pipeline REST API Plugin: 2.0
Pipeline Shared Groovy Libraries: 2.3
Pipeline: Stage View Plugin: 1.7
Pipeline: Supporting APIs 2.2
SCM API Plugin: 1.2
I finally found the answer. I found a entry in the Jenkins' Jira Database that mentioned this exact issue. The issue is called SCM polling is not being performed in multibranch pipeline with Mercurial SCM. Other users chimed in too.
The answer was that Jenkins Multi-branch projects don't need to poll the SCM because indexing the branches does that for you:
Branch projects (the children) do not poll in isolation. Rather, the multibranch project (the parent folder) subsumes that function as part of branch indexing. If there are new heads on existing branches, new branch project builds will be triggered. You need merely check the box Periodically if not otherwise run in the folder configuration.
So, I need to setup reindexing of the branches. I'm not happy with this solution because it seems rather clumsy. I can add post-commit and post-push hooks in SVN and Git to trigger builds when a change takes place, and then reindex on a periodic basis (say once per hour). The problem means configuring these hooks and then keeping them up to date. Each project needs its own POST action which means updating the repository server every time a project changes. With polling, I didn't have to worry about hook maintenance.
You never mentioned setting up a webhook for your repository, so this may be the problem (or part of it).
Jenkins by itself can't just know when changes to a repository have been made. The repository needs to be configured to broadcast when changes are made. A webhook defines a URL that the repository can POST various bits of information to. Point it to a URL that Jenkins can read, and that allows Jenkins to respond to specific types of information it receives.
For example, if you were using github, you could have Jenkins listen on a url such as https://my-jenkins.com/github-webhook/. Github could be configured to send a POST as soon as a PR is opened, or a merge is performed. This POST not only symbolizes that the action was performed, but will also contain information about the action, such as a SHA, branch name, user performing the action... etc.
Both Jenkins and SVN should be capable of defining the URL they each respectively POST and listen on.
My knowledge lies more specifically with git. But this may be a good place to start for SVN webhooks: http://help.projectlocker.com/knowledge_base/topics/how-do-i-use-subversion-webhooks
Maybe you need something under version control in the base directory. Try putting a test file here http://svn.vegicorp.net/svn/toast/test.txt. That may make the poll SCM option show up.
I want to create automatic upload to ftp, using 'FTP Upload' runner, with different build configuration, which depends on successfull build of main configuration. But the thing is I don't know the pattern. As for now path looks like this:
C:\ProgramData\JetBrains\TeamCity\system\artifacts\<project_name>\<build config name>\528
What variable contains this last number?
The problem was with bad description of my problem, more definiteve one:
I have to store artifacts on FTP. FTP is on the same machine as TC server and agent (don't ask me why). So I have to somehow grab artifacts and put them into ftp://"project"/msi and ftp://"project"/nuget, depending on build configuration. I've tried: Grabbing artifacts directly - from folder shown in the initial post, idea failed.
The solution is to create another build configuration and set Artifact dependencies, this makes artifacts reachable from new build configuration, which allows to use FTP Upload runner.
Thanks everyone!
I'm working on a strategy to tag builds in my continuous integration and delivery pipeline. When a fresh build is produced it then goes through multiple stages of testing; after each stage I would like to tag the build. My idea was to expand on the standard Maven system, so an example would be:
my-artifact-1.0-SNAPSHOT.jar
my-artifact-1.0-PASSED_TESTS_1.jar
my-artifact-1.0-PASSED_TESTS_2.jar
...
my-artifact-1.0-RELEASE.jar
As a build passes each stage its tag, which is part of its name/version, gets updated. Eventually, after all testing stages the build is tagged as releasable with RELEASE.
I'm using a Jenkins server and storing artifacts on Artifactory (non-Pro) in Maven repositories. My plan is to use separate Maven repositories for each tag type above, and to move an artifact from one to the other as its tag is updated.
My pseudo-code for the promotion looks like:
(1) Download artifacts that passed in Jenkins
(2) Text-replace the tag (maybe pom.xml as well?)
(3) Upload to new repository
(4) Update the associated Git commit with tag also
I'm not sure how to actually implement this cleanly - is this a common way of doing things? Am I missing something important? Can a Jenkins + Artifactory (non-Pro) + Maven (repos only, Gradle for builds) system accomplish this?
Thanks!
I can see where the idea of adding more metadata to the file names come. Usually, we don't have any other place to add this kind of information, except of the name. But with a proper artifact repository manager (as Artifactory), you don't need it anymore. You can attach any metadata to the artifacts in the repository manager, and then manipulate (e.g. promote) the artifacts based on those properties.
Here's a screencast showing what it takes to add this kind of metadata to the artifacts, and how to promote artifacts based on it.
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
Currently a Maven build (inside Jenkins) is configured to deploy every artifact it builds (releases and snapshots) to a Nexus repository. Now I have to push some of those artifacts to application servers and thought of letting the target servers fetch them from Nexus - this is easy for releases but how can I reference the SNAPSHOT artifacts? Maven's deploy plugin adds a timestamp to make each artifact unique (which is good) but I couldn't find a way to get that generated timestamp for later use!
Quick Aside: I plan to use the promoted builds plugin to start a script on the target server(s) which then in turn ask Nexus for the new artifact to deploy.
Does anybody know how I can make Maven say the timestamp it generates? Or do I really have to parse the whole output for Uploaded: https://NEXUS_URL/content/repositories/snapshots/GROUP/ARTIFACT/VERSION/ARTIFACT-VERSION-TIMESTAMP-SUFFIX.TYPE?
As far as I know you do need to parse the output of the deploy goal.