I'm looking at coming up with a release process using the sbt release plugin, but I am getting an error when I try to commit to SVN as a release step.
svn: Commit failed (details follow):
svn: '/tmp/checkout/svn-test/commit' is not under version control
"/tmp/checkout/svn-test/" is the correct path to my project. I suspect I'm doing something wrong when I define the ReleaseStep to commit to SVN:
My build.sbt release config is as follows:
lazy val execScript = taskKey[Unit]("Commit to Subversion")
execScript := {
"svn commit -m 'test commit from release plugin'" !
}
val commitToSVN = () => ReleaseStep(
action = releaseStepTask(execScript)
)
releaseProcess := Seq[ReleaseStep](
ReleaseTransformations.checkSnapshotDependencies,
ReleaseTransformations.inquireVersions,
ReleaseTransformations.setReleaseVersion,
commitToSVN()
)
Any help would be really appreciated. Thanks
The problem appears to be the use of shell syntax, namely the use of single quotes, with !. As you have it, it thinks that 'test and commit and from and release and plugin' are all separate arguments.
The Java Process stuff, which Scala methods like ! are just thin wrappers for, don't run the process using a shell, and therefore shell syntax doesn't apply.
It should work if you do Seq("svn", "commit", "-m", ...) instead. Passing the arguments separately means you won't need single quotes to delimit arguments.
Related
My gitlab CI pipeline is setup to run maven tests from a docker image created from my maven project.
I have tested the pipeline on my master branch and it worked fine and ran the test.
However I have created a new feature branch and now running the pipeline yet again, however I now get this error
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: getting tag for destination: repository can only contain the runes `abcdefghijklmnopqrstuvwxyz0123456789_-./`: it2901/cs344-maven:feature/produce-allocation-pdf
ERROR: Job failed: command terminated with exit code 1
I can't seem to pinpoint the problem at all. I have also pushed the tag: tut3 to the feature branch as well.
Here is my .gitlab-ci.yml: https://controlc.com/7a94a00f
Based on what you shared, you have this configured:
VERSIONLABELMETHOD: "tut3" # options: "","LastVersionTagInGit"
It should be either:
VERSIONLABELMETHOD: ""
or
VERSIONLABELMETHOD: "LastVersionTagInGit"
or
VERSIONLABELMETHOD: "OnlyIfThisCommitHasVersion"
When you specify "tut3", the script takes it as if it was "" (empty string). Assuming you didn't define $VERSIONLABEL anywhere $ADDITIONALTAGLIST will also be empty.
And later in the code you can see that this gets executed:
if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then ADDITIONALTAGLIST="$ADDITIONALTAGLIST latest"; fi
Assuming $CI_DEFAULT_BRANCH is set to master if you use a separate branch mybranch the code above won't get executed so it's likely that the Kaniko command line doesn't have any a neither a valid $FORMATTEDTAGLIST or $IMAGE_LABELS.
You can debug by seeing their output on the script which is happening at the end before calling Kaniko:
...
echo $FORMATTEDTAGLIST
echo $IMAGE_LABELS
mkdir -p /kaniko/.docker
...
A hack would be to override $CI_DEFAULT_BRANCH with your custom branch.
✌️
I'm hunting a fun little bug in a tiny reprocessing test: reprocessing01.
The project builds just fine until I make a change and trigger refmt via vscode, and then the project will no longer compile.
Here's the code that compiles and runs just fine for me before making any changes.
open Reprocessing;
type stateT = {
image: imageT,
};
let setup = (env) => {
Env.size(~width=800, ~height=600, env);
let image = Draw.loadImage(
~filename="assets/Wave_pattern_by_inkelv1122_on_flickr_800w.jpg",
~isPixel=false, env);
{
image: image
}
};
let draw = ({image} as state, env) => {
Draw.background(Constants.white, env);
Draw.image(
image,
~pos=(0,0),
~width=Env.width(env),
~height=Env.height(env),
env
);
state
};
run(~setup, ~draw, ());
If I open the project in vscode, make a change such as adding let myvar = 42; at the top, and save to trigger refmt, that introduces this error:
/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/bsc.exe -pp "/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/refmt3.exe --print binary" -bs-super-errors -w -30-40+6+7+27+32..39+44+45+101 -bs-D BSB_BACKEND="bytecode" -nostdlib -I '/Users/myer/dev/react/reasonml-playground/reprocessing01/node_modules/bs-platform/lib/ocaml' -no-alias-deps -color always -c -o src/index.mlast -bs-syntax-only -bs-simple-binary-ast -bs-binary-ast -impl /Users/myer/dev/react/reasonml-playground/reprocessing01/src/index.re
File "/Users/myer/dev/react/reasonml-playground/reprocessing01/src/index.re", line 12, characters 4-5:
Error: 2817: <UNKNOWN SYNTAX ERROR>
The line in question is the last one of this code block:
Draw.loadImage(
~filename="assets/Wave_pattern_by_inkelv1122_on_flickr_800w.jpg",
~isPixel=false,
env,
);
After this, the only way out is to revert the code to before the changes introduced by refmt.
I suspect that my version of refmt is out of sync with the one required by bsb-native#2.1.1, but I'm not sure which one to install. I have:
$ refmt --version
Reason 3.0.0 # bee43b0
Is there a table that shows compatible versions between reason-cli and bs-platform?
Are there other ways I should investigate this issue or other potential root causes of this behavior?
UPDATE:
I was able to upgrade bsb-native to the master branch and it worked when building to native until I added some more code in reprocessing02
this issue is because bsb-native#2.1.1 comes with an old version of refmt (pre version 3) which can't read the code that your global refmt outputs (most likely because of the trailing commas). I'm working on making a new release 3.2.0 on all platforms, which comes with the latest refmt. If you're on OSX you can try it by just changing your dep to bsansouci/bsb-native#3.2.0, nuking node_modules and reinstalling.
Sorry for the inconvenience. I'm planning on making my release cycle tighly coupled with bsb's release cycle.
During the sbt build of my scala program i write the current sha1 hash to a file so i can use it easily from the application. This is how it looks like in my build.sbt file:
val dummy = {
val sha1 = Process("git rev-parse HEAD").lines.head
IO.write(file("conf/version.conf"), s"""sha1="$sha1"""")
}
The problem ist that now the build has the dependency that git command line has to be installed, otherwise it will fail since it cannot execute the git command.
Is it possible in sbt to ignore an error that occurs during the build and somehow just take "unknown" as the sha1 hash? The sbt docs say something about "failures" http://www.scala-sbt.org/0.13.5/docs/Detailed-Topics/Tasks.html but i am not sure if this can be applied to my problem.
sbt files are normal Scala files in most regards. Simply assign to sha1 the result of a try / catch expression:
val sha1 = try {
Process("git rev-parse HEAD").lines.head
} catch { case e: NonFatal => "unknown" }
IO.write(file("conf/version.conf"), s"""sha1="$sha1"""")
I have a Scala script that looks something like:
#!/bin/sh
PATH=${SCALA_HOME}:${PATH}
exec scala "$0" "$#"
!#
Console.println("Hello, world!")
Is there some way in Gradle to set the version of Scala to be used, have it implicitly set SCALA_HOME, and execute the script?
There is no built-in feature for this. The way to tackle this is to declare two tasks: A Copy task that downloads the Scala distribution and unpacks it to a local directory, and an Exec task that sets the SCALA_HOME environment variable to the copy task's output directory and executes your script.
Here is an example of executing Scala from Gradle. It is a nascent attempt to build a plugin using Scalafmt. Of note is how nasty it is to use static values.
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.geirsson:scalafmt-core_2.11:0.4.2'
}
}
task scalafmt << {
String target = "object FormatMe { List(Split(Space, 0).withPolicy(SingleLineBlock(close)), Split(Newline, 1).withPolicy{ case Decision(t#FormatToken(_, `close`, _), s) => Decision(t, List(Split(Newline, 0)))}.withIndent(2, close, Right)) }"
def config = org.scalafmt.config.ScalafmtConfig$.MODULE$.default
def range = scala.collection.immutable.Set$EmptySet$.MODULE$
println org.scalafmt.Scalafmt.format(target, config, range).formattedCode()
}
I know this is not quite on topic but I couldn't find anywhere else to put this and I hope it is of some value to people who ended up here for the same reason I did.
Gradle has an Exec task in which you can set the environment to be passed to the new process. You could pass SCALA_HOME through that.
I'm using sbt-s3 to upload my uberjar artifacts to S3 for deployment. What I need now is for a developer for be able to chose whether they're pushing to staging or production.
sbt-s3 looks something like this,
mappings in upload <<= (name, version, scalaBinaryVersion) map { (name, version, scalaBinaryVersion) =>
Seq(new java.io.File("target/scala-%s/%s.jar" format(scalaBinaryVersion, name)) -> ("%s.jar" format name)) }
Say I wanted to prefix %s.jar with a string like "staging" or "production" depending on how a user called SBT (it seems silly to have them edit Build.scala every time they want to push). For example: sbt s3Upload goes to staging and sbt production:s3Upload or sbt production s3Upload would go to production.
I'm having trouble understanding scopes and how I can use them to solve this problem. I can't just make a setting and hardcore S3Prefix in Production because then they can't push to staging. I didn't have any luck making a production task that overrides a default of "staging" to be "production" for following tasks, either.
Thoughts?
One possible solution might be to use input tasks for that, this is a simple task definition from the the sbt documentation:
demo := {
// get the result of parsing
val args: Seq[String] = spaceDelimited("<arg>").parsed
// Here, we also use the value of the `scalaVersion` setting
println("The current Scala version is " + scalaVersion.value)
println("The arguments to demo were:")
args foreach println
}
Depedending on the argument you can then push to staging or production.
I think there could be a more elegant solution with configurations, but I didn't do that before.