Re: Getting Jgit exception in a Job that uses native Git

[Brian Ray]

Navigate to *Manage Jenkins* > *Global Tool Configuration* > *Git* > *Git 
Installations*.

If the only installation configured there is *JGit *or *JGit with Apache 
HTTP client*, that is the answer. The *Git *installation will probably be 
what you are looking for.

On Friday, March 23, 2018 at 4:21:32 AM UTC-7, Dirk Heinrichs wrote:
>
> From: jenkins...@googlegroups.com  [mailto:
> jenkins...@googlegroups.com ] On Behalf Of Dirk Heinrichs 
>
> > I'm currently seeing a strange problem where I get a Jgit exception 
> like: 
> > 
> > FATAL: Walk failure. 
> > org.eclipse.jgit.errors.MissingObjectException: Missing commit 
>  
> > 
> > in a job that's configured to use native Git. In fact, I'm also getting 
> the usual native Git output above the exception. 
> > But why is it using Jgit at all? 
>
> Could resolve it by temp. adding a "Wipe out repository & force clone". 
> However, the question remains: Why is it running Jgit at all? 
>
> Bye... 
>
> Dirk 
>
>

-- 
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/d10250e8-4ee2-410f-9d51-5b21c92fadf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GIT_SSH not working on one of my windows slaves

[Mark Waite]

The name of the temporary directory used for the credentials is based on
either the workspace folder path (with @tmp appended) or the environment
variables %TEMP% or %TMP%.  If none of those contain a space character,
then that is not the problem.

The plugin usually wirtes a message when it detects a space character in a
temporary directory path.  Since you didn't report such a message, I assume
that is not the issue in this case.

Mark Waite

On Thu, May 10, 2018 at 12:38 PM red 888  wrote:

> also, if this is helpful this is the global git config on both slaves:
>
> PS C:\Users\Administrator> git config --list
> core.symlinks=false
> core.autocrlf=true
> core.fscache=true
> color.diff=auto
> color.status=auto
> color.branch=auto
> color.interactive=true
> help.format=html
> rebase.autosquash=true
> http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
> http.sslbackend=openssl
> diff.astextplain.textconv=astextplain
> filter.lfs.clean=git-lfs clean -- %f
> filter.lfs.smudge=git-lfs smudge -- %f
> filter.lfs.process=git-lfs filter-process
> filter.lfs.required=true
>
> On Thursday, May 10, 2018 at 2:22:10 PM UTC-4, Mark Waite wrote:
>
>> Have you confirmed that the temporary directory on the failing machine
>> does not include any space characters in its path?  There is a known
>> problem on Windows that the credential passing technique required by
>> command line git does not allow a space character in the temporary
>> directory path.
>>
>> I assume from the log that the workspace does not include a space
>> character in its path.  If it does, that could invoke the same problem with
>> command line git authentication on Windows not really liking temporary
>> paths which contain a space character.
>>
>> Mark Waite
>>
>> On Thu, May 10, 2018 at 12:17 PM red 888  wrote:
>>
> I can confirm the git ssh key works and has always worked so the creds
>>> themselves should not be an issue.
>>>
>>> git clone fails on both slaves (when run interactively as a logged in
>>> user). The windows task that runs the jnlp executes as the SYSTEM account.
>>>
>>> I also made sure to do git config --system --unset credential.helper.
>>> Any local config that would break this?
>>>
>>> The git jenkins plugin should be totally handling all the git cred setup
>>> stuff, but maybe someone modified a local config on the broken slave? the
>>> git global config looks identical on both of them
>>>
>>>
>>> On Thursday, May 10, 2018 at 1:58:55 PM UTC-4, Mark Waite wrote:
>>>
 It could be a "happy accident" that it is working on the first agent.

 When using a command prompt on the first agent, does `git clone` allow
 you to clone without prompting for remote username or password?

 When using a command prompt on the second agent, does it behave the
 same as the first agent?

 The login context (~/.ssh/ directory contents, environment variables,
 etc.) affect agents which use that login context.  If the agent is already
 configured to silently authenticate to bitbucket, then incorrect
 credentials in the Jenkins environment are ignored and the repository is
 still retrieved.

 Mark Waite

 On Thu, May 10, 2018 at 11:44 AM Slide  wrote:

