Re: gitSCM failed after updates

[Mark Waite]

On Tue, Jun 11, 2019 at 4:53 PM Giles  wrote:

> Unfortunately, I appear to have gone from the frying pan to the fire.  I
> ran one deploy that hadn't worked previously and it did work, and I
> immediately responded with an "it's working" message.  And that single
> deploy still works.  But multiple others (all based on the same code, with
> only varying parameters) don't, all failing with this:
>
> Started by user Giles
> java.lang.NoSuchMethodError: 
> org.eclipse.jgit.lib.Repository.getRef(Ljava/lang/String;)Lorg/eclipse/jgit/lib/Ref;
>   at 
> jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:117)
>
> That may indicate that something has installed a newer version of JGit
than JGit 4.5 which is bundled with git client plugin 2.7.x.  JGit 4.5 and
prior versions provided the getRef(String) API.  Newer JGit versions (like
4.9, 5.1, 5.2, and 5.3) have deprecated or stopped delivering the
getRef(String) API.

Can you confirm that the git client plugin version you're running is 2.7.x
and not one of the pre-release 3.0 versions?  If it is not, then you likely
need to install the most recent 2.7 version.

Can you confirm that the git plugin version you're running is 3.9.x and not
one of the pre-release 4.0 versions?  I expect that is the case since
pre-release versions of git plugin 4.0.0 generally do not refer to
getRef(String).

That message is unrelated to the version of command line git installed on
the master.  That message is related to an internal mismatch between the
JGit API that is available in the running Jenkins process and the JGit API
that the git plugin requires.  The git plugin is expecting to find JGit 4.5
in the Jenkins process.  It does not seem to be there in this case.

This at least is a known error: it appears to happen when there's a newer
> version of git, or a misalignment of the git version and the git plugin.  I
> had initially installed the very new version of Git for Windows 2.22.0.  I
> downgraded that to 2.17.1.2, and eventually went to 2.21.0 - all resulting
> in the same failure.  Any thoughts?  It certainly doesn't seem to be the
> Git version, and the one working pipeline muddies the water further.
>
> On Tuesday, 11 June 2019 17:12:11 UTC-4, Mark Waite wrote:
>>
>> I'm glad that helped.  In the past, we've seen cases where a new version
>> of ssh surprises the credential integration that is used by the git
>> plugin.  I don't think your case is related to that, but I did see that Git
>> for Windows 2.22.0 now includes OpenSSH 8.0.  I need to add that version
>> into my test environment.  I'm not aware of any breakage with OpenSSH 8.0,
>> but we've been surprised in the past.
>>
>> On Tue, Jun 11, 2019 at 3:09 PM Giles  wrote:
>>
>>> Nailed it in one.
>>>
>>> I was sure it was a Jenkins issue ... but I'd upgraded Cygwin at the
>>> same time, and that probably included their version of git.  Which yes, is
>>> my default git.  I changed "Manage Jenkins" -> "Global Tool Configuration"
>>> -> git to the just-installed "Git for Windows", and ... fixed.  I may have
>>> to make some changes in the Jenkinsfiles themselves, but it seems clear now
>>> that the latest Cygwin git broke something, and that Git for Windows fixed
>>> it ...
>>>
>>> This was crisis-level breakage for my department - I can't thank you
>>> enough.
>>>
>>> On Tuesday, 11 June 2019 16:36:38 UTC-4, Mark Waite wrote:

 Are you quite sure that your configuration did not change in about the
 same time as that upgrade?

 The log file indicates that you're running command line git as provided
 by Cygwin.  Is that intentional?  Has it always been that way?

 I don't test the Jenkins git plugin with Cygwin.  I test with Git for
 Windows.  I'm glad cygwin git works, but don't intend to apply effort to
 make it work.

 I don't see anything suspicious or troubling in the list of updates.
 As far as I can tell, none of them should have changed that behavior of the
 git plugin.

 On Tue, Jun 11, 2019 at 1:54 PM Giles  wrote:

> I'm running Jenkins 2.164.3 on a Windows server.  It's been running
> well for several months.  Every Friday evening I do all the Jenkins plugin
> updates.  After this past Friday's updates (details below), all our jobs
> are broken - apparently because the GitSCM checkout is broken.  Our
> Jenkinsfiles are all stored in a git repo, so Jenkins attempts to pull a
> new version before running the job.  This now fails.  I created a test
> Jenkinsfile (editing directly in Jenkins rather than in the git repo) with
> this code in it:
>
> def scmVars = checkout(
> [
> $class: 'GitSCM',
> branches: [[name: '*/' + branch ]],
> doGenerateSubmoduleConfigurations: false,
> extensions: [],
> submoduleCfg: [],
> userRemoteConfigs: [
>

Re: gitSCM failed after updates

[Giles]

Unfortunately, I appear to have gone from the frying pan to the fire.  I 
ran one deploy that hadn't worked previously and it did work, and I 
immediately responded with an "it's working" message.  And that single 
deploy still works.  But multiple others (all based on the same code, with 
only varying parameters) don't, all failing with this:

Started by user Giles
java.lang.NoSuchMethodError: 
org.eclipse.jgit.lib.Repository.getRef(Ljava/lang/String;)Lorg/eclipse/jgit/lib/Ref;
at 
jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:117)
at 
jenkins.plugins.git.GitSCMFileSystem$1.invoke(GitSCMFileSystem.java:114)
at 
jenkins.plugins.git.GitSCMFileSystem$3.invoke(GitSCMFileSystem.java:193)
at 
org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:29)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:81)
at 
jenkins.plugins.git.GitSCMFileSystem.invoke(GitSCMFileSystem.java:189)
at 
jenkins.plugins.git.GitSCMFileSystem.(GitSCMFileSystem.java:114)
at 
jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:353)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:198)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:174)
at 
org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
at 
org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
at 
org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:293)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE


