We have recently migrated our multimodule(each module with a pom.xml) repository from SVN to GIT.SCM connection in all pom.xml files updated from svn to git.
When i am trying to create a branch from git repository using maven release plugin it fails with the below error
"Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5:branch (default-cli) on project intgr: An error is occurred in the checkin process: Exception while executing SCM command. Error while executing command. Error while executing process. Cannot run program "/bin/sh" (in directory "/u01/remote-agent-home/xml-data/build-dir/IN-CDBFG-JOB1/mahirepository"): error=7, Argument list too long -> [Help 1]"
On examining logs i understand below command generated this error.
"[INFO] Checking in modified POMs... [INFO] Executing: /bin/sh -c cd /u01/remote-agent-home/xml-data/build-dir/IN-CDBFG-JOB1/mahirepository && git add -- intgr-parent/pom.xml archetypes/pom.xml and 1000 more pom files "
Is there a way i can workaround or fix this issue?
Maven version : Apache Maven 3.0.4
JDK version : 1.7.0_01
Maven command :
mvn -s ./settingsBamboo.xml --batch-mode release:branch -DbranchName=${bamboo.branchname} -DupdateWorkingCopyVersions=true -DsuppressCommitBeforeBranch=true -DautoVersionSubmodules=true -DremoteTagging=false -DupdateBranchVersions=false -X
I am currently facing this problem as well, but I got a bit further on this.
The issue has nothing to do with Java or Maven, it's a Linux limitation.
using getconfig MAX_ARGS you can find the max amount of bytes you can use as arguments.
Large maven commands can easily go beyond this, and the amount of bytes differs largely per distro.
Check the amount of bytes you can use, and try to get your command below that.
You could for example move into the build dir first, and then run the command relative.
Another solution would be to increase the amount of usable space, but I have so far not gotten that working.
If anyone does or you have fixed this yourself, let me know.
Related
I'm building maven project on Jenkins (version 2.263.4, not the last but not so far).
It's a git project with pipeline configuration and webhook from bitbucket when push is done on the project.
So when a developper create a branch and another one a pull request, i have 2 build in parallel. Domain test running in about 45min.
And sometimes(not always), i have this error :
Command was /bin/sh -c cd /jenkins/workspace/a-hub_test-plantage-jenkins_PR-1/server/project-core/project-core-domain && /jenkins/tools/hudson.model.JDK/jdk11/jdk-11.0.2+9/bin/java -Xmx1500M -jar /jenkins/workspace/a-hub_test-plantage-jenkins_PR-1/server/project-core/project-core-domain/target/surefire/surefirebooter15630998754365374145.jar /jenkins/workspace/a-hub_test-plantage-jenkins_PR-1/server/project-core/project-core-domain/target/surefire 2021-05-04T12-39-54_622-jvmRun1 surefire5846464826560071036tmp surefire_13691263758446667285tmp
Error occurred in starting fork, check output in log
14:46:13 [ERROR] Process Exit Code: 1
14:46:13 [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669)
14:46:13 [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
14:46:13 [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
If i re run the buildin error, it work.
I'm using maven-surefire 2.22.2.
I try to configure it following many thread on stackoverfow, but nothgin work. I try with forkMode none or something else, it work but i loose coverage because jaccoco need fork to work. So i'm stuck.
What can i do to help me to debug this problem?
I don't understand why build failed when another one is building because for me Jenkins work on different working folder, no? so why the problem appear when i'have multiple build in parallel?
thanks for help
I find an hs_err_pid.log in jenkins near source code and i see out of memory! i see that my test was launch with -Xmx1500Mo and problem occured when i launched multiple branch/pr, so jenkins use all of the memory and failed all build during fork...i decrease -Xmx and all seems to work.
I'm trying to install Datomic on a Windows 10 computer, following the official instructions.
I downloaded and unzipped the dev tools as instructed.
I cannot, however, run the install script because it is a bash script.
I opened the script and discovered it requires maven, so I installed maven and tried to run the commands manually.
echo 'Installing: com.cognitect/rebl {:mvn/version "0.9.242"}'
mvn -q org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file -Dfile=rebl-0.9.242/rebl-0.9.242.jar
echo 'Installing: com.datomic/dev-local {:mvn/version "0.9.232"}'
mvn -q org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file -Dfile=dev-local-0.9.232/dev-local-0.9.232.jar
At first this errored with
The goal you specified requires a project to execute but there is no POM in this directory
So I figured out how to create a maven pom.xml.
Then it errors
[ERROR] The specified file 'C:\workspaces\clj-recipe\rebl-0' not exists
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file (default-cli) on project clj-recipe: The specified file 'C:\workspaces\clj-recipe\rebl-0' not exists
Is dev-local not intended for windows?
Update
I did get the maven scripts to run. I created my own install.ps1 in the dev tool directory, which kept paths the same, and quoted the file paths.
# expects to be run from the project (pom.xml) directory, but in a script file in the same directory as the original install script
echo 'Installing: com.cognitect/rebl {:mvn/version "0.9.242"}'
mvn -q org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file -Dfile="rebl-0.9.242/rebl-0.9.242.jar"
echo 'Installing: com.datomic/dev-local {:mvn/version "0.9.232"}'
mvn -q org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install-file -Dfile="dev-local-0.9.232/dev-local-0.9.232.jar"
I still can't get dev-local to run though. There appears to be no changes to the pom.xml.
I start up a repl for the current lein project and run
(require '[datomic.client.api :as d])
(def client (d/client {:server-type :dev-local
:system "dev"}))
Getting the error No such namespace: d.
My guess is that I don't understand how deps.edn works... Right now I have a single deps.edn under C:/Users/[username here]/documents/.clojure/deps.edn
{
:mvn/repos {"cognitect-dev-tools"
{:url "https://dev-tools.cognitect.com/maven/releases/"}}
:deps
{com.datomic/dev-local {:mvn/version "0.9.225"}}
}
There were two key issues here
The install script is not necessary with leiningen (and is not written for windows)
If you want to use a maven-based approach, then use the install script. Be warned that you need maven installed.
The install script can be tweaked for windows by changing as shown above (quote paths, remove the cd, make it a ps1 file)
The deps.edn, maven, and leiningen paths are not compatible. I must configure the dependency using leiningen to use it in my lein-based project
Configuring for lein is fairly simple
add a repositories configuration section
add a package dependency
(defproject ;;...
:dependencies [
;;...
[com.datomic/dev-local "0.9.225"]
]
:repositories [
["cognitect-dev-tools" {:url "https://dev-tools.cognitect.com/maven/releases/"
:username :env/datomic_username
:password :env/datomic_password}]]
;;...
)
Note that the credentials have to be supplied to the lein project. This can be done with
environment variables as shown above (specify the name as :env/var-name-here)
or using an encrypted password field
or use a profile
Until recently everything worked fine with our build process in Jenkins. We got a quite big project with many modules and a complicated dependency structure.
Suddenly, the build fails with error messages like the following:
Failed to execute goal certain-plugin:109:certainEar(certainEar)
on project app: certain plugin: Can't explode ear file
'app-SNAPSHOT.ear': Error, directory can't be deleted
The maven command that gets executed in the build pipeline and results in the error message is the following:
mvn -B -U package -DskipTests
A temporary workaround is manually deleting the affected directory. Previously I had a similar problem with the deletion of an ear, there it was possible to exclude the affected ear from this build step as it was not required there. Afterwards I got the error message mentioned above.
Now I found a (kind of) final solution: Adding clean to the targets of the maven command:
mvn -B -U clean package -DskipTests
Now the building step works fine. But why the heck does this happen? Do you have any hints what could lead to this behavior? I'm quite clueless to say the least.
Somehow this could have something to do with the extraction of an ear out of our big app ear. Shortly after we finished this and merged it into our master branch those errors began to arise. As I was not involved in this work it's hard to track down what happened there exactly and what could lead to this behavior. In parallel I will investigate what the colleagues did there. Hints from you what the reasons could be will certainly help to track this down.
I found nothing similar to this error messages online that helped me in any way.
Your solution "mvn clean" indicates me that your job is executing on a jenkins workspace that contains the execution of the previous job. I would recommend to always start your job by clearing what's in the workspace. In freestyle job, under section Source Code Management you can add the behavior
Wipe out repository & force clone
in pipelines, you would use checkout step
checkout([$class: 'GitSCM',
extensions: scm.extensions + [[$class: 'WipeWorkspace']] + [[$class: 'PruneStaleBranch']],
userRemoteConfigs: [[
url: '<git_url>'
]]
])
there are other ways to clean a workspace in a pipeline like cleanWS and deleteDir. Do prefer the checkout WipeWorkspace plugin
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.
This happens for both: maven projects, and freestyle projects, when maven target is envoked, it tries to execute mvn using absolute path.
[MY-Job] $ tools/Maven/Jenkins_Private_Maven/bin/mvn -f cc/pom.xml -Ddeploy_env=xxx.dev.prv -Dbranch=dev -D-Dsmdist.target=/opt/builds -U clean test -DtestGroups=unit,delegate -Do verride:server=xxx.dev.prv
FATAL: command execution failed
java.io.IOException: Cannot run program "tools/Maven/Jenkins_Private_Maven/bin/mvn" (in directory "workspace/MY-Job"): java.io.IOException: error=2, No such file or directory
I can see that mvn is installed at user's home :
/home/jenkins/tools/Maven/Jenkins_Private_Maven/bin/mvn
but it's trying to run it from the workspace:
/home/jenkins/workspace/MY-Job/tools/Maven/Jenkins_Private_Maven/bin/mvn
Add the default maven installation under (Jenkins -> configuration)
Goto the failing job and make sure you choose the default maven installation from dropdown
Run the job. Success!
Are you sure you have set up Maven in Jenkins -> configuration like this
I have hunch you have a accidental **"."** current directory reference somewhere in your maven set up.
This looks like an auto installed Maven by Jenkins. In which case the previous answers are not correct.
It would seem in this occasion that you have not specified a "remote fs root" for your slave in the salve setup - later versions of Jenkins flag not setting this up correctly as an error.
in Jenkins 2.43:
Manage Jenkins -> Global Tool Configuration -> Maven