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.
Related
I am using dotnet watch command to get automatic reloading for my application and it works quite fine. The problem I encountered is that if I do run some other tool that does something similar there is some locking of resources that happens and one of the processes fails.
My example is that I run live unit testing in Rider.
What I thought might be an easy fix is to add some delay to dotnet watch, so that live testing has some seconds heads up to run before dotnet watch will do a rebuild.
I did not find though any possibility for that unfortunately. Is it possible to achieve with some clever trick?
Does it make a difference (and if so, what difference) where I add the make install step?
In some posts they say to add it under Build like in the first screenshot. Others say it needs to go under Run/Deployment like in the 2nd.
Are both ways equivalent?
If it is part of Build Settings, it will be done every time you do a build under Qt Creator (assuming previous steps succeeded).
If it is part of Run Settings, it will only be run when you actually run the app under Qt Creator.
It depends on the case, which on you want. If it is part of Run Settings, then logically it should be configured to run the installed/deployed binary. If it is just for checking that make install succeeds, as part of the build, even though it will run the application from build directory when you run it under Qt Creator, then it should be part of build.
In your case, it sounds like make install is needed for running the app, so maybe it could be part of Run settings, to make normal builds just a bit faster.
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, ...)
Trying to setup my integration flow and I have some tests that are quite destructive using the velocity-cucumber package.
First issue I find is that these tests are being run on the standard Meteor db. Which on localhost and dev is fine, but not so great for production. As far as I can tell the velocity-cucumber doesn't do anything with mirrors yet.
Because of this I have two cases where I need Meteor to launch in a specific way.
1) On the CI server I need for JUST the tests to run then exit (hopefully with the correct exit code).
2) On the production server I need Meteor to skip all tests and just launch.
Is this currently possible with Meteor command line arguments? I'm contemplating making demeteorize a part of the process, and then use standard node.js testing frameworks.
To run velocity tests and then exit, you can allegedly run meteor with the --test option:
meteor run --test
This isn't working for me, but that's what the documentation says it is supposed to do.
To disable velocity tests, run meteor with the environment variable VELOCITY set to 0. This will skip setting up the mirror, remove the red/green dot, etc.:
VELOCITY=0 meteor run
I've moved my grunt job into Bamboo and everything works great except for the dust compiler. All of my other tasks in my gruntfile can be targeted from the bamboo task and they work. The dustc task gives this error when run: Fatal error: Error: not found: dustc.
I've manually run the dustc task on the build machine's command prompt every way I know how and it works. I even copied the command from the Bamboo build log - the one it uses to execute the grunt task - and it works just fine.
I just can't get it to work when I run the build from within Bamboo.
Any ideas would be greatly appreciated.
Thanks
This turned out to be a permissions/visibility issue.
Evidently system users (or at least the one which was running my build service) don't have access to the system environment variables in Windows. Learn something new every day!
I created a user to run the service (which I probably should have done in the first place) and that non-system user was able to see the correct PATH settings.
This took care of the problem.