Closed joel-costigliola closed 12 years ago
If nobody objects, I will take care of this short-hand. I already have one project there, know the application procedure, and will just go and apply for another account so that FEST-\ can be built on their Jenkins infrastructure.
CI here we come.
Cool !
On Mon, Jul 2, 2012 at 4:41 PM, Ansgar Konermann < reply@reply.github.com
wrote:
If nobody objects, I will take care of this short-hand. I already have one project there, know the application procedure, and will just go and apply for another account so that FEST-\ can be built on their Jenkins infrastructure.
CI here we come.
Reply to this email directly or view it on GitHub: https://github.com/alexruiz/fest-assert-2.x/issues/62#issuecomment-6709882
Hi,
CloudBees FOSS seems to be somewhat restricted w. r. t user management. I could not figure out how the applicant for a FOSS account can add users later on to allow them creation/triggering of Jenkins builds.
OTOH, CloudBees also offers BuildHive (https://buildhive.cloudbees.com) which makes it very easy to set up CI for github projects.
Plus, there is also Travis CI, which is very similar to BuildHive w. r. t. simplicity of setup. It uses its own CI server software, whereas BuildHive is Jenkins. Travis requires a configuration file inside the source code repository, containing information on which build runner should be used and which branches to build. I consider this bad style and dislike it somewhat. Build server config is a different concern and should be dealt with separately from source code. I don't want to edit my source code to tell the build server it should run another build for a new branch I just created. If all developers still want travis, I'd follow the herd, but otherwise I'd love to find a nicer solution.
Drawback of BuildHive: seems the owner of the repositories must configure CI for these repositories. Read: Alex needs to spend some tiny effort here, at least for the initial setup.
Before continuing, I'd like to know our requirements: what is our goal for CI? What is the scope?
Depending on requirements, it might be okay to use CloudBees FOSS, BuildHive, Travis CI or even something completely different which is not on our radar yet. E. g. Atlassian offers their Bamboo CI server to FOSS software projects in an "OnDemand" package (read: hosted). We could also try that. There are some conditions, one being we must have a public test setup for the software we're trying to use. I'd be willing to do the test setup on one of my servers.
And while we're at it: as Atlassian also offers a lot of other cool software for software development, we could (!) also apply for a hosted JIRA (issue tracking), FishEye (source code repo viewer), Crucible (code review) and Confluence (wiki) license... ;-)
So, looking forward for comments!
Best regards
Ansgar
I think we should start simple and build fest-assert and its dependencies (fest-util) on the master branch only. If we are happy with it we will expand our usage.
I'm gonna try subscribing to CloudBees DEV@cloud for Open Source Projects (details here http://www.cloudbees.com/foss/foss-dev.cb).
It's kind of an exploratory phase on CI, it should not prevent us to evaluate others solution in the meantime.
Fest now uses jenkins at cloudbees, available here : https://fest.ci.cloudbees.com/
Next thing to do :
sonar report are not yet available but should be, when ? we don't know.
see this thread : https://cloudbees.zendesk.com/entries/20115016-sonar-server-available-for-foss-projects
There won't be any sonar reports soon, Cloudbees quote : "There is no short term plan to deliver free Sonar service to CloudBees FOSS accounts"
Joel, you can request to add Fest Assert to http://nemo.sonarsource.org/ to have Sonar stats computed.
Thanks to SonarSource, we have sonar reports for Fest assert : http://nemo.sonarsource.org/dashboard/index/424557.
I'm closing this issue as I think we have made reasonable improvements towards CI and quality reports
More inormation here :