These are chat archives for sbt/sbt

24th
Jun 2016
RonakP
@ronak167
Jun 24 2016 06:22

How to pass command line input in Gatling using Scala script?

I want that user can input 'Count, repeatCount, testServerUrl and definitionId' from command line while executing from Gatling. Can anybody please help me?

import io.gatling.core.Predef._
import io.gatling.http.Predef._
import scala.concurrent.duration._

class TestCLI extends Simulation {

    val count = 50
    val wait = 2
    val repeatCount = 2
    val testServerUrl = "Some url" 

    val scn = scenario("testabcd")
        .repeat (repeatCount ) {
            exec(http("asdfg")
            .post("""/xyzapi""")
            .headers(headers_0)
            .body(StringBody("""{"definitionId":10200121}"""))) // I also want to get this value dynamic from CLI and put here
            .pause(wait) 
        }                   

    setUp(scn.inject(atOnceUsers(count))).protocols(httpProtocol)

}

Your help will be much appreciated. TIA.

Mike Mazur
@mikem
Jun 24 2016 06:44

Hi, I’m having trouble with sbt test not applying the test config of a dependent project. I have project A, which has an application.conf in src/main/resources and src/test/resources. When I run tests in project A, the test configuration is applied. I have a project B in a separate directory which has a dependency declared on project A. When I run tests from project B, the settings in project A’s src/test/resources/application.conf file are not applied.

Any ideas on how to fix this?

Mike Mazur
@mikem
Jun 24 2016 07:12
It looks like the issue is caused by the order of the entries in the classpath. When I run the tests in project A, I see this order in the classpath: …;…/projectA/target/scala-2.11/test-classes/;…/projectA/target/scala-2.11/classes/;… but when I run the tests in project B, the order of those two directories is reversed.
Dale Wijnand
@dwijnand
Jun 24 2016 07:19
really? that's interesting. I would've thought that the test classes of projectA wouldn't have been on the classpath of projectB
Mike Mazur
@mikem
Jun 24 2016 07:25
@dwijnand our dependency includes "compile->compile;test->test” so the test classes are included
Dale Wijnand
@dwijnand
Jun 24 2016 07:35
oh.. then yes :)
try "test->test;compile->compile"?
Mike Mazur
@mikem
Jun 24 2016 07:37
Yep, tried that, no dice
Dale Wijnand
@dwijnand
Jun 24 2016 08:36
interesting. what's the order betwen projectA and projectB when running tests in projectB?
Richard Gomes
@frgomes
Jun 24 2016 09:31
Is there a way to tell SBT (inside SBT, not at bash level!) that I need STDOUT written onto STDERR?
My use case is a Scala script which writes results onto stdout (as any script or unix command would do!)... but SBT writes informational messages or complains about waiting for the lock file, etc... which also gets written to stdout. The end result is that the output is useless in a pipeline, since the next step does not understand what those strange messages are about.
Richard Gomes
@frgomes
Jun 24 2016 11:03
Answering my own question...
  outputStrategy := {
    val ofile = java.io.File.createTempFile("my-scala-script_", ".log")
    ofile.deleteOnExit
    Some(CustomOutput(new java.io.FileOutputStream(ofile)))
  }
