When I developed with svnkit 1.8.12 and excuted the svnupload method,sometimes there appears such questions :
svn: E200030: Commit failed (details follow):
svn: E200030: Insert fails: unique index sqlite_autoindex_PRISTINE_1.
And my local workingcopy was locked and svn cleanup can unlocked it.I wonder how this question appears and how can I resolve it without changing my local enter image description hereworkingcopy.
svn commit failed
The goal folder that you wanted to check out from SVN had not been cleaned up because some processes might be using them even though you can delete them. We have experienced this problem for many times in our java program.
At present, what we could do is just restart the tomcat.
Related
I have a project with a gitlab CI for my school project for around 3 months now and never had an issue. But, yesterday morning when I wanted to commit my new code changes and push it to my Gitlab. This worked completely fine, however my CI keeps failing:
In text:
1 Running with gitlab-runner 13.9.0 (2ebc4dc4)
2 on
3 Preparing the "shell" executor
4 Using Shell executor...
6 Preparing environment
7 Running on
9 Getting source from Git repository
10 Fetching changes with git depth set to 50...
11 Reinitialized existing Git repository in
12 Checking out 437a9a83 as master...
13 error: bad signature 0x00000000
14 fatal: index file corrupt
16 Cleaning up file based variables
18 ERROR: Job failed: exit status 1
didn't notice my branch failed so I also merged this with
I was working in a separate branch and didn't notice my branch failed, so I also merged this with my main branch so main isn't working as well.
This is mentioned in gitlab-org/gitlab-runner issue 3290
The Git index file got corrupted causing the build to fail and the runner is not able to recover.
It should be able to handle this by deleting the index file and resetting the repo
As in "How to resolve “Error: bad index – Fatal: index file corrupt” when using Git"
See if the issue persists in a second GitLab pipeline, created for testing, in order to force a new clone of the same repository.
i am trying to install eclipse for Java development.
But after hitting install i get "installation failed with an error. Show log"
This is the log file:
ERROR: org.eclipse.equinox.p2.artifact.repository code=13 Retry another mirror
ERROR: org.eclipse.oomph.p2.core code=0 Repeated attemps to download http://mirrors.xmission.com/eclipse/oomph/drops/milestone/S20191105-074631-1.15.0-M2/plugins/org.eclipse.nebula.widgets.tablecombo_1.2.0.201910251134.jar from the same site
java.io.IOException: Repeated attemps to download http://mirrors.xmission.com/eclipse/oomph/drops/milestone/S20191105-074631-1.15.0-M2/plugins/org.eclipse.nebula.widgets.tablecombo_1.2.0.201910251134.jar from the same site
at org.eclipse.oomph.p2.internal.core.CachingTransport.download(CachingTransport.java:122)
at org.eclipse.oomph.p2.internal.core.CachingTransport.download(CachingTransport.java:255)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:720)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact(SimpleArtifactRepository.java:644)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:776)
at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.getArtifact(MirrorRequest.java:319)
at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.transferSingle(MirrorRequest.java:289)
at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.transfer(MirrorRequest.java:225)
at org.eclipse.equinox.internal.p2.artifact.repository.MirrorRequest.perform(MirrorRequest.java:155)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact(SimpleArtifactRepository.java:759)
at org.eclipse.equinox.internal.p2.artifact.repository.simple.DownloadJob.run(DownloadJob.java:64)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Maybe you have downloaded a corrupted artifact that now has been cached, and the installation won't run. Try by going under the .p2/org.eclipse.equinox.p2.core/cache path of your Eclipse installation path. You will probably find a zip, but without the extension. Try by deleting it, after doing a backup elsewhere.
Are you behind a corporate network? Maybe there is some kind of proxy blocking the host connection.
When I'm doing the "pull", I get the below error message:
Failure updating tracking ref refs/remotes/origin/5100_<Project_Name>:
Missing unknown <commit_id>
Checked network connection settings in Eclipse - it's fine. I did not
change my password recently.
As mentioned in this JGit thread:
I think we lack support for git pull --recurse-submodules
Check if the missing unknown commit id is one of a submodule.
That was requested in issue 488681 and resolved in issue 470318 with commit 06835f3 for JGit 4.9
So double-check what version of JGit you have in your Eclipse.
I created a new job for android new project on Jenkin. Whenever I run the job I got error java.io.ioexception error 13 permission denied. Jenkin says unable to run program gradlew. I know gradlew script need execution permissions according to the error explanation . I granted these and re run the jenkin job. I still get the same error. Jenkin revert the execution permission back after build. When I create new job from existing job and configured with old projects repository , it runs fine. when I configured with new project repository it raised permission issues. I played a lot with permission but no success. I also compared old and new project script file. There was few lines difference but it shouldn't be an issue. Any one can guide me what I am doing wrong.
Thanks
It is clearly a permission issue.
java.io.IOException: Cannot run program "<http://jenkins.gradlew"
error=13, Permission denied
Caused by: java.io.IOException: error=13, Permission denied
There are two solutions to resolve the gradlew permission issue.
Go to Jenkin Job configuration
Go to Build tab and check gradlew executable.
Jenkin will change the permission when you press build now. Keep in mind that these changes are uncommitted. The process works fine if your job is not a release job. If it is release job it creates another issue that I came across.
:workspace:app:checkCommitNeeded FAILED
:app:release FAILED
* What went wrong:
Execution failed for task ':workspace:app:checkCommitNeeded'.
> You have uncommitted files:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
M gradlew
So work around is
commit gradlew with executable bit set:
git update-index --chmod=+x gradlew
git commit
Then you will no longer need the jenkins setting to set it executable, which is the workaround causing the 2nd issue.
Hopefully it would save someone time because I spent hours for the work around.
I was using Github for source code management. It was fetching code there and was updating it every single time, so changing it to +x before submitting my Jenkins job didn't help.
In Linux the project is at /.jenkins/workspace/MyProjectName/SomeSubFolder/gradlew - and it was loosing +x evereytime a new job was submitted (to 644, I think).
The solution was to select the Make gradlew executable checkbox (in Build --> Use Gradle Wrapper) - it is 755 now, and is executing gradle tasks.
Are you using a jenkinsfile for your job configuration?
If so you need to add the permission change for gradlew there.
sh 'chmod 755 ./gradlew'
It sounds like your gradlew is being replaced each time with a version that doesn't have the execute permission set so you will need to do it as part of the jenkins job either via a script or the jenkinsfile.
I am getting an unexpected error when trying to build a project with Hudson. I have a valid account with which I can checkout to the machine on which Hudson is installed. I have updated from Hudson UI the authentication parameters to this account.
Has anyone else encountered this?
hudson.util.IOException2: revision check failed on https://SVN Location
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:157)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:99)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:504)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:621)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1095)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
at hudson.model.Run.run(Run.java:1280)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:139)
Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: OPTIONS of '/SVN Location': 403 Forbidden (https://SVN)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:610)
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.SVNLogClient.doLog(SVNLogClient.java:1016)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:891)
at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:823)
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:145)
... 10 more
I had this problem. And after spending a day researching ssl and http interactions, I discovered that it was in fact an authentication problem.
in jenkins v1.534
the (encrypted) credentials in
/opt/jenkins/jobs/JOBNAME/subversion.credentials
and
/opt/jenkins/hudson.scm.SubversionSCM.xml
Were out of date AND out of sync. And to make diagnosis more difficult they were cached, and overwritten every time I ran a job. So I had to restart the jenkins service every time I changed those files.
Did you use the correct URL for SVN. This is a common error when the capitalization is not correct. Maybe the URL is not SVN_Location but Svn_location