This at least is a known error: it appears to happen when there's a newer 
version of git, or a misalignment of the git version and the git plugin.  I 
had initially installed the very new version of Git for Windows 2.22.0.  I 
downgraded that to 2.17.1.2, and eventually went to 2.21.0 - all resulting 
in the same failure.  Any thoughts?  It certainly doesn't seem to be the 
Git version, and the one working pipeline muddies the water further.

On Tuesday, 11 June 2019 17:12:11 UTC-4, Mark Waite wrote:
>
> I'm glad that helped.  In the past, we've seen cases where a new version 
> of ssh surprises the credential integration that is used by the git 
> plugin.  I don't think your case is related to that, but I did see that Git 
> for Windows 2.22.0 now includes OpenSSH 8.0.  I need to add that version 
> into my test environment.  I'm not aware of any breakage with OpenSSH 8.0, 
> but we've been surprised in the past.
>
> On Tue, Jun 11, 2019 at 3:09 PM Giles > 
> wrote:
>
>> Nailed it in one.
>>
>> I was sure it was a Jenkins issue ... but I'd upgraded Cygwin at the same 
>> time, and that probably included their version of git.  Which yes, is my 
>> default git.  I changed "Manage Jenkins" -> "Global Tool Configuration" -> 
>> git to the just-installed "Git for Windows", and ... fixed.  I may have to 
>> make some changes in the Jenkinsfiles themselves, but it seems clear now 
>> that the latest Cygwin git broke something, and that Git for Windows fixed 
>> it ...
>>
>> This was crisis-level breakage for my department - I can't thank you 
>> enough.
>>
>> On Tuesday, 11 June 2019 16:36:38 UTC-4, Mark Waite wrote:
>>>
>>> Are you quite sure that your configuration did not change in about the 
>>> same time as that upgrade?
>>>
>>> The log file indicates that you're running command line git as provided 
>>> by Cygwin.  Is that intentional?  Has it always been that way?  
>>>
>>> I don't test the Jenkins git plugin with Cygwin.  I test with Git for 
>>> Windows.  I'm glad cygwin git works, but don't intend to apply effort to 
>>> make it work.
>>>
>>> I don't see anything suspicious or troubling in the list of updates.  As 
>>> far as I can tell, none of them should have changed that behavior of the 
>>> git plugin.
>>>
>>> On Tue, Jun 11, 2019 at 1:54 PM Giles  wrote:
>>>
 I'm running Jenkins 2.164.3 on a Windows server.  It's been running 
 well for several months.  Every Friday evening I do all the Jenkins plugin 
 updates.  After this past Friday's updates (details below), all our jobs 
 are broken - apparently because the GitSCM checkout is broken.  Our 
 Jenkinsfiles are all stored in a git repo, so Jenkins attempts to pull a 
 new version before running the job.  This now fails.  I created a test 
 Jenkinsfile (editing directly in Jenkins rather than in the git repo) with 
 this code in it:

 def scmVars = checkout(
 [
 $class: 'GitSCM',
 branches: [[name: '*/' + branch ]],
 doGenerateSubmoduleConfigurations: false,
 extensions: [],
 submoduleCfg: [],
 userRemoteConfigs: [

Re: Can multibranch pipeline support user-selected branch?

[David Karr]

On Tue, Jun 11, 2019 at 1:47 PM Guy Knights  wrote:

> I've been looking into multibranch pipeline and I'm wondering, can it be
> configured to support build parameters to specify which branches will be
> built?
>
> I know the branch config can be setup with a regex to specify that certain
> branches will be built, but it means that the same branches will be built
> every time. I want whoever kicks off the job to be able to specify that
> only particular branches will build at different times.
>

I'm not sure if this is what you're looking for, but a multibranch pipeline
can be specifically fired for a particular branch, with a url like this:

http://host:port
/jenkins/job//job//job/${PULL_REQUEST_TO_BRANCH}/buildWithParameters?...


> Thanks,
> Guy
>
> --
> 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/CANNH9msUkO1_Z3dF22%3D28qwToq%2BzfiNqcoe5ShHHfbVzN38G1A%40mail.gmail.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/CAA5t8VrKE9u-6WbRQGG13ijBmv3KA%3D-uMbWOHNrT9LcLe91O2Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: gitSCM failed after updates

[Mark Waite]

I'm glad that helped.  In the past, we've seen cases where a new version of
ssh surprises the credential integration that is used by the git plugin.  I
don't think your case is related to that, but I did see that Git for
Windows 2.22.0 now includes OpenSSH 8.0.  I need to add that version into
my test environment.  I'm not aware of any breakage with OpenSSH 8.0, but
we've been surprised in the past.

On Tue, Jun 11, 2019 at 3:09 PM Giles  wrote:

> Nailed it in one.
>
> I was sure it was a Jenkins issue ... but I'd upgraded Cygwin at the same
> time, and that probably included their version of git.  Which yes, is my
> default git.  I changed "Manage Jenkins" -> "Global Tool Configuration" ->
> git to the just-installed "Git for Windows", and ... fixed.  I may have to
> make some changes in the Jenkinsfiles themselves, but it seems clear now
> that the latest Cygwin git broke something, and that Git for Windows fixed
> it ...
>
> This was crisis-level breakage for my department - I can't thank you
> enough.
>
> On Tuesday, 11 June 2019 16:36:38 UTC-4, Mark Waite wrote:
>>
>> Are you quite sure that your configuration did not change in about the
>> same time as that upgrade?
>>
>> The log file indicates that you're running command line git as provided
>> by Cygwin.  Is that intentional?  Has it always been that way?
>>
>> I don't test the Jenkins git plugin with Cygwin.  I test with Git for
>> Windows.  I'm glad cygwin git works, but don't intend to apply effort to
>> make it work.
>>
>> I don't see anything suspicious or troubling in the list of updates.  As
>> far as I can tell, none of them should have changed that behavior of the
>> git plugin.
>>
>> On Tue, Jun 11, 2019 at 1:54 PM Giles  wrote:
>>
>>> I'm running Jenkins 2.164.3 on a Windows server.  It's been running well
>>> for several months.  Every Friday evening I do all the Jenkins plugin
>>> updates.  After this past Friday's updates (details below), all our jobs
>>> are broken - apparently because the GitSCM checkout is broken.  Our
>>> Jenkinsfiles are all stored in a git repo, so Jenkins attempts to pull a
>>> new version before running the job.  This now fails.  I created a test
>>> Jenkinsfile (editing directly in Jenkins rather than in the git repo) with
>>> this code in it:
>>>
>>> def scmVars = checkout(
>>> [
>>> $class: 'GitSCM',
>>> branches: [[name: '*/' + branch ]],
>>> doGenerateSubmoduleConfigurations: false,
>>> extensions: [],
>>> submoduleCfg: [],
>>> userRemoteConfigs: [
>>> [
>>> credentialsId: jenkinsCred,
>>> url: jenkinsRepo,
>>> ]
>>> ]
>>> ]
>>> );
>>>
>>> (Assume the "jenkinsCred" and "jenkinsRepo" values are correct.)  The
>>> failure looks like this:
>>>
>>> [Pipeline] {[Pipeline] checkoutusing credential 
>>> 29d83033-ebf6-4811-9c45-b0aadec775c2
>>>  > C:\cygwin64\bin\git.exe rev-parse --is-inside-work-tree # timeout=10
>>> Fetching changes from the remote Git repository
>>>  > C:\cygwin64\bin\git.exe config remote.origin.url g...@github.com:*/*.git 
>>> # timeout=10
>>> Fetching upstream changes from g...@github.com:*/*.git
>>>  > C:\cygwin64\bin\git.exe --version # timeout=10
>>> using GIT_SSH to set credentials Read-only access to the "Jenkins" 
>>> repository at github.com/*.
>>>  > C:\cygwin64\bin\git.exe fetch --tags --force --progress 
>>> g...@github.com:*/*.git +refs/heads/*:refs/remotes/origin/* # timeout=10
>>> ERROR: Error fetching remote repo 'origin'
>>> hudson.plugins.git.GitException: Failed to fetch from 
>>> g...@github.com:*/*.git
>>> at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
>>> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
>>> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
>>> at 
>>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)
>>> at 
>>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)
>>> at 
>>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)
>>> at 
>>> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>>> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>>> at java.util.concurrent.FutureTask.run(Unknown Source)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>> at java.lang.Thread.run(Unknown Source)
>>> Caused by: hudson.plugins.git.GitException: Command 
>>> "C:\cygwin64\bin\git.exe fetch --tags --force --progress 
>>> g...@github.com:*/*.git +refs/heads/*:refs/remotes/origin/*" returned 
>>> status code 128:
>>> stdout:
>>> stderr: error: cannot run 
>>> 

Re: gitSCM failed after updates

[Giles]

Nailed it in one.

I was sure it was a Jenkins issue ... but I'd upgraded Cygwin at the same 
time, and that probably included their version of git.  Which yes, is my 
default git.  I changed "Manage Jenkins" -> "Global Tool Configuration" -> 
git to the just-installed "Git for Windows", and ... fixed.  I may have to 
make some changes in the Jenkinsfiles themselves, but it seems clear now 
that the latest Cygwin git broke something, and that Git for Windows fixed 
it ...

This was crisis-level breakage for my department - I can't thank you enough.

On Tuesday, 11 June 2019 16:36:38 UTC-4, Mark Waite wrote:
>
> Are you quite sure that your configuration did not change in about the 
> same time as that upgrade?
>
> The log file indicates that you're running command line git as provided by 
> Cygwin.  Is that intentional?  Has it always been that way?  
>
> I don't test the Jenkins git plugin with Cygwin.  I test with Git for 
> Windows.  I'm glad cygwin git works, but don't intend to apply effort to 
> make it work.
>
> I don't see anything suspicious or troubling in the list of updates.  As 
> far as I can tell, none of them should have changed that behavior of the 
> git plugin.
>
> On Tue, Jun 11, 2019 at 1:54 PM Giles > 
> wrote:
>
>> I'm running Jenkins 2.164.3 on a Windows server.  It's been running well 
>> for several months.  Every Friday evening I do all the Jenkins plugin 
>> updates.  After this past Friday's updates (details below), all our jobs 
>> are broken - apparently because the GitSCM checkout is broken.  Our 
>> Jenkinsfiles are all stored in a git repo, so Jenkins attempts to pull a 
>> new version before running the job.  This now fails.  I created a test 
>> Jenkinsfile (editing directly in Jenkins rather than in the git repo) with 
>> this code in it:
>>
>> def scmVars = checkout(
>> [
>> $class: 'GitSCM',
>> branches: [[name: '*/' + branch ]],
>> doGenerateSubmoduleConfigurations: false,
>> extensions: [],
>> submoduleCfg: [],
>> userRemoteConfigs: [
>> [
>> credentialsId: jenkinsCred,
>> url: jenkinsRepo,
>> ]
>> ]
>> ]
>> );
>>
>> (Assume the "jenkinsCred" and "jenkinsRepo" values are correct.)  The 
>> failure looks like this:
>>
>> [Pipeline] {[Pipeline] checkoutusing credential 
>> 29d83033-ebf6-4811-9c45-b0aadec775c2
>>  > C:\cygwin64\bin\git.exe rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>  > C:\cygwin64\bin\git.exe config remote.origin.url g...@github.com:*/*.git 
>> # timeout=10
>> Fetching upstream changes from g...@github.com:*/*.git
>>  > C:\cygwin64\bin\git.exe --version # timeout=10
>> using GIT_SSH to set credentials Read-only access to the "Jenkins" 
>> repository at github.com/*.
>>  > C:\cygwin64\bin\git.exe fetch --tags --force --progress 
>> g...@github.com:*/*.git +refs/heads/*:refs/remotes/origin/* # timeout=10
>> ERROR: Error fetching remote repo 'origin'
>> hudson.plugins.git.GitException: Failed to fetch from g...@github.com:*/*.git
>>  at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
>>  at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
>>  at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
>>  at 
>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)
>>  at 
>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)
>>  at 
>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)
>>  at 
>> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>>  at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>>  at java.util.concurrent.FutureTask.run(Unknown Source)
>>  at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>  at java.lang.Thread.run(Unknown Source)
>> Caused by: hudson.plugins.git.GitException: Command "C:\cygwin64\bin\git.exe 
>> fetch --tags --force --progress g...@github.com:*/*.git 
>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>> stdout: 
>> stderr: error: cannot run 
>> D:\Jenkins\workspace\DEBUG_07_git_Checkout@tmp\jenkins-gitclient-ssh1436722960383118000.bat:
>>  No such file or directory
>> fatal: unable to fork
>>
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2318)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1905)
>>  at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:81)
>>  at 
>> 

Can multibranch pipeline support user-selected branch?

[Guy Knights]

I've been looking into multibranch pipeline and I'm wondering, can it be
configured to support build parameters to specify which branches will be
built?

I know the branch config can be setup with a regex to specify that certain
branches will be built, but it means that the same branches will be built
every time. I want whoever kicks off the job to be able to specify that
only particular branches will build at different times.

Thanks,
Guy

-- 
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/CANNH9msUkO1_Z3dF22%3D28qwToq%2BzfiNqcoe5ShHHfbVzN38G1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: no files matching the pattern C:\MyApp\bin\project.dll ERROR: no files matching the pattern C:\MyApp\bin\project.dll

[Nef Rey]

Tried that too. No go.  I found other blogs about the same thing and the 
answer seems to be use batch commands.  Those blogs were for old revisions 
so I figured that perhaps this was fixed by now.  Perhaps it was fixed some 
time ago and is now broke again.

On Tuesday, June 11, 2019 at 9:17:00 AM UTC-5, slide wrote:
>
> You could copy the files into the workspace from the location they are 
> currently in. Most Jenkins plugins will only act on things under the 
> workspace for good reasons (security for one).
>
> On Tue, Jun 11, 2019 at 7:13 AM Nef Rey > 
> wrote:
>
>> That would be a bummer... The files that I need to access are not in the 
>> workspace (its complicated). They are moved to another folder. I'm using 
>> the batch command for now, but wish I could use the plugin.
>>
>> On Tuesday, June 11, 2019 at 3:52:53 AM UTC-5, Richard Bywater wrote:
>>>
>>> Pure guess without looking at the plugin code or ever having used the 
>>> plugin but I'm guessing Test Files need to be specified as a relative path 
>>> within the workspace rather than an arbitrary file somewhere else on the 
>>> disk.
>>>
>>> Richard.
>>>
>>> On Tue, 11 Jun 2019 at 05:13, Nef Rey  wrote:
>>>
 I'm using a Windows10 installation of Jenkins 2.164.3. The 
 configuration for VSTest.Console plugin is like below Test Files = 
 C:\MyApp\bin\project.dll Test Name = /Tests:Test1 However I get the error: 
 no files matching the pattern C:\MyApp\bin\project.dll. Have tried 
 different things to no avail. I know I can use a windows batch command to 
 run the test cases with the same path and switch described above, but I 
 would like to use this plugging as it seems more elegant to use. IS there 
 a 
 fix for this??? 

 -- 
 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 jenkins...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/jenkinsci-users/16a70671-c27d-433c-9268-67cd848c7eee%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 jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/d17b02a2-24d6-4f89-9621-ad6a247db1e4%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Website: http://earl-of-code.com
>

-- 
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/0e87945b-850b-4a4d-98b2-60fbe878ea1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: gitSCM failed after updates

[Mark Waite]

Are you quite sure that your configuration did not change in about the same
time as that upgrade?

The log file indicates that you're running command line git as provided by
Cygwin.  Is that intentional?  Has it always been that way?

I don't test the Jenkins git plugin with Cygwin.  I test with Git for
Windows.  I'm glad cygwin git works, but don't intend to apply effort to
make it work.

I don't see anything suspicious or troubling in the list of updates.  As
far as I can tell, none of them should have changed that behavior of the
git plugin.

On Tue, Jun 11, 2019 at 1:54 PM Giles  wrote:

> I'm running Jenkins 2.164.3 on a Windows server.  It's been running well
> for several months.  Every Friday evening I do all the Jenkins plugin
> updates.  After this past Friday's updates (details below), all our jobs
> are broken - apparently because the GitSCM checkout is broken.  Our
> Jenkinsfiles are all stored in a git repo, so Jenkins attempts to pull a
> new version before running the job.  This now fails.  I created a test
> Jenkinsfile (editing directly in Jenkins rather than in the git repo) with
> this code in it:
>
> def scmVars = checkout(
> [
> $class: 'GitSCM',
> branches: [[name: '*/' + branch ]],
> doGenerateSubmoduleConfigurations: false,
> extensions: [],
> submoduleCfg: [],
> userRemoteConfigs: [
> [
> credentialsId: jenkinsCred,
> url: jenkinsRepo,
> ]
> ]
> ]
> );
>
> (Assume the "jenkinsCred" and "jenkinsRepo" values are correct.)  The
> failure looks like this:
>
> [Pipeline] {[Pipeline] checkoutusing credential 
> 29d83033-ebf6-4811-9c45-b0aadec775c2
>  > C:\cygwin64\bin\git.exe rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > C:\cygwin64\bin\git.exe config remote.origin.url g...@github.com:*/*.git # 
> timeout=10
> Fetching upstream changes from g...@github.com:*/*.git
>  > C:\cygwin64\bin\git.exe --version # timeout=10
> using GIT_SSH to set credentials Read-only access to the "Jenkins" repository 
> at github.com/*.
>  > C:\cygwin64\bin\git.exe fetch --tags --force --progress 
> g...@github.com:*/*.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> ERROR: Error fetching remote repo 'origin'
> hudson.plugins.git.GitException: Failed to fetch from g...@github.com:*/*.git
>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
>   at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
>   at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
>   at 
> org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)
>   at 
> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)
>   at 
> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)
>   at 
> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>   at java.util.concurrent.FutureTask.run(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>   at java.lang.Thread.run(Unknown Source)
> Caused by: hudson.plugins.git.GitException: Command "C:\cygwin64\bin\git.exe 
> fetch --tags --force --progress g...@github.com:*/*.git 
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> stdout:
> stderr: error: cannot run 
> D:\Jenkins\workspace\DEBUG_07_git_Checkout@tmp\jenkins-gitclient-ssh1436722960383118000.bat:
>  No such file or directory
> fatal: unable to fork
>
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2318)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1905)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:81)
>   at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:488)
>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
>   ... 11 more[Pipeline] }[Pipeline] // node[Pipeline] End of 
> PipelineERROR: Error fetching remote repo 'origin'
> Finished: FAILURE
>
> This is essentially identical to the failure we're seeing for all jobs.  I 
> assume it's normal behaviour that GitSCM generates and
> tries to run a random-named bat file?  It's unclear to me if the bat file 
> isn't created or is unreadable, although Jenkins is running
> as SYSTEM and has generally been able to read and write everything.
>
> Does anyone have any thoughts on what may have gone wrong?
>
>  -
>
>
> The updates made Friday night:
>
> >>> Artifactory 3.2.2 -> 

