We have libraries in Visual Studio and bamboo, that get changed more often. We want our weekly build to find that library (say it is version 2.3), but in bamboo we have that library being built and deployed at 2.4. Which of course is stored in the packages.config file.
I am sure there is some way to do it, that others have wanted to do this, but I can't find exactly something that spells it out (or I am reading into things too much or too little).
How through bamboo, would we go into this and change before the build?
Is it a third party tool? Recommendations?
Is there some script that is done?
Is there some tool within bamboo that handles this?
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
I evaluate SOA products of wso2 for few weeks and there are some basic (and crucial to me) features which I cannot find/use or maybe it just does not exist. I want to make sure.
First of all, creating IDE support. As probably most of you know wso2 team delivers Carbon Studio which is quite a nice thing. Unfortunately when it comes to team work so often importing existing projects into IDE I hit a wall because:
1) If I use Distribution Project I'm required to commit .projects files which actually contains nature understand by Carbon Studio. It is acceptable but it is as well bad practice in my opinion.
2) If I use Maven then after import I'm going to loose project nature so plugins are not going to work without preparing .projects.
Am I missing something? I would like get rid of .projects and be able to use IDE on 100%. Is it possible? Can't it be generated or something. Normally plugins are trying to recognize file type and edit it with specified plugin. I understand that most Synapse configs (for example) are all XMLs but that is not a reason for me. Any way, does someone know some kind of solution?
Also Distribution Project cannot be build from command line if known maven repositories cannot deliver some artifact. I can write maven plugin to implicitly build each wanted artifact but it is not something I want to do if maven can do it for me. And I cannot use maven because after import I'll lose IDE features.
To me IDE is useless if I'm required to fix each project before actually importing it. Time is very precious.
The second important and unacceptable feature is importing jars into project when using, for example, generators. Why created project cannot be configured to use dependencies?
Robert
what is the developer studio version you use? From developer studio 2.0.0 there is a feature to import a carbon project. Then you don't need to commit the .project files.
Goto import --> WSO2 --> Existing WSO2 projects into workspace
Do you have some opinion for code coverage in Hudson.. Now i have build with Msbuild and MSTest and that's work.
But for code coverage, i think i need some help. I have searched that somebody use nCover another with Emma. Which one is better and more easier ? And maybe reference to help me.
Best regard,
Are you .NET (NCover) or Java (Emma) or both?
NCover should work with Hudson but costs
Open Source projects exist look for PartCover and more recently OpenCover.
All three .NET tools support command-line and as such they should integrate with Hudson.
We are currently using dotCover by JetBrains. It's cheaper than NCover and it integrates well with Visual Studio. You don't have to use a separate application (NCover Explorer) to view your code with the covered/uncovered highlighting, which is great.
The command line version of dotCover allows you to create XML files of the analysis and you can parse the XML via <XmlRead> (in the MSBuild Community Tasks library) to parse the output.
It takes a while to get set up properly, but it works.
If you used the following:
Continuous Integration using build scripts
IDE for code development
Do you run into problems of synchronizing your build scripts with the IDE build system? If so, how do you resolve this kind of issue? Using any environment (Java/.NET/etc) to explain the solution will do. I just want to get ideas on how people solve this problem.
In Java world you can have 2 kind of scripts - build scripts & scripts to generate project file for your favorite IDE (ipr for IDEA for example). Such that if you project's structure have changed just re-run the script that will update .ipr file, for example. Also, various people in the team can work with different IDEs.
In .NET world there are 2 options:
if you build with MSBuild then you don't need to synchronize anything - .csproj files from VS are valid MSBuild files as well.
if you build with NAnt you can run devenv task that will go to .sln file and still call .csproj files that are always up to date.
This is my second question on Bamboo (My First One). My understanding after reading suggested info, I need a build tool, like nAnt or MSbuild to write a script that gets the source code and builds it (I am working on a .net 3.5 with silverlight project). After, when deploying, I need to write scripts to move my files to the diff servers. Please tell me whether I am going in the right direction or not. Can I use ant, maven, bash scripts to do the same with a .net project?
Yes, that is true:
Bamboo is the central management server which coordinates all work
Bamboo itself has interfaces and plugins for lots of types of work
Bamboo basically needs to first get your source from a source repository (lots of plugins here for a variety of systems)
Then it needs to do the build - that can be done by using MSBuild to build your Visual Studio solution, or it could be a batch file to call your XYZ compiler and linker to create your app - whatever it is you have and use
Once your solution or project is built, you have "artifacts" (build results, e.g. executable app, config files, etc.) lying around
with those results, you can do additional things:
zip them up into a ZIP file and copy them somewhere
run a install builder on them and create an MSI
install them on a test server to make sure everything installs just fine
The sky's the limit! :-)
But in general: Bamboo is just the "orchestrator" - the coordinator. The actual work is done by either direct Bamboo plugins (of which there are plenty), or then you can call external command-line apps by means of a unix script or Windows batch file.
Marc