We have configured the Cruisecontrol for our project and all developers can check the build result using Dashborad and CCTray.
we working on multisite projects so dont want the build should be handled by developer as we have seperate continous integration. I was just curious if we can block a group of users from forcing the build. So we want the builds should be forced by build master and not be developers. Developers can just see the build result.
How can we do that?
Set forceBuild="Deny" in the RolePermission tag. See the CruiseControl documentation for more information.
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 am having an issue getting selenium end to end tests to work after an automated deployment using visual studio team services (VSTS).
I have a build working that generates a build artefact. This is triggered from VSTS but runs on an on premises build server. I have a deployment working that deploys to an on premises development web server. All this works including unit tests running after the build.
When I try to add testing after the deployment is when I run into the problem. The tests are to be run on the build server and point to the dev server website. The deployment has two phases. A deploy and then an agent phase that runs a test assemblies task using the build agent on the build server. The problem seems to be that the test dll's are not being included in the build artifact and so are never found when the test process runs. Deploy setup us as follows.
I have a copy files before the publish artifact in the build definition that seems to copy the files in to the right place but they are not included in the zip file artefact. I've looked at several websites and posts on here but I still seem to be missing a vital bit of knowledge that will get this working.
Use of the log did help as recommended so thanks for that.
I have managed to get this working. I separated the selenium tests out into a separate solution and built that separately creating it's own build artefact. I then added this to the agent task in the deploy. This worked. The only thing I need to get sorted now is the correct search path to find the test DLL's. It's not quite as dynamic as I would like at the moment. I can play tunes on that until I get it right though.
I accept this is working around rather than solving the original problem but needs and timescales must. I think moving the end to end UI tests out of the main solution makes sense anyway but no doubt others may think differently.
Thanks for your help everyone
I'm just starting to develop a new eclipse plugin where I want a web application server running in Eclipse. I found a nice blog, OSGi as a Web Application Server, that describes how to do this. The author suggests creating a target environment for my bundle requirements, and some of those bundles get pulled in from the Equinox Project SDK (now called Equinox Target Components in Juno). I notice that the tutorial project runs fine when my target platform is the platform I created in the tutorial, but fails to start when it is the default platform. So, now for my question...
If I need bundles that are not part of the default, how will my plugin project get access to those bundles? Will I need to deploy them along with my plugin? How would I know if the user's eclipse does or does not already have those required bundles?
You was not much clear about what kind of application you are developing. Running a web server in an Eclipse IDE as a plugin don't make any sense to me. This kind of server application is best just running on top of Equinox.
Anyway, the right path is to create a "Product Configuration" file and add categories that contains the needed bundles (go to File/Plug-in Development/Product Configuration).
With this file you can run an instance of the product (inside the IDE) and can export it (create a zip containing all needed bundles)
And if you want to able your user to install plugin inside his IDE you must create a P2 repository (using a Target Definition File) and expose the exported directory within a Http server. You could research about Tycho to build this kind of components in a maven style.
Well, I'm not sure if re-inventing the wheel again is really sufficient.
You might take a look at Pax-Web for inspiration on how to do it, or take a look Apache Karaf as a OSGi-Container (using Pax-Web). Or even better start contributing to one of the two :-)
I want to know how we can create different build like distribution, debug, release or development build using titanium studio.
Can we create custom build profile such that each of my build profile have different settings like if resource filters are applied on my project.
I don't think something similar exist, you need to build a custom tool. What about using git and its branches? Or write a script with a list of all your files and rename all the unnecessary with a ".disabled" extension?
I like scripting and automating things, if you want we can create some kind of project on github. :)
We have a code base composed of many projects. Currently each time we add a project on SVN we must reconfigure CruiseControl to start build and test on such project.
I'm looking for a tool (better if open source) able to scan the SVN repository and find new projects by itself.
A project can be "a SVN folder containing trunk, tags, branches subfolders".
Even better if the tool supports multistaged continous integration and build on demand.
Thanks
In general, projects tend to be just different enough to require the build system to be set-up manually. However, you could probably use something like Jenkins with some bash scripts to achieve what you're looking for; eg. if your SVN server has an HTML index of all the projects, you could set up a bash script to poll that page for changes then tell Jenkins to add a new project from a template.