>>> Can you try dumping the environment variables on each node and see if
> there are any differences?
>
> On Thu, May 10, 2018 at 10:42 AM red 888  wrote:
>
 Super frustrating because this is working on one of my windows slaves,
>> but not this one- and I cant find any config differences.
>>
>> On the working slave I see this:
>>
>>
>> [Pipeline] checkout
>> Cloning the remote Git repository
>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>>  > git config --add remote.origin.fetch 
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
>> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
>> (origin/test-slave)
>> Enabling Git LFS pull
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>>

Re: GIT_SSH not working on one of my windows slaves

[red 888]

Jenkins says "using GIT_SSH to set credential" What is it actually 
putting in GIT_SSH?

On Thursday, May 10, 2018 at 2:38:14 PM UTC-4, red 888 wrote:
>
> also, if this is helpful this is the global git config on both slaves:
>
> PS C:\Users\Administrator> git config --list
> core.symlinks=false
> core.autocrlf=true
> core.fscache=true
> color.diff=auto
> color.status=auto
> color.branch=auto
> color.interactive=true
> help.format=html
> rebase.autosquash=true
> http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
> http.sslbackend=openssl
> diff.astextplain.textconv=astextplain
> filter.lfs.clean=git-lfs clean -- %f
> filter.lfs.smudge=git-lfs smudge -- %f
> filter.lfs.process=git-lfs filter-process
> filter.lfs.required=true
>
> On Thursday, May 10, 2018 at 2:22:10 PM UTC-4, Mark Waite wrote:
>>
>> Have you confirmed that the temporary directory on the failing machine 
>> does not include any space characters in its path?  There is a known 
>> problem on Windows that the credential passing technique required by 
>> command line git does not allow a space character in the temporary 
>> directory path.
>>
>> I assume from the log that the workspace does not include a space 
>> character in its path.  If it does, that could invoke the same problem with 
>> command line git authentication on Windows not really liking temporary 
>> paths which contain a space character.
>>
>> Mark Waite 
>>
>> On Thu, May 10, 2018 at 12:17 PM red 888  wrote:
>>
>>> I can confirm the git ssh key works and has always worked so the creds 
>>> themselves should not be an issue.
>>>
>>> git clone fails on both slaves (when run interactively as a logged in 
>>> user). The windows task that runs the jnlp executes as the SYSTEM account.
>>>
>>> I also made sure to do git config --system --unset credential.helper. 
>>> Any local config that would break this?
>>>
>>> The git jenkins plugin should be totally handling all the git cred setup 
>>> stuff, but maybe someone modified a local config on the broken slave? the 
>>> git global config looks identical on both of them
>>>
>>>
>>> On Thursday, May 10, 2018 at 1:58:55 PM UTC-4, Mark Waite wrote:
>>>
 It could be a "happy accident" that it is working on the first agent.  

 When using a command prompt on the first agent, does `git clone` allow 
 you to clone without prompting for remote username or password?  

 When using a command prompt on the second agent, does it behave the 
 same as the first agent?

 The login context (~/.ssh/ directory contents, environment variables, 
 etc.) affect agents which use that login context.  If the agent is already 
 configured to silently authenticate to bitbucket, then incorrect 
 credentials in the Jenkins environment are ignored and the repository is 
 still retrieved.

 Mark Waite

 On Thu, May 10, 2018 at 11:44 AM Slide  wrote:

>>> Can you try dumping the environment variables on each node and see if 
> there are any differences?
>
> On Thu, May 10, 2018 at 10:42 AM red 888  wrote:
>
 Super frustrating because this is working on one of my windows slaves, 
>> but not this one- and I cant find any config differences.
>>
>> On the working slave I see this:
>>
>>
>> [Pipeline] checkout
>> Cloning the remote Git repository
>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>>  > git config --add remote.origin.fetch 
>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
>> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
>> (origin/test-slave)
>> Enabling Git LFS pull
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>>  > git config --get remote.origin.url # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git lfs pull origin # timeout=45
>> Commit message: "test slave"
>>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
>> timeout=10
>>
>>
>>
>> But o

