I was wondering if anyone could recommend best practise for SBT builds using Bamboo. I see that is a Bamboo plugin for SBT however it is a) unsupported and b) isn't compatible with later versions of Bamboo. This combination would almost certainly be a blocker for us as using it could lead to a position where we couldn't take a Bamboo update (potentially fixing a security issue) because it would break all of our SBT builds.
Presumably you can just set up Bamboo to build SBT projects as a script task but I'm a bit worried about the experience here as it's not clear to me how things like failing tests and code coverage will be represented.
Is it possible to have a reasonably slick SBT and Bamboo setup without using the plugin or is Bamboo not a suitable CI system to use with SBT?
We do heavily rely on bamboo in our sbt workflows. The plugin works fine but the only benefit over a short inline script is the parsing of tests which is also available as another task.
We love having some portable build scripts in the projects which can be also used by bamboo.
So here is the starter guide:
have a good portable build script in your project (presumably bash script)
call this script in an inline script in bamboo (so you can do some other stuff as well, e.g. checkout submodules, choosing docker host, ...)
Related
I'm tyring to find a better method to run my SBT project with continuous build (compile) and run, SBT can already do continuous compile and test but not with the run command unless I'm not aware how that is possible.
I tried using the ~ command on run but it does nothing
sbt clean compile ~run
I tried using the spray sbt plugin
addSbtPlugin("io.spray" % "sbt-revolver" % "0.9.1")
but it is so tempremental and hangs a lot while trying to kill the current process making it faster to just kill the app then run sbt clean compile run
Is there a way to achieve this?
sbt clean ~run should work fine and rerun main method every time you change the sources. But if you're running a web server which is supposed to run continuously, sbt won't interrupt it to rerun.
So you should use sbt-revolver for that and solve any problems with it by either asking another question or submitting a bug report for the plugin.
I am writing e2e Tests for some JS application at the moment. Since I am not a JS developer I was investigating on this theme for a while and ended up with the following setup:
Jasmine2 as testing framework
grunt as "build-tool"
protractor as test runner
jenkins as CI server (already in use for plenty java projects)
Although the application under tests is not written in angular I decided to go for protractor, following a nice guide on howto make protractor run nicely even without angular.
Writing some simple tests and running them locally worked like a charm. In order to implicitly wait for some elements to show up in den DOM I used the following code in my conf.js:
onPrepare: function() {
browser.driver.manage().timeouts().implicitlyWait(5000);
}
All my tests were running as expected and so I decided to go to the next step, i.e. installation in the CI server.
The development team of the aplication I want to tests was already using grunt to build their application so I decided to just hook myself into that. The goal of my new grunt task is to:
assemble the application
start a local webserver running the application
run my protractor test
write some test reports
Finally I accomplished all of the above steps, but I am dealing with a problem now I cannot solve and did not find any help googling it. In order to run the protractor test from grunt I installed the grunt-protractor-runner.
The tests are running, BUT the implicit wait is not working, causing some tests to fail. When I added some explicit waits (browser.sleep(...)) everything is ok again but that is not what I want.
Is there any chance to get implicitly waiting to work when using the grunt-protractor-runner?
UPDATE:
The problem does not have anything to do with the grunt-protractor-runner. When using a different webserver I start up during my taks its working again. To be more precisley: Using the plugin "grunt-contrib-connect" the tests is working using the plugin "grunt-php" the test fails. So I am looking for another php server for grunt now. I will be updating this question.
UPDATE 2:
While looking for some alternatives I considered and finally decided to mock the PHP part of the app.
Is there a way I can start and stop sinopia as a grunt task? All tutorials I see use cli and I'd prefer a portable solution if possible.
I'm trying to develop a build system for a multimodule project where the modules are dependent on each other, my plan to attack this is to have each module publish itself to a local sinopia server during the build so that dependent modules will find it as a dependency.
You can certainly use grunt to run the sinopia command, but I don't think that's the question you're trying to ask.
Let me ask you: why do you want to start and stop sinopia more than once? My understanding is that you start sinopia and leave it running, and it will let you publish packages to it and download them without having to restart it.
Which tutorial(s) are you following? Perhaps that will help me understand your question.
I am involved in development of a large cross platform project that build for Windows, Linux, and Mac OS X. The build for the software is configured with CMake.
The CMake scripts have been designed to configure successfully for Visual Studio on Windows, and Makefiles are currently used for building on Linux and Mac OS X.
Pretty much all of the development for the project so far has been done with people working on Windows, and a little bit of work on Linux. I am interested in developing for the project using Xcode 4.6 on a Macintosh running Mac OS X 10.7, and I have encountering problems as the CMake files do not seem to configure properly for that development environment.
For non-windows platforms many custom commands have been written to try to configure things such as copying needed files or setting environments that are needed for certain operations such as running unit tests during the build process.
It seems that because Xcode is an integrated development environment simliar to Visual Studio is has this concept of a build configuration, and when software gets build output files in up in a directory path that includes that configuration concept (i.e. many build files end up in a path that ends with folder named something like Debug, Release, etc.)
CMake is supposed to have support for dealing with this build configuration concept and the mechanism utilized work well for Visual Studio. That do no seem to work for Xcode. For example our build engineers have design CMake scripts so that for Windows, many path and whatnot are configured using the CMAKE_CFG_INTDIR value which helps to qualify the build configuration.
The use of CMAKE_CFG_INTDIR is not working for Xcode as the script for Macintosh were written with Makefiles in mind which don't really have the build configuration concept. The use of CMAKE_CFG_INTDIR within custom commands used to configure things fails on the Macintosh as the value resolves to $(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME). This values are not define when the custom commands are run, so values are not set properly and build operations fail.
It is unclear what is needed so that the system can successfully configure for Xcode. Searching on the Internet so far has not yielded insight into what should be used to make sure that build configuration can be successful. What resources are available that would help in figuring out how to configure this project to build with Xcode?
If you're talking about custom commands set using add_custom_command, then you should prefer "generator expressions" to avoid issues regarding per-configuration build directories. From the docs for add_custom_command:
Arguments to COMMAND may use "generator expressions" with the syntax "$<...>". Generator expressions are evaluated during build system generation to produce information specific to each build configuration.
For example, the build directory for a target called "MyExe" could be referred to as $<TARGET_FILE_DIR:MyExe>
Generator expressions are available in a few CMake commands, not just add_custom_command.
If you have more specific problems, it's maybe worth asking further question(s) with the relevant details.
Net solution for a website, consisting of 5 projects, and there are a few(less than 10) developers working on the solution. We deploy almost on a daily basis.
The question is, how to setup the SVN repo to support this scenario (the daily deploy), also mentioning that not every commited file should go to production, there is a QA check before deploying.
Try out TeamCity
(CI tool) as its free for smaller amounts of CI. this may be better for you than CruiseControl.Net as CCNET is very configuration heavy as its all done via XML. TeamCity uses wizards to create the scripts to manage releases
if you need any other help on CI then let me know as its something I am evangelistic about.
What you want to do is commonly referred to as Continuous integration (CI).
While you can do that using Subversion, it is probably not the right tool for the job.
There is special CI software, which will allow you to easily automate the necessary tasks (checkout from version control, compiling / building, running automatic tests, deployment etc). An example would be CruiseControl.NET.
As to "not every commited file should go to production", the common solution is to have a special "release" branch, which gets deployed. Only tested code is merged there (or have the trunk always be stable, otherwise same model). Of course, you can also (better: additionally) have tests before your automatic deployment, and only deploy if all tests pass.
Working with a release branch
In practice, this means that people check in their code as they produce it. Sometimes this code will work, sometimes not. When the release time draws nearer, a "release branch" is created in Subversion. This release branch is then effectively a frozen snapshot of the source as it was at the time of branching. Now this branch can be used to compile & deploy the application, which can then be tested.
No new code is checked into the branch (but checkins can continue elsewhere). Only if a bug is detected in the branch, will there be a checkin into the branch to fix it. This continues until the branch passes all tests. Then the branch can be released as a new version of the software; afterwards the branch will only be used if the released version needs to be patched.
Of course, any bugfixes checked into the branch need to also be put into the trunk (either by merging branch -> trunk, for which Subversion provides special support, or by reimplementing the fix in the trunk, as appropriate).