Re: jenkins build history with status for the given period

[Rakesh Nair]

Hi Panneer,

I guess you can make use of api provided by jenkins to get above details
regarding build. You can try below link to know how to fetch details from
jenkins api.

https://github.com/jenkinsci/pipeline-stage-view-plugin/blob/master/rest-api/README.md


On Tue, Jun 11, 2019, 5:31 AM panneerrselvam natarajan 
wrote:

> Hi All,
>
> We are running Jenkins on Unix environment and execution the pipeline with
> different stages including Unit Testing. Now I want to generate the report
> for given period with following details
>
> Like below
>
> Build Number
> Execution date
> UnitTest Pass or Fail .
> Each stage pass or fail
> Build pass or fail
>
>
> Do we need to install any plug in or shall we create the xml file and
> append the record. Please guide us.
>
> Regards
> Panneer
>
> --
> 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/95f80cf2-cd23-4378-bcd3-c74114b319b2%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/CANhPVKQ_wgO5VQ8ppiMOqVuzmP5LLVnPh_Hws0wM_EuA7h9k3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

gitSCM failed after updates

[Giles]

I'm running Jenkins 2.164.3 on a Windows server.  It's been running well 
for several months.  Every Friday evening I do all the Jenkins plugin 
updates.  After this past Friday's updates (details below), all our jobs 
are broken - apparently because the GitSCM checkout is broken.  Our 
Jenkinsfiles are all stored in a git repo, so Jenkins attempts to pull a 
new version before running the job.  This now fails.  I created a test 
Jenkinsfile (editing directly in Jenkins rather than in the git repo) with 
this code in it:

