Re: Jenkins 2.277.1 Issue?
So, the https://github.com/jenkinsci/plugin-installation-manager-tool really saved my day. I went through the plugins directory and checked against the compatibility list, and upgraded all of the plugins with the Plugin Installation Manager Tool. And finally we are up-and-running again! fredag 2 april 2021 kl. 14:37:53 UTC+2 skrev xJom: > I have the same problem on one of my instances, but I also have the > problem that I cannot go back to previous version, because it destroys the > other instances. I think there is a compatibility issue for plugins, and if > you could go back, then update all your plugins according to the > compatility matrix here. > https://github.com/jenkinsci/jep/blob/master/jep/227/compatibility.adoc > For me, I think I need to try to upgrade the plugins manually... > > måndag 22 mars 2021 kl. 16:15:15 UTC+1 skrev eric@gmail.com: > >> Hi! Last week we took 2.277.1 when patching. I didn't see any issues >> until this morning when I tried to log on and got 403 No valid crumb was >> included in the request. I restarted the server a few times trying to fix >> it but never could get logged in. I did some research and found a thread >> telling me to make a global security setting change to proxy compatibility >> (even though I'm not proxied), but couldn't get to global security to try >> that. So I backed it out to 2.263.4, where we were before. It's working >> again, but I'm guessing the same thing will happen next time we apply >> patches. Is there a change with 277 that will make me have to change some >> setting or another? Thanks! > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/cf872f38-d840-4521-be24-0924ba627bcbn%40googlegroups.com.
Re: Jenkins 2.277.1 Issue?
I have the same problem on one of my instances, but I also have the problem that I cannot go back to previous version, because it destroys the other instances. I think there is a compatibility issue for plugins, and if you could go back, then update all your plugins according to the compatility matrix here. https://github.com/jenkinsci/jep/blob/master/jep/227/compatibility.adoc For me, I think I need to try to upgrade the plugins manually... måndag 22 mars 2021 kl. 16:15:15 UTC+1 skrev eric@gmail.com: > Hi! Last week we took 2.277.1 when patching. I didn't see any issues > until this morning when I tried to log on and got 403 No valid crumb was > included in the request. I restarted the server a few times trying to fix > it but never could get logged in. I did some research and found a thread > telling me to make a global security setting change to proxy compatibility > (even though I'm not proxied), but couldn't get to global security to try > that. So I backed it out to 2.263.4, where we were before. It's working > again, but I'm guessing the same thing will happen next time we apply > patches. Is there a change with 277 that will make me have to change some > setting or another? Thanks! -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/eac37c54-9b55-4068-8b02-a8a4a7b1eb14n%40googlegroups.com.
Re: Could not write config file
>From the link: Description Sometimes, the git init-command fails because of the .git/config-file is non-writeable. Logging into the slave, there seems to be nothing wrong with the permissions on the file. When it is good, it just inits the repo. 12:33:36 Started by GitLab push by the_persion 12:33:36 [EnvInject] - Loading node environment variables. 12:33:36 Building remotely on the_machine in workspace C:\JenkinsVM_slave\workspace\the_job 12:33:36 [WS-CLEANUP] Deleting project workspace... 12:33:38 [WS-CLEANUP] Done 12:33:41 Wiping out workspace first. 12:33:41 Cloning the remote Git repository 12:33:41 Cloning repository the_repository.git 12:33:41 > git init C:\JenkinsVM_slave\workspace\the_job # timeout=10 12:33:41 Fetching upstream changes from the_repository.git When it fails, it halts at git init: 11:38:32 Started by GitLab push by the_person 11:38:32 [EnvInject] - Loading node environment variables. 11:38:32 Building remotely on the_machine in workspace C:\JenkinsVM_slave\workspace\the_job 11:38:32 [WS-CLEANUP] Deleting project workspace... 11:38:32 [WS-CLEANUP] Done 11:38:32 Wiping out workspace first. 11:38:32 Cloning the remote Git repository 11:38:32 Cloning repository the_repository.git 11:38:32 > git init C:\JenkinsVM_slave\workspace\the_job # timeout=10 11:38:33 ERROR: Error cloning remote repo 'origin' 11:38:33 hudson.plugins.git.GitException: Could not init C:\JenkinsVM_slave\workspace\the_job 11:38:33at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:666) 11:38:33at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:467) 11:38:33at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152) 11:38:33at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145) 11:38:33at hudson.remoting.UserRequest.perform(UserRequest.java:153) 11:38:33at hudson.remoting.UserRequest.perform(UserRequest.java:50) 11:38:33at hudson.remoting.Request$2.run(Request.java:332) 11:38:33at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 11:38:33at java.util.concurrent.FutureTask.run(Unknown Source) 11:38:33at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 11:38:33at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 11:38:33at hudson.remoting.Engine$1$1.run(Engine.java:85) 11:38:33at java.lang.Thread.run(Unknown Source) -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/db32ac74-9af8-4b20-879f-561fe4ae285c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Could not write config file
Hi! Using Jenkins 2.46.1 LTS on an Ubuntu server, and a virtual Windows slave, we sometime get an error when initializing the git repo (from GitLab on the same Ubuntu server). Originally, we thought it was an issue with the Git-plugin: https://issues.jenkins-ci.org/browse/JENKINS-41169 We have tried a lot of workarounds, like removing the entire workspace manually, adding delays in the start of the job, etc etc. (You can see it in the thread above.) But nothing works as a solid solution. It is always coming back. I am currently out of ideas on things to try, so please, if you can add some comment, that makes me dig in the right direction, it would be most welcome. BR /Mattias -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/34b2c97a-0b47-45e2-a330-aeb00579b464%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins, Gerrit-trigger and git submodules
Old thread, but I have searched a lot for possible solutions, and found a few, but maybe not the most excellent one. One approach is just to let some builds fail and then manually let them through. This gets tedious over time. One approach seems to be using the topic, but there is no good way to keep a topic together at the time of "Patchset created". One other approach is to make a retrigger, which executes everytime some change with the same topic is changed. But if the change is spread out through a lot of submodules, there can be a lot of failures before we have a final result. An enhancement is to manually tell Gerrit, when all patch sets of a topic is uploaded, and then retrigger all patchset created included in the topic. The problem I have, that is not solved with @mooyah's approach is that one of the submodules cannot be built on its own, but is a collection of common parts. This common submodule breaks the build very often. I really want the CI to wait for the whole topic upload. Also I found that Gerrit merges the submodules if you Submit the superproject, even if no review is done in the submodules. This seemed quite weird. Maybe I am also missing something about the superproject/submodules handling in Gerrit? BR /Mattias -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0a2992fe--4b9c-a225-cb676b931ff7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