Re: GIT_SSH not working on one of my windows slaves

[red 888]

also, if this is helpful this is the global git config on both slaves:

PS C:\Users\Administrator> git config --list
core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
rebase.autosquash=true
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
http.sslbackend=openssl
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true

On Thursday, May 10, 2018 at 2:22:10 PM UTC-4, Mark Waite wrote:
>
> Have you confirmed that the temporary directory on the failing machine 
> does not include any space characters in its path?  There is a known 
> problem on Windows that the credential passing technique required by 
> command line git does not allow a space character in the temporary 
> directory path.
>
> I assume from the log that the workspace does not include a space 
> character in its path.  If it does, that could invoke the same problem with 
> command line git authentication on Windows not really liking temporary 
> paths which contain a space character.
>
> Mark Waite 
>
> On Thu, May 10, 2018 at 12:17 PM red 888  > wrote:
>
>> I can confirm the git ssh key works and has always worked so the creds 
>> themselves should not be an issue.
>>
>> git clone fails on both slaves (when run interactively as a logged in 
>> user). The windows task that runs the jnlp executes as the SYSTEM account.
>>
>> I also made sure to do git config --system --unset credential.helper. Any 
>> local config that would break this?
>>
>> The git jenkins plugin should be totally handling all the git cred setup 
>> stuff, but maybe someone modified a local config on the broken slave? the 
>> git global config looks identical on both of them
>>
>>
>> On Thursday, May 10, 2018 at 1:58:55 PM UTC-4, Mark Waite wrote:
>>
>>> It could be a "happy accident" that it is working on the first agent.  
>>>
>>> When using a command prompt on the first agent, does `git clone` allow 
>>> you to clone without prompting for remote username or password?  
>>>
>>> When using a command prompt on the second agent, does it behave the same 
>>> as the first agent?
>>>
>>> The login context (~/.ssh/ directory contents, environment variables, 
>>> etc.) affect agents which use that login context.  If the agent is already 
>>> configured to silently authenticate to bitbucket, then incorrect 
>>> credentials in the Jenkins environment are ignored and the repository is 
>>> still retrieved.
>>>
>>> Mark Waite
>>>
>>> On Thu, May 10, 2018 at 11:44 AM Slide  wrote:
>>>
>> Can you try dumping the environment variables on each node and see if 
 there are any differences?

 On Thu, May 10, 2018 at 10:42 AM red 888  wrote:

>>> Super frustrating because this is working on one of my windows slaves, 
> but not this one- and I cant find any config differences.
>
> On the working slave I see this:
>
>
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository g...@bitbucket.org:myteam/myapp.git
>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>  > git --version # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=45
>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
> timeout=10
>  > git config --add remote.origin.fetch 
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
> timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=45
>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
> (origin/test-slave)
> Enabling Git LFS pull
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>  > git config --get remote.origin.url # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git lfs pull origin # timeout=45
> Commit message: "test slave"
>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
> timeout=10
>
>
>
> But on the failing slave:
>
>
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository g...@bitbucket.org:myteam/myapp.git
>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam

Re: GIT_SSH not working on one of my windows slaves

[red 888]

hmm what is the "temporary directory" in this context? The jenkins 
workspace is configured the same on both slaves (just a folder under c:) so 
no spaces there

Another thing i looked at was 
*c:\Windows\System32\config\systemprofile\.ssh\* and on both slaves that 
folder just has a know_hosts file and its contents is the same on both 
slaves too.