OK. Now I need to do the same with stderr, it seems :-(
Richard Gomes
@frgomes
Jun 24 2016 11:28
Guess what would be the next query here... how can I do that????
Matthew de Detrich
@mdedetrich
Jun 24 2016 11:50
I am getting “unable to reparse” warnings everywhere on SNAPSHOTS
Does anyone have any idea what causes this?
eugene yokota
@eed3si9n
Jun 24 2016 11:52
@mdedetrich SNAPSHOT tries to read the publication date by reparsing the module descriptor out of the internet
Matthew de Detrich
@mdedetrich
Jun 24 2016 11:52
Oh, these snapshots are in a private repo, would that explain it?
Or are they being published incorrectly
eugene yokota
@eed3si9n
Jun 24 2016 11:53
generally my recommendation is to avoid using SNAPSHOT with sbt for anything serious
it's better to put Git sha or something in a "snapshot" repository
and clean it out somehow
Matthew de Detrich
@mdedetrich
Jun 24 2016 11:54
SNAPSHOT does have its uses, just wanted to know if its anything really serious
Is there a way to supress the warning?
eugene yokota
@eed3si9n
Jun 24 2016 11:55
as long as you don't have SNAPSHOT published locally and remotely, it should be ok
one way to supress it is use updateOptions := updateOptions.value.withLatestSnapshots(false)
Matthew de Detrich
@mdedetrich
Jun 24 2016 11:56
Oh yeah, its never published locally
eugene yokota
@eed3si9n
Jun 24 2016 11:57
you can't always guarantee that all developers will never publish SNAPSHOT locally so you could get into a situation where someone reports a bug and it only happens on that person's machine
so my recommendation generally is to only use SNAPSHOT for local testing
Matthew de Detrich
@mdedetrich
Jun 24 2016 11:58
Yeah I am aware of that, this is only being done for prototyping (then we will do proper releasing)
Chris Hodapp
@clhodapp
Jun 24 2016 20:09
Hey. I’m hoping to gain a deep understanding of how recursive build / project loading works in sbt. The outward behavior makes it clear that e.g. *.sbt in /project/ must be fully compiled, loaded, and interpreted before *.sbt at the toplevel of the build are compiled and loaded, because you can declare library dependencies in those lower-level files and have them available on the classpath at the top-level. What I’m actually hoping for is that there exists some undiscovered (and possibly extremely hacky) pattern that can be implemented to allow plugins to affect the list of top-level projects.
OlegYch
@OlegYch
Jun 24 2016 20:10
sbt.Build#projects
nothing hacky about it
Chris Hodapp
@clhodapp
Jun 24 2016 20:11
Well, except that it’s deprecated and fully removed in sbt 1.0
and not accessible from AutoPlugins
OlegYch
@OlegYch
Jun 24 2016 20:11
well
Chris Hodapp
@clhodapp
Jun 24 2016 20:12
heheh
OlegYch
@OlegYch
Jun 24 2016 20:12
tbh i think that was the worst decision
Chris Hodapp
@clhodapp
Jun 24 2016 20:12
Yeah, definitely it’s contentious
OlegYch
@OlegYch
Jun 24 2016 20:12
so far i can't grasp autoplugins either
Chris Hodapp
@clhodapp
Jun 24 2016 20:13
In my personal opinion, AutoPlugins are way better than what came before, but a lot of that value only comes when the community fully accepts and implements them
OlegYch
@OlegYch
Jun 24 2016 20:15
i just spent a couple of hours figuring out how to disable an autoplugin conditionally
and didnt
Chris Hodapp
@clhodapp
Jun 24 2016 20:15
what do you mean conditionally?
OlegYch
@OlegYch
Jun 24 2016 20:15
well some plugins conflict with others
Chris Hodapp
@clhodapp
Jun 24 2016 20:16
Yes! so that is a major gap in the autoplugin api
OlegYch
@OlegYch
Jun 24 2016 20:16
some dont even make sense as a plugin for every project
looking at you, native-packager
Chris Hodapp
@clhodapp
Jun 24 2016 20:16
The fact that you can’t express conflicts
that’s a major issue
and the model actually does make it kinda difficult to fix that
b/c everything is statically typed, if you wanted to express a conflict with another plugin, you’d actually have to pull it onto the classpath
bleh
but autoplugins aren’t any worse about that
they’re actually better than what came before
OlegYch
@OlegYch
Jun 24 2016 20:17
the auto part is
worse
Chris Hodapp
@clhodapp
Jun 24 2016 20:18
You can explicitly disable a plugin on a per-project basis even if it chooses to graft itself on
OlegYch
@OlegYch
Jun 24 2016 20:18
that's a static decision though
Chris Hodapp
@clhodapp
Jun 24 2016 20:19
ah, but see, the thing is, the previous plugins were also auto in that sense, it was just so bad that the best practice became to ignore that part of the API
and punish users by making them always have to apply settings explicitly
OlegYch
@OlegYch
Jun 24 2016 20:19
i guess so
Dale Wijnand
@dwijnand
Jun 24 2016 20:20
@clhodapp A replacement for Build#projects will be there for 1.0.0
There's a couple of tickets and an oldish PR about it
OlegYch
@OlegYch
Jun 24 2016 20:22
does anything exists that allows to apply a bunch of settings based on other settings?
like settings += if (bla.value) thisPlugin else thatPlugin
Chris Hodapp
@clhodapp
Jun 24 2016 20:23
It can only be done in terms of applied plugins
that is
Dale Wijnand
@dwijnand
Jun 24 2016 20:23
Not that I know of
OlegYch
@OlegYch
Jun 24 2016 20:24
onLoad?
Chris Hodapp
@clhodapp
Jun 24 2016 20:24
you can say “if a project has plugin X applied, also apply plugin Y. If a project has plugin A applied, also apply plugin B"
at least in the high-level of the api. sbt is so programmable that there are always hacks ;)
OlegYch
@OlegYch
Jun 24 2016 20:24
couldn't figure out how to get current settings in onLoad the other day though..
state.get(setting.key) was empty..
Chris Hodapp
@clhodapp
Jun 24 2016 20:27
perhaps you needed to scope it more tightly? <key> in (<project>, Compile) or some such?
OlegYch
@OlegYch
Jun 24 2016 20:27
i think i tried that
didn't try getting from extracted project though
dunno..
i hope that Attributed/Setting/Settings/SettingKey api can be simplified
Dale Wijnand
@dwijnand
Jun 24 2016 20:31
perhaps not simplified, but explained and documented better
OlegYch
@OlegYch
Jun 24 2016 20:31
yes
no idea what's the difference between sbt.StateOps#get and sbt.Extracted#get is
Dale Wijnand
@dwijnand
Jun 24 2016 20:35
Me either.