I want to create a hudson job, that takes an id as a parameter. And use that id to calculate the svn-repo path.
Where I work you have a svn path for every issue that you resolve. And then all the issues are joined into a single svn-path.
What I want to do is to run static code analysis on the partial issues.
So I think maybe having an Ant build.xml that I use for every issue, then, parametrize the job with the issue id.
I have tried to achieve that but the svn path doesn't replace the parameter.
I have tried with #issueId, %issueId%, ${issueId} and ${env.issueId} without success.
Jump error like:
Location 'http://svn-path:8181/svn/devSet/issues/${env.chuid}' does not exist
Checking out a fresh workspace because C:\Documents and Settings\dnoseda\.hudson\jobs\test\workspace\${env.chuid} doesn't exist
Checking out http://svn-path:8181/svn/devSet/issues/${env.chuid}
ERROR: Failed to check out http://svn-path:8181/svn/devSet/issues/${env.chuid}
org.tmatesoft.svn.core.SVNException: svn: '/svn/!svn/bc/46190/devSet/issues/$%7Benv.chuid%7D' path not found: 404 Not Found (http://svn-path:8181)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at
I am think that I can not do what I want.
Do you know how I can setup the correct configuration to achieve this matter?
Thanks for any help.
Edit
The section of the configurate job that I want to put this parameter is this:
<scm class="hudson.scm.SubversionSCM">
<locations>
<hudson.scm.SubversionSCM_-ModuleLocation>
<remote>http://svn-path:8181/svn/devSet/issues/${env.issueid}</remote>
</hudson.scm.SubversionSCM_-ModuleLocation>
</locations>
New Edit: Solved
My version of hudson it was the last (1.349), but the version of svn plugin it was 1.11, being the last the 1.13, and it work with ${issueId}
Thank for the anwsers
From the hudson wiki:
"The parameter are available as environment parameters. So e.g. a shell ($FOO, %FOO%) or Ant ( ${env.FOO} ) can access these values."
Your syntax doesn't match the one in the wiki.
I've setup a svn project that does the parameter substitution successfully. The syntax is indeed ${issueId} so I assume you are doing something wrong, or are using a very old version of Hudson. Could you update the question with the versions of Hudson and the subversion plugin that you are using?
<project>
<actions/>
<description></description>
<keepDependencies>false</keepDependencies>
<properties>
<hudson.model.ParametersDefinitionProperty>
<parameterDefinitions>
<hudson.model.StringParameterDefinition>
<name>issueId</name>
<description></description>
<defaultValue>none</defaultValue>
</hudson.model.StringParameterDefinition>
</parameterDefinitions>
</hudson.model.ParametersDefinitionProperty>
</properties>
<scm class="hudson.scm.SubversionSCM">
<locations>
<hudson.scm.SubversionSCM_-ModuleLocation>
<remote>https://svn.dev.java.net/svn/hudson/trunk/${issueId}</remote>
</hudson.scm.SubversionSCM_-ModuleLocation>
</locations>
<useUpdate>true</useUpdate>
<excludedRegions></excludedRegions>
<excludedUsers></excludedUsers>
<excludedRevprop></excludedRevprop>
</scm>
<canRoam>true</canRoam>
<disabled>false</disabled>
<triggers class="vector"/>
<concurrentBuild>false</concurrentBuild>
<builders/>
<publishers/>
<buildWrappers/>
</project>
Here is the build output. The checkout fails due to an authentication issue, but the parameter is successfully replaced:
Started by user anonymous
Building on master
Checking out a fresh workspace because C:\hudson\jobs\test-svn\workspace\${issueId} doesn't exist
Checking out https://svn.dev.java.net/svn/hudson/trunk/www
ERROR: Failed to check out https://svn.dev.java.net/svn/hudson/trunk/www
org.tmatesoft.svn.core.SVNCancelException: svn: No credential to try. Authentication failed
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getFirstAuthentication(DefaultSVNAuthenticationManager.java:168)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:534)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:273)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:261)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:178)
at org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482)
at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:851)
at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:893)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:791)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:615)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:541)
at hudson.FilePath.act(FilePath.java:676)
at hudson.FilePath.act(FilePath.java:660)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:534)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:482)
at hudson.model.AbstractProject.checkout(AbstractProject.java:898)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:400)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:349)
at hudson.model.Run.run(Run.java:1106)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:122)
Notifying upstream projects of job completion
Finished: FAILURE
In this comment, it is mentioned that they use the ${ISSUEID}, which is why I suggested it, but all other signs I see say this doesn't actually work.
Otherwise I would recommend not using the SCM plugin and doing the SVN operation in a build script step. This would allow you to use the parameters as env variables like $ISSUEID
Related
I have a maven project which I want to build on Jenkins. I am giving goal as
clean install -Desb_env=dev
I have mention esb_env in mule-app.properties file. Same command is working fine & picking up the value of esb_env in local machine.But same command is not working on jenkins. It gives error as
Property ESB_ENV could not be found
Like this there few more goal need to give, I could not proceed further. Don't know what is wrong with Jenkins.
I have checked path for repo as well.
Any help would be appreciated.
This is the way we are specifying parameter in mule-app.properties file. keeping it blank & providing value through command.
ESB_ENV=
secure.properties=key
key=
I tried to add custom jar into my project (to pom.xml). When I made an operation
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> -DartifactId=<myArtifactId> -Dversion=<myVersion> -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
I actually received an error: the specified file not exists. But the file is in the folder - that's the problem. How I can resolve this? Or how I can add custom jar without this step? I know about scope , but it's not working properly - maven variable ${basedir} cannot be used in systemPath.
Maven 3.3.9
UPDATE 1: Actually, now I find smth new: Maven doesn't like dots in groupId and version. After some tries I installed file, but it's wrong path, because instead of (e.g) org.my.local.file tree I received file in org_my_local_file folder in maven repo.
I did this many times and it worked as expected.
What do you exactly mean with :
Maven doesn't like dots in groupId and version.
What exception do you get ?
You get org_my_local_file because I think you exachanged '.' in the groupId against '_' ?
You find a good tutorial here where you can see how it is done correctly :
How to include custom library into maven local repository?
EDIT :
It looks like you are using windows. Especially powershell is known to cause problems. Have a look here, may be you have to escape some characters, there are some possible solutions :
install maven artifact
I encountered this issue when trying to initialize our base development environment. We use an Ant script to initialize Maven, our developer server and other tools and includes installing a few 3rd party jars into the local Maven repository. This error, "The specified file '<path>\true' not exists" was occurring when invoking Maven from within Ant 1.9.11.
I also used this answer to specify paths identified in the Ant script and set them in the batch script template before running the batch script.
Specifically, this answer offered a lot to get the batch script constructed: https://stackoverflow.com/a/36298099/2336934. Didn't take much:
<!-- generate the batch file -->
<tempfile property="temp.file" suffix=".properties" deleteonexit="true" destdir="${env.TEMP}" />
<echoproperties destfile="${temp.file}" />
<replaceregexp file="${temp.file}" match="([^=]*)=" replace="#\1#=" byline="true" />
<copy file="${basedir}/scripts/install-jars.template" tofile="${basedir}/scripts/install-jars.bat" />
<replace file="${basedir}/scripts/install-jars.bat" replacefilterfile="${temp.file}" />
<echo message="Running batch file for Maven setup" />
<exec executable="${basedir}/scripts/install-jars.bat" />
<delete file="${basedir}/scripts/install-jars.bat" deleteonexit="true" />
There weren't any issues with the parameters being passed, but this must be specified correctly. Running the command you're trying to execute in a script temporarily in a command window is useful to verify the command syntax and function before trying to embed in a script.
I even created a empty true file to satisfy the error which complained the file was not a valid POM file. Filling it with basic POM content led to another error. So reader beware, this business about "true not exists" is a Red Herring.
Moving the Maven install:install-file commands out to the batch file was the key to get past the issue. It also allowed me to specify the quotes in the command as " rather than " due to the commands originally being specified in the Ant script (xml).
I don't know if any of you do use the maven plugin jgitflow.
when running
clean jgitflow:release-start jgitflow:release-finish
on hudson, I get the following error:
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m5.1:release-start
(default-cli) on project test-git-release: Execution default-cli of goal
external.atlassian.jgitflow:jgitflow-maven-plugin:1.0-m5.1:release-start
failed: String index out of range: -6
My pom.xml looks as follows:
<plugin>
<groupid>external.atlassian.jgitflow</groupid>
<artifactid>jgitflow-maven-plugin</artifactid>
<version>1.0-m5.1</version>
<configuration>
<enablesshagent>true</enablesshagent>
<defaultoriginurl>URL</defaultoriginurl>
<autoversionsubmodules>true</autoversionsubmodules>
<nodeploy>true</nodeploy>
<pushreleases>true</pushreleases>
<flowinitcontext>
<versiontagprefix>V_</versiontagprefix>
</flowinitcontext>
</configuration>
</plugin>
On my local machine I am able to run this command successfully.
Apparently is a known bug: official bug report, for the same version you mentioned and same behavior (working fine locally but same exception on Jenkins/Hudson).
Note that the linked bug report above provides a workaround maybe worth to try:
The workaround is in Jenkins:
Additional Behaviours
=> checkout to specific local branch
Update
According to the comments exchanged, proposed solutions and effective resolutions, here is the historical log for future helps:
Following the suggested workaround above and setting the local branch to checkout from origin/develop, the following error was encountered:
error occurred during unpacking on the remote end: unpack-objects abnormal exit
Such an error was actually due to permissions on the concerned folder, as also suggested by other SO threads, here and here. However changing the permissions afterwards did not help.
The issue was finally solved by creating the .git repository on the server itself. Doing so gave the group of the folder the same permissions as the owner.
A little timesaver for all the folks working with GitLab and experiencing this problem:
GitLab's Runner works on a DETACHED HEAD, which causes JGitFlow's search for GIT refs to fail, resulting in exactly this error.
The solution is as it is for Jenkins: before performing the JGitFlow operation, make a checkout. For GitLab you can do this by adding a git checkout in the /script part of the respective pipeline your gitlab-ci.yml, for example:
sample-pipeline:
stage: release
script:
-git checkout -B master
-mvn --batch-mode jgitflow:release-start jgitflow:release-finish
Since JGitFlow automatically checks out the develop branch and does its magic from there, you can always check out the master beforehand, as it has no effect at all; its just important that its not a DETACHED HEAD when GitLab starts its search for refs.
I would like to use Maven to produce an artifact in zip format. To give you some background; my project includes an APS package (Application Packaging Standard, used to provision cloud applications on the Parallels platform). This package is a zip file that contains a combination of XML as well as PHP files. It is generated by an APS plugin from within Eclipse and its name always includes the version and release number of its contents.
What I am trying to do is generate a zip file with Maven that would be kind of a release candidate that will be eventually sent to customers and would include not only the actual APS package but also other files such as README, User Guide.pdf, etc;. I would like the name of this zip file to contain the version number of the version number of the APS package. Currently I can generate this manually by using something like "mvn -Dversion=1.2.3-4 package" but I would like to automate the process and ideally run this from Jenkins.
Basically, my strategy is to run a script that would extract the version number from the initial APS package, once that is done, my script can invoke Maven and can pass this parameter to it so it can generate the final zip with the proper version number. This is fine but again, I need to run this script manually and I am looking for an automated process.
My question is; is it possible to invoke this script from within Maven and use its return as a parameter to set the version name (or the name of the file that will be generated) at run time? As I mentioned, I would like eventually Jenkins to handle this. It can pick up the pom file but I am not sure how it could kind of "auto configure" itself to have the proper version number.
Thanks is advance.
From jenkins build you can use profile with ${BUILD_NUMBER}:
<profile>
<id>jenkins</id>
<build>
<finalName>${artifactId}-${version}-${BUILD_NUMBER}</finalName>
</build>
</profile>
Then run in jenkins:
clean install -Pjenkins
I use the SVN (or any source versioning system) version to identify the software builds.
By simply executing this
REVISION=`svn info | grep '^Revision:' | sed -e 's/^Revision: //'`
on the sourcers folder you get the right value in $REVISION, then you can use it for your maven build
mvn -Dversion=1.2.3-$REVISION package
easy and clean
I'm setting up Jenkins for the first time and running into an issue where Jenkins does not appear to even attempt to execute the Ant task I've specified.
I've defined my JDK and Ant installations under Manage Jenkins.
I've setup my Job to Invoke Ant using the Targets 'war-all'
Whether I force a build or wait for it to naturally execute after the next commit, there is nothing in the Build Console Output about attempting to execute the ant task.
Here is a sample Console Output:
Any ideas as to why it might not be executing would be appreciated. Also tips on how I can find more logging from Jenkins which might provide clues as to why it is not executing would be helpful. I'm not sure what Logger I might specify or even then where the logging information is written on the file system.
The problem was that I was selecting "Build multi-configuration project" as the type of my job. When I select "Build a free-style software project" as my job type the Ant task will execute after the SVN update.
Looks like your svn doesn't see any changes and therefor is not re-building the module.
Try deleting the workspace and re-trigger the build, or change the check-out strategy to 'Always check out a fresh copy'.
I faced the same problem when upgraded to 1.417 from 1.413.
The combobox "Ant version" disappeared from "Invoke ant" build step. It should be here.
I just downgraded to 1.413 and continue to work.
So, the answer is - you should specify "Ant version" in project settings. But you cannot do it in 1.417.
It seems like Jenkins doesn't like when you create a job before configuring JDK. If that happens, job will never work properly. So, for me the solution was:
Delete job.
Configure JDK
Re-create job.
Probably the same problem may arise when job's JDK is deleted.
In my case,ant default target was not being picked up from build.xml so I had to explicitly mention the target in jenkins option.
I resolved this by changing the jdk to default and then again switched to what was set earlier.This is a workaround but not sure how this resolved.