def scmVars = checkout(
[
$class: 'GitSCM',
branches: [[name: '*/' + branch ]],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [
[
credentialsId: jenkinsCred,
url: jenkinsRepo,
]
]
]
);

(Assume the "jenkinsCred" and "jenkinsRepo" values are correct.)  The 
failure looks like this:

[Pipeline] {[Pipeline] checkoutusing credential 
29d83033-ebf6-4811-9c45-b0aadec775c2
 > C:\cygwin64\bin\git.exe rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > C:\cygwin64\bin\git.exe config remote.origin.url g...@github.com:*/*.git # 
 > timeout=10
Fetching upstream changes from g...@github.com:*/*.git
 > C:\cygwin64\bin\git.exe --version # timeout=10
using GIT_SSH to set credentials Read-only access to the "Jenkins" repository 
at github.com/*.
 > C:\cygwin64\bin\git.exe fetch --tags --force --progress 
 > g...@github.com:*/*.git +refs/heads/*:refs/remotes/origin/* # timeout=10
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from g...@github.com:*/*.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)
at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)
at 
org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)
at 
org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: hudson.plugins.git.GitException: Command "C:\cygwin64\bin\git.exe 
fetch --tags --force --progress g...@github.com:*/*.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error: cannot run 
D:\Jenkins\workspace\DEBUG_07_git_Checkout@tmp\jenkins-gitclient-ssh1436722960383118000.bat:
 No such file or directory
fatal: unable to fork

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2318)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1905)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:81)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:488)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
... 11 more[Pipeline] }[Pipeline] // node[Pipeline] End of 
PipelineERROR: Error fetching remote repo 'origin'
Finished: FAILURE

This is essentially identical to the failure we're seeing for all jobs.  I 
assume it's normal behaviour that GitSCM generates and
tries to run a random-named bat file?  It's unclear to me if the bat file isn't 
created or is unreadable, although Jenkins is running
as SYSTEM and has generally been able to read and write everything.

Does anyone have any thoughts on what may have gone wrong?

 -


The updates made Friday night:

>>> Artifactory 3.2.2 -> 3.2.4  [ security warning 
]
>>> Pipeline: API 2.34 -> 
2.35  
>>> Pipeline: Basic Steps 2.16 -> 
2.18  
>>> Pipeline: Declarative 1.3.8 -> 
1.3.9
>>> Pipeline: Declarative Extension Points API 1.3.8 -> 
1.3.9   
>>> Pipeline: Groovy 2.69 -> 
2.70   
>>> Pipeline: Model API 1.3.8 -> 
1.3.9   
>>> Pipeline: Nodes and Processes 2.30 -> 
2.31
>>> Pipeline: SCM Step 2.7 -> 
2.9  

Docker content trust from pipelines

[Albert Domenech]

I have an unsolved annoying issue regarding Jenkins pipelines and Docker 
Content Trust, I hope someone can give me a hand with it.

I'm using Harbor as private registry and I activated Content Trust on my 
laptop's Docker daemon. Whenever I push a new Image to the registry 
manually from the shell, the daemon signs the Image as expected using my 
local signing keys.

Then I followed the delegation process to allow Jenkins user to do the 
same. I created specific signing keys for it and added them to the registry 
from my laptop, so now Jenkins user is an allowed signer for specific 
projects.

If I create and push new images from the Jenkins OS user shell, everything 
goes as expected also, meaning that the images are signed and pushed to the 
registry with all the meta info needed.

The problem comes when I try to do the same from a Pipeline, for some 
strange reason, Docker is not able to find the signing keys, so the image 
is pushed but not signed. I tried in different ways, but always with the 
same result. "no valid signing keys for delegation roles"

Curious thing that I observed is that "docker trust inspect ..." works both 
ways (from shell and pipeline) and shows Jenkins user as an allowed signer, 
but "notary key list" only works from the pipeline if I add "--configFile 
~/.notary/config.json" parameter that in fact points to the default 
configuration path

Here a partial extract from the stage I'm using:

script {
  withEnv(['DOCKER_CONTENT_TRUST=1',
'DOCKER_CONTENT_TRUST_SERVER=https://harbor.example.com:4443']) {
withCredentials([usernamePassword(credentialsId: 
"harbor_jenkins_credentials", usernameVariable: "HARBOR_USERNAME", 
passwordVariable: "HARBOR_PASSWORD")]) {
  sh "docker login --username=$HARBOR_USERNAME 
--password=$HARBOR_PASSWORD harbor.example.com"
}
withCredentials([string(credentialsId: 
'docker-content-trust-repository-passphrase', variable: 
'DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE'),
 string(credentialsId: 'docker-content-trust-root-passphrase', variable: 
'DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE')]) {
  sh """#!/bin/bash
printenv
notary --configFile ~/.notary/config.json key list
docker trust inspect --pretty harbor.example.com/services/test
docker push harbor.example.com/services/test:${nextTag}
docker push harbor.example.com/services/test:${commitHash}
docker push harbor.example.com/services/test:latest
  """
}
  }
 }


-- 
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/79ccc6f9-d3f5-453b-9739-4b9b886a555d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: no files matching the pattern C:\MyApp\bin\project.dll ERROR: no files matching the pattern C:\MyApp\bin\project.dll

[Slide]

You could copy the files into the workspace from the location they are
currently in. Most Jenkins plugins will only act on things under the
workspace for good reasons (security for one).

On Tue, Jun 11, 2019 at 7:13 AM Nef Rey  wrote:

> That would be a bummer... The files that I need to access are not in the
> workspace (its complicated). They are moved to another folder. I'm using
> the batch command for now, but wish I could use the plugin.
>
> On Tuesday, June 11, 2019 at 3:52:53 AM UTC-5, Richard Bywater wrote:
>>
>> Pure guess without looking at the plugin code or ever having used the
>> plugin but I'm guessing Test Files need to be specified as a relative path
>> within the workspace rather than an arbitrary file somewhere else on the
>> disk.
>>
>> Richard.
>>
>> On Tue, 11 Jun 2019 at 05:13, Nef Rey  wrote:
>>
>>> I'm using a Windows10 installation of Jenkins 2.164.3. The
>>> configuration for VSTest.Console plugin is like below Test Files =
>>> C:\MyApp\bin\project.dll Test Name = /Tests:Test1 However I get the error:
>>> no files matching the pattern C:\MyApp\bin\project.dll. Have tried
>>> different things to no avail. I know I can use a windows batch command to
>>> run the test cases with the same path and switch described above, but I
>>> would like to use this plugging as it seems more elegant to use. IS there a
>>> fix for this???
>>>
>>> --
>>> 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 jenkins...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/16a70671-c27d-433c-9268-67cd848c7eee%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/d17b02a2-24d6-4f89-9621-ad6a247db1e4%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Website: http://earl-of-code.com

-- 
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/CAPiUgVeEBV_Pz7q_wD%3DfPHgBk_-jsECK7UNy83DQR8gSUY%3D%2B2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: no files matching the pattern C:\MyApp\bin\project.dll ERROR: no files matching the pattern C:\MyApp\bin\project.dll

[Nef Rey]

That would be a bummer... The files that I need to access are not in the 
workspace (its complicated). They are moved to another folder. I'm using 
the batch command for now, but wish I could use the plugin.

On Tuesday, June 11, 2019 at 3:52:53 AM UTC-5, Richard Bywater wrote:
>
> Pure guess without looking at the plugin code or ever having used the 
> plugin but I'm guessing Test Files need to be specified as a relative path 
> within the workspace rather than an arbitrary file somewhere else on the 
> disk.
>
> Richard.
>
> On Tue, 11 Jun 2019 at 05:13, Nef Rey > 
> wrote:
>
>> I'm using a Windows10 installation of Jenkins 2.164.3. The configuration 
>> for VSTest.Console plugin is like below Test Files = 
>> C:\MyApp\bin\project.dll Test Name = /Tests:Test1 However I get the error: 
>> no files matching the pattern C:\MyApp\bin\project.dll. Have tried 
>> different things to no avail. I know I can use a windows batch command to 
>> run the test cases with the same path and switch described above, but I 
>> would like to use this plugging as it seems more elegant to use. IS there a 
>> fix for this??? 
>>
>> -- 
>> 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 jenkins...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/16a70671-c27d-433c-9268-67cd848c7eee%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/d17b02a2-24d6-4f89-9621-ad6a247db1e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to write a yaml configuration for certificate with JCasC plugin?

[Andreas Magnusson]

Upgraded to 1.20 and I got the same error. 
Sigh, wish they could actually get the syntax set once and for all. 

-- 
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/f2928b25-3d7d-4893-aadb-ef8a1c98b869%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to write a yaml configuration for certificate with JCasC plugin?

[Andreas Magnusson]

Hi, this matches my config which looks like this:
  - certificate:
  id: "our-keystore"
  description: "certificate-alias"
  keyStoreSource:
fileOnMaster:
  keyStoreFile: 
"/var/jenkins_conf/secrets/ComodoCodeSigning2018.p12"
  password: "password..."
  scope: "GLOBAL"
This worked on 1.15, haven't had time to update to latest version since.
But note that I found out that I had to put the alias in the description. I 
think I had to read the code for the plugin to understand that little 
nugget...

/Andreas

-- 
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/12839eac-20ef-4720-b08e-cab86d583235%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to write a yaml configuration for certificate with JCasC plugin?

[Andreas Magnusson]

This matches my configuration except that I had to add the alias of the 
certificate as "description". Not sure if that was the error I got though. 
Eveything else matches my config.
/Andreas

-- 
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/071c40a0-3793-4dec-a584-48554927139a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Where is build.properties?

[ABostonGal ABostonGal]

Inherited project with little documentation and less experience with 
actually managing ant builds.

My understanding is that build.xml can get its property values from a file 
called build.propoerties.

My problem is: I cannot find "build.properities" anywhere in the project 
code nor on the build machines.

In this case, there are developer machines and then the machine on which 
the code compiles.

So I find a build.xml for the project and on the machine that builds, the 
ant batch file which will use the build.xml...

Help?

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/a32b6c52-cf78-49b0-bd15-c378424c79de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: Shell step oddity removes escaped slash

[Sverre Moe]

I have the following Pipeline step to find specific files:
sh("find . -regex '.*${packageName}-[0-9.]+-.\\.noarch\\.rpm'")

The Output:
[Pipeline] sh
+ find . -regex '.*package-name-[0-9.]+-.\.noarch\.rpm'
This does not return any result.

Both of these two works in Bash:
find . -regex '.*meos-dashboard-[0-9.]+-.\.x86_64\.rpm'
find . -regex .*meos-dashboard-[0-9.]+-.\.x86_64\.rpm

This groovy code work:
def find = "find . -regex .*package-name-[0-9.]+-.\\.noarch\\.rpm".execute()
println find.text

This groovy code does not work:
def find = "find . -regex '.*package-name-[0-9.]+-.\\.noarch\\.rpm'".execute
()
println find.text


So it seems Groovy does not work with surrounding the regex with single 
quote. Trying without does not go so well either:
sh("find . -regex .*${packageName}-[0-9.]+-.\\.noarch\\.rpm")

The output:
[Pipeline] sh
+ find . -regex '.*package-name-[0-9.]+-..noarch.rpm'
Pipeline seems to remove the "\" from the regular expression when I am not 
using the single quote.


Any idea what is the problem here? Pipeline or Groovy?

-- 
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/a8a22c0b-d707-4fdc-b41c-91e8b12d756a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: no files matching the pattern C:\MyApp\bin\project.dll ERROR: no files matching the pattern C:\MyApp\bin\project.dll

[Richard Bywater]

Pure guess without looking at the plugin code or ever having used the
plugin but I'm guessing Test Files need to be specified as a relative path
within the workspace rather than an arbitrary file somewhere else on the
disk.

Richard.

On Tue, 11 Jun 2019 at 05:13, Nef Rey  wrote:

> I'm using a Windows10 installation of Jenkins 2.164.3. The configuration
> for VSTest.Console plugin is like below Test Files =
> C:\MyApp\bin\project.dll Test Name = /Tests:Test1 However I get the error:
> no files matching the pattern C:\MyApp\bin\project.dll. Have tried
> different things to no avail. I know I can use a windows batch command to
> run the test cases with the same path and switch described above, but I
> would like to use this plugging as it seems more elegant to use. IS there a
> fix for this???
>
> --
> 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/16a70671-c27d-433c-9268-67cd848c7eee%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/CAAy0hwesANNKUAfZbSEmCr0ujkfsJW3oe4k1fD__Hz2w6sGr3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.