is there a way to notify a CI system about a new published version of an artifact and trigger a build?
The scenario looks like that:
Developer of team A working on component C commits changes
CI is triggered, builds and runs tests
After tests are passing the binaries are published to an artifact repo (Nexus)
Another CI job receives this notification and triggers a build where other components + the new component C version are tested (integration tests).
Is there any plugin available on the market that supports such a notification mechanism? I haven't found yet such a tool for Nexus(Ivy)? The only thing I found is an Artifactory plugin from JFrog where you can publish from Teamcity directly.
Thanks,
Martin
I'm not aware of anything pre-made that does this. But you could easily write a small plugin that does this. Have a look at the "virusscan" example here, it would just take a few small modifications to make it do what you want:
https://github.com/sonatype/nexus-example-plugins/
Artifactory nowadays supports webhooks to achieve what I asked years ago: https://www.jfrog.com/confluence/display/JFROG/Webhooks
Related
We are currently using bamboo to build and test our software. Now our build plans are just a bunch of task: execute this bat, execute that bat etc. Created with the Bamboo UI.
It happens that over months/years the build plan needs adjustments:
Parallelize jobs
Add extra jobs
Change some tasks
But this will break when we try to build an older version of the software. Some scripts (called from bamboo task) are not-existing in older versions.
At my previous employer we used Jenkins pipelines where the content of the build and test was just a file present in the sources repo.
Now with bamboo it appears you can use Bamboo Specs. From I read you create specs file and when you run this, it which will create build plan. But I don't see a relation to cater for changing build plans over time (changing steps).
For example the Bamboo Specs of develop are used to build all Plan Branches (e.g. Pull Requests). So if you want to change the build in a PullRequest, you first need to merge this into develop, the Bamboo Spec of develop updates the Build Plan. Not possible to test this before merging.
Question: How can you make scripted buildplans in Bamboo, where every branch of develop can a have possible other way of building?
We have it now setup as:
Buildplan 'Product A': plan branches: develop, release_x, release, y
Buildplan 'Product A PullRequest': plan branches: feature/*
Edit: supported in 7.0: https://confluence.atlassian.com/bamboo/enhanced-plan-branch-configuration-996709304.html
Old answer:
I found Atlassian documentation: https://jira.atlassian.com/browse/BAM-19620. They call it 'divergent plan branches'. No support, there is a feature request.
As of 15-4-2019:
Atlassian Update – [11 April 2019] Hi everyone,
Thank you for your votes and thoughts on this issue.
We fully understand that many of you are dependent on this
functionality.
After careful consideration, we've decided to prioritise [this
feature] on Bamboo roadmap. We hope to start development after our
current projects are completed.
Expect to hear an update on our progress within the next 6 months.
To learn more on how your suggestions are reviewed, see our updated
workflow for server feature suggestions.
Kind regards,
Bamboo Team
Question: How can you make scripted build plans in Bamboo?
To make scripted build plans in Bamboo, you have to use bamboo specs. Since you are already familiar with Jenkins, bamboo specs work exactly like Jenkinsfile by automating your pipeline. The benefit of using this is that it lives in your source code and the changes you make to this file in your source code automatically changes your plan(pipeline) when bamboo build is triggered.
This is how I script build plans in bamboo:
I add my bamboo.yml file under the root of my repo. But currently, I use git subtree and my bamboo specs live in there. But you don't have to do this. The below link provides you with a simple approach.
Link my repo to bamboo
Tell bamboo to scan for bamboo specs in the repo
Make commit and push
https://confluence.atlassian.com/bamboo/tutorial-bamboo-specs-yaml-stored-in-bitbucket-server-941616819.html
If I have to make changes to the plan in the future, I edit the bamboo specs file then commit and push.
I had the same problem and unfortunately had to go through an unpleasant choice
Backporting the build script
This is not necessarily feasible everywhere, but I managed to make it work somehow for my project.
The idea is: treat the build script as a C#/Java interface, or better as a contract.
As soon as your branches do not provide significant changes in building the software, e.g. your desktop app becomes a web app, or you switch from Ant to Gradle, you can handle this.
Assuming my application is always a web application to be released as a jar on JFrog Artifactory, I have identified the following steps that are common to all maintained versions:
Use javac to build the jar of all modules
Use gulp to build the Javascript resources
Run JUnit from the repository
Baptize 💒 the artifacts with a version number obtained with a tricky algorithm
Push the artifacts to JFrog Artifactory
So the idea is that I had taken my Ant build script and mostly rewrote it in order to do the same tasks on different versions of the application. I started doing the changes from an older version, not maintained anymore, as an excercise. In fact, my official Git branches look like release/x.y.z where semver is x.y.z.k and newer bugfix-builds are built from the head of any x.y.z release.
So I took release/3.10.0 branch and rewrote Ant. I am currently testing with a manually created Bamboo plan
Stage: Compile
ant clean ivy-retrieve compile jar #builds the jar in a job
ant gulp-install gulp-prod zip #creates javascript resources
Stage: Test
ant run-junit
Manual Stage: Release
ant baptize ivy-release #tags the artifact using ${bamboo.jira.version} and pushes to JFrog Artifactory
What I am going to do with Yaml
Since the build script is the same, but specific tasks (e.g. Java compiler version) may change in different versions, I can create a very single Yaml script that rules them versions all.
I will then merge release/3.10.0 => release/3.10.1 => release/3.10.2 ... release/3.11.2 by merging the conflicts
Personal experience
Tonight I am struggling in making the JUnit tests work as I also chose to backport my testing framework to the older version of the project. I accept that a few tests will fail because older and non-maintained versions contain bugs. For me this is a way to prove that the system works.
Indeed, diverging branches are a great idea, but I am forced to use Bamboo 6 in my office
Given that we have a project called tools-lib.jar and it currently is at version 1.0.0 and other projects such as rest-api.war have a dependency on tools-lib-1.0.0.jar. Lets assume that both tools-lib and our rest api are under development by separate teams with separate timelines. What I would like to do is make my rest-api.war depend on tools-lib-2.0.0.jar. If the 2.0.0 release version isn't there, the application would go build against 2.0.0-SNAPSHOT. Does anyone know of a way to configure this via maven?
The goal of this is that if the rest-api is done before the tools lib, we don't have to go back through and change all the dependencies manually in order to build against the release, it will just do it.
Thanks in advance.
Is there any way to setup Travis CI on our own machines for private repositories and have it connect to our own git server?
Looks like they are working on private repository support. It's in private beta testing now. Checkout this thread https://groups.google.com/forum/?fromgroups#!topic/travis-ci/Asq30ulew4E
Update:
You can also check https://circleci.com/ for private repos.
Another alternative is gitlab-ci. This works well with gitlabhq and is open source.
UPDATE:
I have recently tried Jenkins with GitlabHQ. They both can co-exist very well too, but with the help of additional plugins. Jenkins does not come with support for git out of the box, but a plugin is readily available for that.
Installing Jenkins was very straight forward on Ubuntu. I am guessing it must be as easy on other platforms as it is written in Java and is available as a .war file. Configuring it is also very easy from its web interface.
Numerous plugins are available (including those for GitlabHQ, Github etc.). Plugins can be downloaded and installed right from its web interface.
Travis now has a private offering, the starting price at the time of writing this is $129.00 USD per month for unlimited repositories with two simultaneous builds. Very easy to set up and if you're already on GitHub it integrates very nicely: https://magnum.travis-ci.com/
I think this is what you are looking for. I especially like only paying for build time.
http://beta.travis-ci.com/?r=http://about.travis-ci.org/docs/user/travis-pro/
Jenkins is also a possible CI tool. cloudbees offers enterprise support.
Travis CI now offers Travis Pro for private repositories. Users with a student email address can sign up for GitHub's Student Developer Pack and get access to build from private repositories for free.
I am testing out automatic deployment of build artifacts from Bamboo to Artifactory. I installed the Artifactory plugin in Bamboo, and then set up a test build plan. I added an "Artifactory Generic Deploy Task" since I'm not using Maven, Ivy, or Gradle.
My repository layout is:
group / product / version / filename.extension
It was pretty easy to specify where the artifact should go in the "Edit Published Artifacts" field in Bamboo:
myartifact=>com.example/someproduct/${bamboo.buildNumber}
This is fine for snapshot builds, but what if I want to make a release with a specific version number? What do I put in place of ${bamboo.buildNumber}? Or do I need to take an entirely different approach?
It's normally preferred to promote a satisfactory snapshot build to a released status than to run an independent release build.
Although Artifactory's release promotion support was not implemented for Bamboo's generic build type, starting with version 2.6.0 you can actually implement your own build promotion strategy within Artifactory as a custom User Plugin and invoke the procedure via a REST-API command.
So the procedure becomes pretty simple:
Write a release promotion strategy.
Add a Bamboo build step that executes the promotion via REST.
Build your snapshots until you're satisfied with the state.
Execute release step.
We also keep an example of a release promotion strategy plugin in github.
IDEA has many plugins to use. I.e. IDEtalk is one of them which I use. How can I code a simple plugin that just connects to Internet and shows a web page? (no need for an address bar but it is not a problem to be). I want my plugin's shortcut's button locate at my IDE as like IDEtalk, Commander, Maven Projects etc.
Any ideas?
Check the documentation and the source code of the other plug-ins available in the public git repository of the Community Edition.
There is a Creating Your First Plugin guide on JetBrains web site. It covers all the needed steps from plugin creation to deployment to the plugin repository.
You might also want take a look in the source code of a simple plugin like Twitter Integration Plugin which I recently implemented. Or check a more complex one like this one.