On Thursday, May 10, 2018 at 2:22:10 PM UTC-4, Mark Waite wrote:
>
> Have you confirmed that the temporary directory on the failing machine 
> does not include any space characters in its path?  There is a known 
> problem on Windows that the credential passing technique required by 
> command line git does not allow a space character in the temporary 
> directory path.
>
> I assume from the log that the workspace does not include a space 
> character in its path.  If it does, that could invoke the same problem with 
> command line git authentication on Windows not really liking temporary 
> paths which contain a space character.
>
> Mark Waite 
>
> On Thu, May 10, 2018 at 12:17 PM red 888  > wrote:
>
>> I can confirm the git ssh key works and has always worked so the creds 
>> themselves should not be an issue.
>>
>> git clone fails on both slaves (when run interactively as a logged in 
>> user). The windows task that runs the jnlp executes as the SYSTEM account.
>>
>> I also made sure to do git config --system --unset credential.helper. Any 
>> local config that would break this?
>>
>> The git jenkins plugin should be totally handling all the git cred setup 
>> stuff, but maybe someone modified a local config on the broken slave? the 
>> git global config looks identical on both of them
>>
>>
>> On Thursday, May 10, 2018 at 1:58:55 PM UTC-4, Mark Waite wrote:
>>
>>> It could be a "happy accident" that it is working on the first agent.  
>>>
>>> When using a command prompt on the first agent, does `git clone` allow 
>>> you to clone without prompting for remote username or password?  
>>>
>>> When using a command prompt on the second agent, does it behave the same 
>>> as the first agent?
>>>
>>> The login context (~/.ssh/ directory contents, environment variables, 
>>> etc.) affect agents which use that login context.  If the agent is already 
>>> configured to silently authenticate to bitbucket, then incorrect 
>>> credentials in the Jenkins environment are ignored and the repository is 
>>> still retrieved.
>>>
>>> Mark Waite
>>>
>>> On Thu, May 10, 2018 at 11:44 AM Slide  wrote:
>>>
>> Can you try dumping the environment variables on each node and see if 
 there are any differences?

 On Thu, May 10, 2018 at 10:42 AM red 888  wrote:

>>> Super frustrating because this is working on one of my windows slaves, 
> but not this one- and I cant find any config differences.
>
> On the working slave I see this:
>
>
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository g...@bitbucket.org:myteam/myapp.git
>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>  > git --version # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=45
>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
> timeout=10
>  > git config --add remote.origin.fetch 
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
> timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=45
>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
> (origin/test-slave)
> Enabling Git LFS pull
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>  > git config --get remote.origin.url # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git lfs pull origin # timeout=45
> Commit message: "test slave"
>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
> timeout=10
>
>
>
> But on the failing slave:
>
>
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository g...@bitbucket.org:myteam/myapp.git
>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>  > git --version # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/

Re: GIT_SSH not working on one of my windows slaves

[Mark Waite]

Have you confirmed that the temporary directory on the failing machine does
not include any space characters in its path?  There is a known problem on
Windows that the credential passing technique required by command line git
does not allow a space character in the temporary directory path.

I assume from the log that the workspace does not include a space character
in its path.  If it does, that could invoke the same problem with command
line git authentication on Windows not really liking temporary paths which
contain a space character.

Mark Waite

On Thu, May 10, 2018 at 12:17 PM red 888  wrote:

