I want to take a build number passed as an argument when running maven and inject it into some HTML files.
To give an example:
Build command would be "mvn -DBUILdNUM=1"
I would like to take this and inject it into an html file (in a comment hopefully) replacing something like ${builnum}.
I would also like to use something similar for cache busting my js scripts.
You can use Maven Resource Filtering for this.
Related
I would like to change the default output directory (target) to something else. I am using the parallel runner and I expected the command line options/mvn options to overwrite what is specified in the Runner.parallel() call.
What did not work:
Run mvn clean test -Dkarate.options="--output=artifacts"
Configure output directories as specified for the surefire-report-plugin
Configure reportDirectory for the surefire-plugin
What did work (but without maven and without parallel execution):
java -jar karate.jar ... --output=artifacts"
What am I missing here?
Not sure if I fully understand, but pretty sure this is not supported unless you are asking to customize the folder in which the json / xml reports go to - and that is the last argument to Runner.parallel().
Since this is something we've never got as a request, you may want to contribute a PR.
I have a PhoneGap project that use custom MSBuild scripts running in TeamCity as a CI build.
What I want to add now is zip and send the project files with the PhoneGap REST API on each check-in.
But before sending the files I need to make a few changes inside the head node of the index.html since there are URIs to a service that differs from DEBUG, TEST, RELEASE environments.
Is there any way I could use something like #ifdef with build properties on a .html file or is there perhaps an even better way of solving this scenario using MsBuild/TeamCity?
You could setup custom tokens (like "##replace this##") and then simply update HTML content using TeamCity PowerShell build step.
I'm using Maven 3.0.3. I'm running the "mvn test" command, in which my test files are in the standard place (src/test/java). Where do I put properties files so that they get picked up by Java's "getResourceAsStream" method? I tried placing my properties files in both src/main/resources and src/test/resources, but my JUnit test isn't finding them. Here's how I want to load the tests ...
final InputStream in = getClass().getResourceAsStream("my.properties");
but this returns null. I'm using JUnit 4.8. Any ideas? Thanks, - Dave
It works for me if I use getClass().getResourceAsStream("/my.properties").
Without the / prefix, the path is relative to your class's package, so you'd have to put the properties file in a path like src/test/resources/com/mycompany/mypackage/my.properties.
I have a Hudson job that runs a maven goal. Before this maven goal is executed I have added a step to run before the build starts, it is a shell script that obtains the version number that I want to use in the 'Goals and options' field.
So in my job configuration, under Build Environment I have checked the Configure M2 Extra Build Steps box and added a shell script before the build. The script looks like this:
export RELEASE={command to extract release version}
echo $RELEASE
And then under the Build section I point to my 'root pom'. In the Goals and options I then want to be able to do something like this:
-Dbuild.release.version=${RELEASE} deploy
Where build.release.version is a maven property referenced in the POM. However since the shell doesn't seem to make its variables global it doesn't work. Any ideas?
The only one I have is to install the Envfile plugin and get the shell script to write out the RELEASE property to a file and then get the plugin to read the file, but the order in which everything is run may cause problems and it seems like there must be simpler way...is there?
Thanks in advance.
I recently wanted to do the same, but AFAIK it's not possible to export values from a pre-build shell to the job environment. If there is a Hudson Plugin for this I've missed it.
What did work, however, was a setup similar to what you were suggesting: having the pre-build shell script write the desired value(s) to a property-file in the workspace, and then using the Parametrized Trigger Plugin to trigger another job that actually does the work (in your case, invoke the Maven job). The plugin can be configured to read the parameters it passes from the property file. So the first job has just the shell script and the post-build triggers, and the second one does the actual work, having the correct parameters available as environment variables.
General idea of the shell script:
echo "foo=bar
baz=`somecmd`" > build.properties
And for your Goals and options, something like:
-Dbuild.release.version=${foo} deploy
Granted, this isn't as elegant as one might want but worked really well for us, since our build was broken into several jobs to begin with, and we can actually reuse the other jobs that the first one triggers (that is, invoke them with different parameters).
When you say it doesn't work, do you mean that your RELEASE variable is not passed to the maven command? I believe the problem is that by default, each line of the shell script is executed separately, so environment variables get lost.
If you want the entire shell script to execute as if it was one script file, make the first line:
#!/bin/sh
I think this is described in the Help information alongside the shell script build step (and if I'm wrong, that's a good place to look for the right syntax).
I'm using PMEase QuickBuild to perform automated builds of our Maven2 projects and a nightly sanity test to ensure nothing is broken.
The test needs to untar packages which are created by the automated Maven2 projects. The problem is that the package names change frequently due to project versions being incremented all the time.
Does anyone know how I can configure QuickBuild to pick up the version (ideally from the POM file of the individual components), if this is possible at all?
I don't know if this is an option for you but it looks like you can do it the other way around. Quoting Build with Maven:
Control build version
If you want to control the build
version from QuickBuild side, please
follow below steps:
Change the POM file and define the project version as
${buildVersion}. Do not forget to
commit the file into your SCM after
change.
Define a build property like below when define the Maven build
step:
buildVersion=${build.version}
There are maybe other options but I must admit that my knowledge (zero) of QuickBuild is very limited
I created a work around to this issue by having QuickBuild execute a shell script which did the untarring by using wildcards, similar to the following (to avoid computing the exact version):
tar xzf filename-*.tar.gz
I couldn't figure out how to do this in QuickBuild, so I offloaded the work to the shell script.