> I can confirm the git ssh key works and has always worked so the creds
> themselves should not be an issue.
>
> git clone fails on both slaves (when run interactively as a logged in
> user). The windows task that runs the jnlp executes as the SYSTEM account.
>
> I also made sure to do git config --system --unset credential.helper. Any
> local config that would break this?
>
> The git jenkins plugin should be totally handling all the git cred setup
> stuff, but maybe someone modified a local config on the broken slave? the
> git global config looks identical on both of them
>
>
> On Thursday, May 10, 2018 at 1:58:55 PM UTC-4, Mark Waite wrote:
>
>> It could be a "happy accident" that it is working on the first agent.
>>
>> When using a command prompt on the first agent, does `git clone` allow
>> you to clone without prompting for remote username or password?
>>
>> When using a command prompt on the second agent, does it behave the same
>> as the first agent?
>>
>> The login context (~/.ssh/ directory contents, environment variables,
>> etc.) affect agents which use that login context.  If the agent is already
>> configured to silently authenticate to bitbucket, then incorrect
>> credentials in the Jenkins environment are ignored and the repository is
>> still retrieved.
>>
>> Mark Waite
>>
>> On Thu, May 10, 2018 at 11:44 AM Slide  wrote:
>>
> Can you try dumping the environment variables on each node and see if
>>> there are any differences?
>>>
>>> On Thu, May 10, 2018 at 10:42 AM red 888  wrote:
>>>
>> Super frustrating because this is working on one of my windows slaves,
 but not this one- and I cant find any config differences.

 On the working slave I see this:


 [Pipeline] checkout
 Cloning the remote Git repository
 Cloning repository g...@bitbucket.org:myteam/myapp.git
  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
 Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
  > git --version # timeout=10
 using GIT_SSH to set credentials mygitcreds
  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
 +refs/heads/*:refs/remotes/origin/* # timeout=45
  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
 timeout=10
  > git config --add remote.origin.fetch 
 +refs/heads/*:refs/remotes/origin/* # timeout=10
  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
 timeout=10
 Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
 using GIT_SSH to set credentials mygitcreds
  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
 +refs/heads/*:refs/remotes/origin/* # timeout=45
  > git rev-parse "origin/test-slave^{commit}" # timeout=10
 Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
 (origin/test-slave)
 Enabling Git LFS pull
  > git config core.sparsecheckout # timeout=10
  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
  > git config --get remote.origin.url # timeout=10
 using GIT_SSH to set credentials mygitcreds
  > git lfs pull origin # timeout=45
 Commit message: "test slave"
  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
 timeout=10



 But on the failing slave:


 [Pipeline] checkout
 Cloning the remote Git repository
 Cloning repository g...@bitbucket.org:myteam/myapp.git
  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
 Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
  > git --version # timeout=10
 using GIT_SSH to set credentials mygitcreds
  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
 +refs/heads/*:refs/remotes/origin/* # timeout=45
 ERROR: Error cloning remote repo 'origin'
 hudson.plugins.git.GitException: Command "git fetch --tags --progress 
 g...@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/ori

 gin/*" returned status code 128:
 stdout:
 stderr: gituserfrom...@bitbucket.org: Permission denied (publickey).
 fatal: Could not read from remote repository.


 Its the same pipeline job, same repo, same creds, and the slave should
 be configured the same but when I change the agent to point to the other
 sla

Re: GIT_SSH not working on one of my windows slaves

[red 888]

I can confirm the git ssh key works and has always worked so the creds 
themselves should not be an issue.

git clone fails on both slaves (when run interactively as a logged in 
user). The windows task that runs the jnlp executes as the SYSTEM account.

I also made sure to do git config --system --unset credential.helper. Any 
local config that would break this?

The git jenkins plugin should be totally handling all the git cred setup 
stuff, but maybe someone modified a local config on the broken slave? the 
git global config looks identical on both of them


On Thursday, May 10, 2018 at 1:58:55 PM UTC-4, Mark Waite wrote:
>
> It could be a "happy accident" that it is working on the first agent.  
>
> When using a command prompt on the first agent, does `git clone` allow you 
> to clone without prompting for remote username or password?  
>
> When using a command prompt on the second agent, does it behave the same 
> as the first agent?
>
> The login context (~/.ssh/ directory contents, environment variables, 
> etc.) affect agents which use that login context.  If the agent is already 
> configured to silently authenticate to bitbucket, then incorrect 
> credentials in the Jenkins environment are ignored and the repository is 
> still retrieved.
>
> Mark Waite
>
> On Thu, May 10, 2018 at 11:44 AM Slide > 
> wrote:
>
>> Can you try dumping the environment variables on each node and see if 
>> there are any differences?
>>
>> On Thu, May 10, 2018 at 10:42 AM red 888 > > wrote:
>>
>>> Super frustrating because this is working on one of my windows slaves, 
>>> but not this one- and I cant find any config differences.
>>>
>>> On the working slave I see this:
>>>
>>>
>>> [Pipeline] checkout
>>> Cloning the remote Git repository
>>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>>  > git --version # timeout=10
>>> using GIT_SSH to set credentials mygitcreds
>>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>>> timeout=10
>>>  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* 
>>> # timeout=10
>>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>>> timeout=10
>>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>> using GIT_SSH to set credentials mygitcreds
>>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
>>> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
>>> (origin/test-slave)
>>> Enabling Git LFS pull
>>>  > git config core.sparsecheckout # timeout=10
>>>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>>>  > git config --get remote.origin.url # timeout=10
>>> using GIT_SSH to set credentials mygitcreds
>>>  > git lfs pull origin # timeout=45
>>> Commit message: "test slave"
>>>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
>>> timeout=10
>>>
>>>
>>>
>>> But on the failing slave:
>>>
>>>
>>> [Pipeline] checkout
>>> Cloning the remote Git repository
>>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>>  > git --version # timeout=10
>>> using GIT_SSH to set credentials mygitcreds
>>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>> ERROR: Error cloning remote repo 'origin'
>>> hudson.plugins.git.GitException: Command "git fetch --tags --progress 
>>> g...@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/origin/*" 
>>> returned status code 128:
>>> stdout: 
>>> stderr: gituserfrom...@bitbucket.org : Permission denied 
>>> (publickey).
>>> fatal: Could not read from remote repository.
>>>
>>>
>>> Its the same pipeline job, same repo, same creds, and the slave should 
>>> be configured the same but when I change the agent to point to the other 
>>> slave it cant clone.
>>>
>>>
>>> On the working slave all i had to do was install git for windows (turn 
>>> off windows cred store), install java, and then run the jnlp jar.
>>>
>>>
>>> Tried to do the same thing on the non working slave so I dont know why 
>>> that one could be failing.
>>>
>>> -- 
>>> 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-use...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/3afe4362-20f7-40c9-91ac-ac6573d0bd16%40googlegroups.com

Re: GIT_SSH not working on one of my windows slaves

[red 888]

Dumped env vars on both nodes right before checkout, i dont see any real 
differences. Anything env vars specific to GIT_SSH? Also both slaves are 
running the same windows build too.


On Thursday, May 10, 2018 at 1:44:16 PM UTC-4, slide wrote:
>
> Can you try dumping the environment variables on each node and see if 
> there are any differences?
>
> On Thu, May 10, 2018 at 10:42 AM red 888  > wrote:
>
>> Super frustrating because this is working on one of my windows slaves, 
>> but not this one- and I cant find any config differences.
>>
>> On the working slave I see this:
>>
>>
>> [Pipeline] checkout
>> Cloning the remote Git repository
>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>>  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* 
>> # timeout=10
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
>> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
>> (origin/test-slave)
>> Enabling Git LFS pull
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>>  > git config --get remote.origin.url # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git lfs pull origin # timeout=45
>> Commit message: "test slave"
>>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
>> timeout=10
>>
>>
>>
>> But on the failing slave:
>>
>>
>> [Pipeline] checkout
>> Cloning the remote Git repository
>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>> ERROR: Error cloning remote repo 'origin'
>> hudson.plugins.git.GitException: Command "git fetch --tags --progress 
>> g...@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/origin/*" 
>> returned status code 128:
>> stdout: 
>> stderr: gituserfrom...@bitbucket.org : Permission denied 
>> (publickey).
>> fatal: Could not read from remote repository.
>>
>>
>> Its the same pipeline job, same repo, same creds, and the slave should be 
>> configured the same but when I change the agent to point to the other slave 
>> it cant clone.
>>
>>
>> On the working slave all i had to do was install git for windows (turn 
>> off windows cred store), install java, and then run the jnlp jar.
>>
>>
>> Tried to do the same thing on the non working slave so I dont know why 
>> that one could be failing.
>>
>> -- 
>> 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-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/3afe4362-20f7-40c9-91ac-ac6573d0bd16%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/4b508b44-b542-4249-8b52-443ad4bd258e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GIT_SSH not working on one of my windows slaves

[Mark Waite]

It could be a "happy accident" that it is working on the first agent.

When using a command prompt on the first agent, does `git clone` allow you
to clone without prompting for remote username or password?

When using a command prompt on the second agent, does it behave the same as
the first agent?

The login context (~/.ssh/ directory contents, environment variables, etc.)
affect agents which use that login context.  If the agent is already
configured to silently authenticate to bitbucket, then incorrect
credentials in the Jenkins environment are ignored and the repository is
still retrieved.

Mark Waite

On Thu, May 10, 2018 at 11:44 AM Slide  wrote:

> Can you try dumping the environment variables on each node and see if
> there are any differences?
>
> On Thu, May 10, 2018 at 10:42 AM red 888  wrote:
>
>> Super frustrating because this is working on one of my windows slaves,
>> but not this one- and I cant find any config differences.
>>
>> On the working slave I see this:
>>
>>
>> [Pipeline] checkout
>> Cloning the remote Git repository
>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>>  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* 
>> # timeout=10
>>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
>> timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
>> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
>> (origin/test-slave)
>> Enabling Git LFS pull
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>>  > git config --get remote.origin.url # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git lfs pull origin # timeout=45
>> Commit message: "test slave"
>>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
>> timeout=10
>>
>>
>>
>> But on the failing slave:
>>
>>
>> [Pipeline] checkout
>> Cloning the remote Git repository
>> Cloning repository g...@bitbucket.org:myteam/myapp.git
>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials mygitcreds
>>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>> ERROR: Error cloning remote repo 'origin'
>> hudson.plugins.git.GitException: Command "git fetch --tags --progress 
>> g...@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/origin/*" 
>> returned status code 128:
>> stdout:
>> stderr: gituserfromcredbind...@bitbucket.org: Permission denied (publickey).
>> fatal: Could not read from remote repository.
>>
>>
>> Its the same pipeline job, same repo, same creds, and the slave should be
>> configured the same but when I change the agent to point to the other slave
>> it cant clone.
>>
>>
>> On the working slave all i had to do was install git for windows (turn
>> off windows cred store), install java, and then run the jnlp jar.
>>
>>
>> Tried to do the same thing on the non working slave so I dont know why
>> that one could be failing.
>>
>> --
>> 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/3afe4362-20f7-40c9-91ac-ac6573d0bd16%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAPiUgVft0hmukqoCu-JQckBpj%3D72CwCfQp_tTwAz5kAvT_-qRg%40mail.gmail.com
> 

Re: GIT_SSH not working on one of my windows slaves

[Slide]

Can you try dumping the environment variables on each node and see if there
are any differences?

On Thu, May 10, 2018 at 10:42 AM red 888  wrote:

> Super frustrating because this is working on one of my windows slaves, but
> not this one- and I cant find any config differences.
>
> On the working slave I see this:
>
>
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository g...@bitbucket.org:myteam/myapp.git
>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>  > git --version # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=45
>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
> timeout=10
>  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
> timeout=10
>  > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # 
> timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=45
>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
> (origin/test-slave)
> Enabling Git LFS pull
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>  > git config --get remote.origin.url # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git lfs pull origin # timeout=45
> Commit message: "test slave"
>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
> timeout=10
>
>
>
> But on the failing slave:
>
>
> [Pipeline] checkout
> Cloning the remote Git repository
> Cloning repository g...@bitbucket.org:myteam/myapp.git
>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>  > git --version # timeout=10
> using GIT_SSH to set credentials mygitcreds
>  > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
> +refs/heads/*:refs/remotes/origin/* # timeout=45
> ERROR: Error cloning remote repo 'origin'
> hudson.plugins.git.GitException: Command "git fetch --tags --progress 
> g...@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/origin/*" 
> returned status code 128:
> stdout:
> stderr: gituserfromcredbind...@bitbucket.org: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
>
> Its the same pipeline job, same repo, same creds, and the slave should be
> configured the same but when I change the agent to point to the other slave
> it cant clone.
>
>
> On the working slave all i had to do was install git for windows (turn off
> windows cred store), install java, and then run the jnlp jar.
>
>
> Tried to do the same thing on the non working slave so I dont know why
> that one could be failing.
>
> --
> 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/3afe4362-20f7-40c9-91ac-ac6573d0bd16%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAPiUgVft0hmukqoCu-JQckBpj%3D72CwCfQp_tTwAz5kAvT_-qRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

GIT_SSH not working on one of my windows slaves

[red 888]

Super frustrating because this is working on one of my windows slaves, but 
not this one- and I cant find any config differences.

On the working slave I see this:


[Pipeline] checkout
Cloning the remote Git repository
Cloning repository g...@bitbucket.org:myteam/myapp.git
 > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
 > git --version # timeout=10
using GIT_SSH to set credentials mygitcreds
 > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
 > +refs/heads/*:refs/remotes/origin/* # timeout=45
 > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git # timeout=10
Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
using GIT_SSH to set credentials mygitcreds
 > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
 > +refs/heads/*:refs/remotes/origin/* # timeout=45
 > git rev-parse "origin/test-slave^{commit}" # timeout=10
Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
(origin/test-slave)
Enabling Git LFS pull
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
 > git config --get remote.origin.url # timeout=10
using GIT_SSH to set credentials mygitcreds
 > git lfs pull origin # timeout=45
Commit message: "test slave"
 > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=10



But on the failing slave:


[Pipeline] checkout
Cloning the remote Git repository
Cloning repository g...@bitbucket.org:myteam/myapp.git
 > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
 > git --version # timeout=10
using GIT_SSH to set credentials mygitcreds
 > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git 
 > +refs/heads/*:refs/remotes/origin/* # timeout=45
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git fetch --tags --progress 
g...@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/origin/*" 
returned status code 128:
stdout: 
stderr: gituserfromcredbind...@bitbucket.org: Permission denied (publickey).
fatal: Could not read from remote repository.


Its the same pipeline job, same repo, same creds, and the slave should be 
configured the same but when I change the agent to point to the other slave 
it cant clone.


On the working slave all i had to do was install git for windows (turn off 
windows cred store), install java, and then run the jnlp jar.


Tried to do the same thing on the non working slave so I dont know why that 
one could be failing.

-- 
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/3afe4362-20f7-40c9-91ac-ac6573d0bd16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Is there a way to figure out artifactName in jenkins pipeline without specifying it in the Jenkinsfile?

[krish]

Is there a way to figure out artifactName in jenkins pipeline without 
specifying it in the Jenkinsfile?

-- 
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/3524b664-d802-44fc-8cc0-b82808feeb10%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re:

[niristotle okram]

What is your version of the plugins?

On Thu, May 10, 2018 at 3:14 AM Victor Martinez <
victormartinezru...@gmail.com> wrote:

> I'm not sure if you can upgrade those plugins but you could give a go and
> run a local jenkins instance with the latest version of those plugins and
> see whether the same behaviour keeps going. Other than that, I don't have
> any other suggestions.
>
> Cheers
>
> --
> 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/d8748045-ec9d-4c27-9b68-476e8f5437e6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from mobile device, excuse typos if any.

-- 
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/CAPzcO4jX_8Q_f2vNaEFD1jbP5HAqUpT5cHdyOw7B-0UGKJigRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

How to get the value of the "Release version" (and others) from "Module Version Configuration" to a comment

[maxcollins8923]

Hi

We are using jenkins version 2.73.3 on a Linux Redhat OS 7. We have jobs in 
> which we execute the option Artifactory Release Staging there is a 
> section called Module 
> Version Configuration in which there are two variables 
> 

Release version
and
Next development version

We want to take the contents or values of these variables and add them to 
>>> the section VCS Configuration  and within same Next development version 
>>> comment to add the values of Release version and Next development version 
>>> to this comment Next development version comment 
>>
>>
Is this possible to do what plugins are required, how to do we obtain these 
> values and add them to  Next development version comment?



Currently 
Next development version commenthas a value of 
[artifactory-release] Next development version.

we wants to have 
[artifactory-release] Next development version. Previous release version 
4.0.1. Next development version 4.0.2-SNAPSHOT.  

The values would obviously change.

In the attached screen shot I have circled the part of the comment we 
wanted added to the Next development version

Max 

-- 
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/42088004-69ac-4d2f-a86e-0a0570aefa7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re:

[Victor Martinez]

I'm not sure if you can upgrade those plugins but you could give a go and 
run a local jenkins instance with the latest version of those plugins and 
see whether the same behaviour keeps going. Other than that, I don't have 
any other suggestions.

Cheers

-- 
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/d8748045-ec9d-4c27-9b68-476e8f5437e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to check "Use Groovy Sandbox" programmatically from groovy : EnvironmentVariableContext

[Victor Martinez]

Does it help the below answer? 
- 
https://groups.google.com/forum/#!searchin/job-dsl-plugin/Use$20Groovy$20Sandbox%7Csort:date/job-dsl-plugin/UiD7ujvEQ-s/HvgRrAiJAwAJ

-- 
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/dec9a15f-8b7c-41d1-be55-5277f7ef4466%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.