Re: Jenkins List Files of Git Branch

2019-10-11 Thread Mark Waite
The git ls-remote command is not allowed to list remote files, only remote 
references (branches and tags).

Git providers (GitHub, Bitbucket, Gitea, Assembla, Beanstalk, Gitlab, etc.) 
generally provide one or more REST API's that will list remote files in a 
branch.

On Thursday, October 10, 2019 at 11:37:34 PM UTC-8, Ajay Sharma wrote:
>
> Hi Everyone, Good Morning.
>
> Request any ones help to List All FILES from the GIT BRANCH.  
> I am trying to first list Branches of a GIT REPO, then list the files of 
> the BRANCH. 
>
> I am facing problem while listing files of the BRANCH. 
>
> I have used this code List files Of the GIT REPO with   *Extended Choice 
> Parameter*. 
>
> def gettags = ("git ls-remote -t -h 
> http://pramod:username.password@10.112.78.152/pramod/automaticjobs.git
> ").execute()
> return gettags.text.readLines().collect { 
>   it.split()[1].replaceAll('refs/heads/', '').replaceAll('refs/tags/', 
> '').replaceAll("\\^\\{\\}", '')
> }
>
> BUT this code is not working for Listing the Files of the GIT BRANCH. 
>
> def gettags = ("git ls-remote -t -h 
> http://pramod:usernamepassword@10.112.78.152/pramod/automaticjobs.git -r 
> {env.Branches}").execute()
> return gettags.text.readLines().collect { 
>   it.split()[1].replaceAll('refs/heads/', '').replaceAll('refs/tags/', 
> '').replaceAll("\\^\\{\\}", '')
> }
>
>
>
>

-- 
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/ad6d0852-7c2b-494d-a929-30043da22b5c%40googlegroups.com.


Re: create a local linux machine as a slave for aws ec2 cloud jenkins

2019-10-11 Thread Mark Waite
https://wiki.jenkins.io/display/JENKINS/Distributed+builds describes the
alternatives available and the reasons for those alternatives.

If your local machine is not directly accessible to your EC2 master or if
it is a Windows computer, then you are likely unable to initiate the
connection from the master to the agent.  That means you can't use the
ssh-slaves connection technique.  You'll likely need to use the JNLP based
technique that allows you to initiate a connection from the agent to the
master.

On Fri, Oct 11, 2019 at 6:14 AM gopi dasari 
wrote:

> HI All,
>
> I am very new to Jenkins,
>
> I want to create my local machine as a slave for aws ec2 cloud Jenkins to
> run the jobs. anyone please help me how to create a slave machine to ec2
> jenkins-master.
>
>
>
> [image: jenkins master-slave.png]
>
> --
> 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/69d8b34e-959e-4ec2-848e-12a46fdbd829%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/69d8b34e-959e-4ec2-848e-12a46fdbd829%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFTeTVUN4FMCRPxsi4nEfsmWwgdVMcDk99bJ4Y8mfcZhQ%40mail.gmail.com.


Re: Restrict credential retrieval to a specific slave

2019-10-09 Thread Mark Waite
I am not aware of anyone working to allow credentials to be limited to an
agent.  I believe the same capabilities are available by assigning the
credentials to folders and then limiting user access to specific folders.
Choose a credential name that should be the same in several different
folders, then define the credential with the value specific to the folder
that is using it.

The test jobs would reside in a "Test-Folder" and refer to a credential
named 'credential-2019-10-10'.  In that folder, the value of the credential
should be chosen so that it only allows access to things related to test.

The development jobs would reside in a "Development-Folder" and refer to a
credential named 'credential-2019-10-10'.  In that folder, the value of the
credential should be chosen so that it only allows access to things related
to development.

The jobs reference the same credential but since the credentials are
defined inside the folder, they are only accessible to jobs in that folder
(and below).

On Wed, Oct 9, 2019 at 12:55 AM Pietro Giannini  wrote:

> Hi!
>
> I just came across this post and realized this is exactly what we need. We
> are heavily using pipelines at our agency and being able to restrict
> credentials to a specific node would enable us to give total freedom the
> developers while keeping control of the passwords at infra level.
>
> Is there any chance we could get this feature onboard?
>
> Br,
> Pietro
>
>
>
> On Friday, September 20, 2019 at 3:07:27 PM UTC+2, Jhonny Oliveira wrote:
>>
>> Dear Mark,
>>
>> I understand your suggestion, however in such case you would have to
>> create multiple jobs, whereas, as it is right now, I only need one. No
>> parameters, no additional settings just the minimal configuration to pick
>> up the changes, build, test and deploy. I even get for free all the
>> statistics together.
>>
>> Nevertheless, I will try to come with an alternative solution. I believe
>> your input may be valuable in there.
>>
>> Thank you very much,
>> J Oliveira
>>
>> --
> 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/25d0de20-d7c4-4336-8645-d6302768d2db%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/25d0de20-d7c4-4336-8645-d6302768d2db%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFkgNGtp5KeMTC5aKtSBcDB8QmHkypF1DzfeFj39Vg_Qw%40mail.gmail.com.


Re: gitSCM failed after updates

2019-09-29 Thread Mark Waite
On Sun, Sep 29, 2019 at 6:47 PM 'Henry Xu' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Hi, thanks for your suggestion. I downgrade the git from 2.21.0 to 2.17.1
> (the version I used on the old machine) and anything work fine. I am
> wondering why the git version may cause issue of this kind.
>
>
The cygwin environment may have changed how it launches subprocesses.  The
cygwin environment may have changed how it is invoked from Windows.
Command line git may have changed something which causes the damage.

The Jenkins git plugin is not tested with cygwin.  This mail message thread
has strong indications (you and one other user) that the most recent
command line git that is available with cygwin does not work with the
Jenkins git plugin.  I'm glad that it works for you with git 2.17.1, but I
don't test with cygwin and won't test with cygwin in the future.


> On Monday, September 30, 2019 at 8:01:52 AM UTC+8, Mark Waite wrote:
>>
>>
>>
>> On Sun, Sep 29, 2019 at 5:12 PM Henry Xu  wrote:
>>
>>> I guess I have same issue. And it's wired as it works will on a machine
>>> I provisioned a year ago. Can you kindly provide more detail about how to
>>> using Global Tool Configuration to fix this problem? Thanks in advance.
>>>
>>>
>> The Jenkins global tool configuration won't fix the problem, at least as
>> far as I know.
>>
>> If you have the same problem, then you are running Windows, have
>> installed cygwin, and have configured Jenkins to use the git program that
>> is available with cygwin.  The solution is to install git for Windows and
>> assure that it is the program which is used by Jenkins, instead of the git
>> program that is available with cygwin.  The Jenkins git plugin does not
>> test with the command line git version that is included with cygwin.  It
>> tests with git for Windows.
>>
>> Another alternative (for many use cases) is to enable JGit as a git
>> implementation in your Jenkins server, then configure the job to use JGit
>> instead of command line git.  JGit is able to run most use cases, but not
>> all use cases that are supported by command line git.  Refer to
>> https://plugins.jenkins.io/git-client for instructions to enable JGit in
>> your installation.
>>
>>
>>>
>>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>>> --force --progress xxx +refs/heads/*:refs/remotes/Fiji/* --prune" returned 
>>> status code 128:
>>> stdout:
>>> stderr: error: cannot run c:\jws2\workspace\xxx\ssh7984855687134194056.bat: 
>>> No such file or directory
>>> fatal: unable to fork
>>>
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72)
>>> at 
>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:212)
>>> at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>>> at hudson.remoting.Request$2.run(Request.java:369)
>>> at 
>>> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>>> 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)
>>> Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
>>> SDET-XMN160
>>> at 
>>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
>>> at 
>>> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>>> at hudson.remoting.Channel.call(Channel.java:957)
>>> at 
>>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
>>> at sun.reflect.GeneratedMethodAccessor709.invoke(Unknown Source)
>>&

Re: gitSCM failed after updates

2019-09-29 Thread Mark Waite
;
> On Wednesday, June 12, 2019 at 5:09:22 AM UTC+8, 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.

Re: Updating Corp to Corp list!

2019-09-26 Thread Mark Waite
I banned this person from the list.  We don't accept recruiting e-mail 
messages on the Jenkins users mailing list.

On Thursday, September 26, 2019 at 4:03:01 PM UTC-6, Srujan Reddy wrote:
>
> Hi All!
>
>  
>
> I am updating my Corp to Corp list. Looking to partner with Employers who 
> can support us with genuine consultants on skills like Fullstack Developers 
> (Java / .Net), Angular Developers, ReactJS Developers, Devops Engineer, 
> Python Developers / Data Engineer with Python,Informatica Developer, QA 
> Engineer, SAP. Etc, 
>
>  
>
>  
>
>  
>
> Thanks & Regards
>
>  
>
>  
>
> Srujan Reddy
>
> Senior Technical Recruiter
>
> Work: +1 734-928-2001 Ext:431
>
> Direct: +1 209-896-8718
>
> Web: www.greatlogics.com
>
> 32770 Grand River Avenue, Suite 206B,
>
> Farmington Hills, MI-48336   
>
>  
>

-- 
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/98756955-a4b3-456e-a46b-ba4af82b09a7%40googlegroups.com.


Re: Heavy checkouts for pull requests take a lot of disk space on our master server

2019-09-24 Thread Mark Waite
If the Bitbucket branch source allows it, you can create a reference
repository on the master and add the extension to enable use of the
reference repository during checkout.

Refer to https://youtu.be/jBGFjFc6Jf8?t=6434 for hints on handling large
git repos (Jenkins World 2017 lightning talk on "Git in the Large").  I
updated the slides in a Jenkins World 2019 post at
https://www.slideshare.net/markewaite/git-for-jenkins-faster-and-better

On Tue, Sep 24, 2019 at 5:06 AM Damien Garrido <
damien.garrido.w...@gmail.com> wrote:

> Hello,
>
> While using the Bitbucket Branch Source plugin version 2.4.0 along with
> the Stash Pullrequest Builder plugin version 1.7.0, when a change request
> is processed by Jenkins, a preliminary checkout is done on the master
> server in order to retrieve the Jenkinsfile, i.e. the "Checking out git
>  into  folder>/workspace@script to read Jenkinsfile" message.
>
> Once the Jenkinsfile has been retrieved, and even if it is the only file
> needed (?), no clean up of the checkout is done on the master server.
> A second checkout is done afterward on our ephemeral agents to do the
> merge actions and the build.
>
> The point is that, since the workspaces with the checkouts stay on the
> Jenkins master server, we rapidly run out of disk space on the master
> server because of some heavy Git repositories with a lot of Pull Requests.
>
> Is there an option or a way to clean the workspace checkouts on the master
> server after the Jenkinsfile has been retrieved ?
>
> Thank you for your help !
>
> Damien
>
> --
> 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/b230aa74-6598-454d-a052-1b573fba2954%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/b230aa74-6598-454d-a052-1b573fba2954%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEUSKPbgh%3DbvHx_cX1sUDch%2B2%3D_TD96bnARUcrjkUADvQ%40mail.gmail.com.


Re: Match multiple branches with Git plugin

2019-09-22 Thread Mark Waite
You didn't mention the type of job you're using.

If you're using a Freestyle job, it should work exactly as you desire,
detecting changes on all the branches that match the wildcard.  It works
that way for me on several jobs that I use.  A Freestyle job processing
multiple branches tends to confuse users, since they need to look deeply
into the job to decide which branch was used on each build.  It is less and
less common to use a Freestyle project that builds multiple branches.

If you're using a Pipeline job, then you should consider using a
Multibranch Pipeline job rather than reusing the same job for different
branches.  A multibranch Pipeline job will automatically create and delete
jobs for all branches that are detected and contain a Jenkinsfile.

On Thu, Sep 19, 2019 at 7:33 AM Technical Lead 
wrote:

> Hi, I'm trying to use the Git plugin (with the GitHub plugin) to trigger
> builds on multiple branches with a single branch specifier rule.  However,
> the job only appears to trigger when there are changes to on the "first"
> matching branch.  I've tried wildcards (i.e. origin/dev/*) and regexes
> (i.e. :^origin/dev/.*), to no avail.  The limited documentation sort of
> indicates that the wildcard method would only use the first matching
> branch, but it's unclear for a regex.  I'd rather not reconfigure the job
> every time a new branch is added to list it explicitly in a branch
> specifier.
>
> --
> 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/76d496e6-edea-4ff9-b317-bdc69481f955%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/76d496e6-edea-4ff9-b317-bdc69481f955%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHotrqjW75x1XsAZEHqpXaWej4v_0sg0Voujw6DXzVtbA%40mail.gmail.com.


Re: Install Jenkins as WAR file or Install using package installers?

2019-09-22 Thread Mark Waite
My opinion and Linux centric -

If you need a Jenkins installation that starts easily, runs easily, and
upgrades easily, and don't care as much about being able to repeatably
create that exact same installation and all its configuration on another
machine, use the package installer, especially the Linux package installers
(CentOS, Debian, Red Hat, Ubuntu).  You can use Jenkins configuration as
code to configure this just as any of the others, but don't add the
complexity of managing a Docker image.

If you need a Jenkins installation that you can consistently create the
same installation on different machines, then choose a Docker based
installation.  Docker installations use the war file and allow you to
specify your custom additions.

If you have a platform that does not provide a package installer, then use
the war file.

Mark Waite

On Sun, Sep 22, 2019 at 8:01 AM ABostonGal ABostonGal 
wrote:

> Why would I choose to install Jenkins as a WAR file instead of using a
> package installer?
>
>
> --
> 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/accaa206-178a-4a76-8c4d-e7b70ff9f7a8%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/accaa206-178a-4a76-8c4d-e7b70ff9f7a8%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEoCBUdXEwZCP0KJXnwnmTHOJaWY49b%3DaUnzaAN3U5L2Q%40mail.gmail.com.


Re: SSH agent uses username 'jenkins' instead of the one configured in the credential

2019-09-20 Thread Mark Waite
On Thu, Sep 19, 2019 at 1:56 AM DexterMagnific 
wrote:

> Thank you for your response.
>
> I'm afraid I'm using the latest Git client plugin: 2.8.6, and also the
> right protocol (ssh): the SCM checkout went well when running the pipeline
> on the parent repo. Out test database is a submodule of the repository and
> we only clone it if the build is OK, hence the stage "download test db":
>
> jenkins@192.168.20.23: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
> fatal: clone of 'ssh://192.168.20.23:29418/testDB' into submodule path
> '/var/lib/jenkins/workspace/MyProject/testDB' failed
> Failed to clone 'testDB'. Retry scheduled
>
>
The URL in the output, 'ssh://192.168.20.23:29418/testDB', indicates that
the username is not included in the URL.  In the absence of a user name in
the URL, the user name of the current user is used.  That is standard git
and ssh behavior, not something that the git plugin controls.


> You see that I did not include an URL in the git command because I only
> want to checkout the submodules.
>
> Regarding openSSH, I think I'm up to date, I'm using the latest Ubuntu
> 18.04 packages.
>
>
> On Thursday, September 19, 2019 at 2:19:55 AM UTC+2, Mark Waite wrote:
>>
>> If you're running an outdated version of the git client plugin and a
>> newer version of OpenSSH (7.7 and later), then you might be encountering
>> https://issues.jenkins-ci.org/browse/JENKINS-50573 .  Git plugin
>> versions prior to
>>
>> If you're running the current git client plugin (2.8.6) or running an
>> OpenSSH older than 7.7, then you might be mistakenly using an http or https
>> protocol URL.  The ssh protocol is either ssh://hostname/dir/path or
>> username@hostname:dir/path.  `git remote -v` will report the URL of the
>> remote in that repository.
>>
>> On Tue, Sep 17, 2019 at 4:27 AM DexterMagnific 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have big troubles making 'git' commands inside a pipeline file.
>>>
>>> I have the following command:
>>>
>>>  stage('Download test database') {
>>>   steps {
>>> sshagent(credentials: ['----'])
>>> {*/
>>>   sh 'git submodule update --init --recursive'
>>> }
>>>   }
>>> }
>>>
>>> The problem is that git is called with the user 'jenkins' instead of the
>>> one that is specified inside the credential (which is 'jenkins-serv') I get
>>> a "permission denied" from the git server.
>>>
>>> [Pipeline] // stage
>>> [Pipeline] stage
>>> [Pipeline] { (Download test database)
>>> [Pipeline] sh
>>> + git submodule update --init --recursive
>>> Cloning into '/var/lib/jenkins/workspace/MyProject/testDB'...
>>> jenkins@192.168.20.23: Permission denied (publickey).
>>> fatal: Could not read from remote repository.
>>>
>>>
>>> Did I miss something on the pipeline setup ?
>>>
>>> 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 jenkins...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-users/b5f85d92-adfd-496c-b7c8-2d7a34ad4b21%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/b5f85d92-adfd-496c-b7c8-2d7a34ad4b21%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
> --
> 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/8a34fbbe-80e3-41f5-b501-10e0582079d8%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/8a34fbbe-80e3-41f5-b501-10e0582079d8%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFGPtR17pfuhyf_JUtK9pDzStU1-zwp6Vp%2BPqLaNeFgvg%40mail.gmail.com.


Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Mark Waite
On Thu, Sep 19, 2019 at 8:41 AM Jhonny Oliveira 
wrote:

> Dear Mark,
>
> I agree with you, I'm relying on long-lived agents. I read your answer,
> but I'm not understanding your suggestion to use folders, I do not
> comprehend how they can help. I mean, with folders I can avoid cross
> application credential usage and that is great, but I can't prevent cross
> environment credential leakage within the same application.
>
>
My suggestion is

   - Dev-Folder defines a credential (scoped to Dev-Folder) with ID
   'weblogic-deploy-credential-2019-09-19'
  - Job inside Dev-Folder refers to credential
  'weblogic-deploy-credential-2019-09-19 ' and uses it to deploy to dev
   - Test-Folder defines a credential (scoped to Test-Folder) with ID '
   weblogic-deploy-credential-2019-09-19'
  -   Job inside Test-Folder refers to credential
  'weblogic-deploy-credential-2019-09-19 ' and uses it to deploy to test

The same source code can be used for the job inside Dev-Folder and the job
inside Test-Folder if the other things that vary between dev and test are
also parameterized in that job.  In the case you provided, rather than
URL_TST and URL_DEV, you would define a parameter DESTINATION_URL and would
pass in the test value.  The "folder properties" plugin looks like it may
be needed in that case so that each folder can have its own value for the
DESTINATION_URL without requiring that developers pass the parameter to the
job.

If a malicious developer in Dev-Folder modifies their Jenkinsfile to deploy
to test, it will be rejected because the credentials in the Dev-Folder
don't have permission to deploy to test.

If a malicious developer in Dev-Folder modifies their Jenkinsfile to
display the values of the credentials, only the credentials from the
Dev-Folder will be exposed.


> Please have a look at the code snippet below. As you will be able to see,
> with this implementation nothing prevents anyone with access to the source
> code from flipping the IDs around and getting the credentials in the wrong
> environment (mistake or malicious action). Furthermore, and to give a
> little extra context, the Pipeline is completely autonomous and will be
> triggered automatically on every (almost) pull request. It is also smart
> enough to detect a release and proceed towards production (with some
> approvals - of course - to adhere to release management).
>
> In such scenario, and considering that the agents only have access to
> their own environment, the only way to prevent a credential to be used or
> exposed in the wrong one would be to deliberately restrict it to that
> specific agent.
>
> Maybe I'm taking this idea of automation and complete SDLC from source to
> far! :-)
>
> I appreciate your answers, thanks you!
> J. Oliveira
>
> def WLS_CRED_DEV=’111aaa11-a3a1-4aab-9a20-a1166a80’
> def WLS_CRED_TST=’222aaa11-a3a1-4aab-9a20-a1166a80 ‘
> (…)
> stage ('Deploy to DEV') {
> agent { label "${agent_dev}"}
> steps {
> script {
>
> withCredentials([usernamePassword(credentialsId: "$WLS_CRED_DEV",
> usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
> sh "mvn -U
> weblogic:redeploy -DskipTests=true -Dfailonerror=true -Duser='${WL_USER}'
> -Dpassword='${WL_PASS}' -Dname=${ARTIFACTID} -Dupload=true
> -Dsource=target/${ARTIFACTID}-${VERSION}.war -Dtargets=${ARTIFACTID}
> -Dadminurl='${URL_DEV}'"
> }
> }
> }
> }
> stage ('Deploy to TST) {
> agent { label "${agent_tst}"}
> steps {
> script {
>
> withCredentials([usernamePassword(credentialsId: "$WLS_CRED_TST",
> usernameVariable: 'WL_USER', passwordVariable: 'WL_PASS')]){
> sh "mvn -U
> weblogic:redeploy -DskipTests=true -Dfailonerror=true -Duser='${WL_USER}'
> -Dpassword='${WL_PASS}' -Dname=${ARTIFACTID} -Dupload=true
> -Dsource=target/${ARTIFACTID}-${VERSION}.war -Dtargets=${ARTIFACTID}
> -Dadminurl='${URL_TST}'"
> }
> }
> }
> }
>
>
> --
> 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/ac762c3b-3488-4a4f-a8f5-2408aac38284%40googlegroups.com
> .
>


-- 
Thanks!
Mark Waite

-- 
You received this message because you are subscribed to the Google

Re: Jenkins Docker Image and extended Linux executables

2019-09-19 Thread Mark Waite
On Thu, Sep 19, 2019 at 8:10 AM 'Carsten' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Hi,
> we are running Jenkins in a docker environment.
> Jenkins Version 2.192
> running in a docker container version 19.03.2, build 6a30dfc
> Running on an Ubuntu Xenial 16.04
> We are deploying by Linux shell scripts using multiple extended Linux
> commands like "netcat" or "nslookup".
>
> Unfortunately the Jenkins image seems to deny such commands.
> In a first attempt it cannot find the commands, because they are out of
> the running environment (even setting "PATH" does NOT help):
>
> /var/jenkins_home/workspace/[branchpath]/Pipeline/accesstest.sh: line 19:
> nslookup: No such file or directory
>
> and in a second attempt copying the files into the home path of Jenkins,
> it misses the libraries:
>
> "../var/jenkins_home/nslookup: error while loading shared libraries:
> libdns.so.162: cannot open shared object file: No such file or directory.."
>
> How can I solve this problem?
>
>
It is more generally preferred to limit the amount of work and the number
of programs installed on the Jenkins master.  Usually it is better to
specify agents which include the desired programs rather than placing those
programs on the master.

If you find that there are cases where you absolutely must install the
programs on the master, then you can create your own Dockerfile which is
based on the Jenkins Dockerfile and adds the programs you need using the
appropriate operating system commands (like `apt-get install`).

Mark Waite


> br
> Carsten
>
>
>
>
> --
> 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/b9156977-a8a4-4f21-8f25-9325defffde3%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/b9156977-a8a4-4f21-8f25-9325defffde3%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEt_MoSrmcNNmy5JW053hMxbJN-%2BjH2w%2BcEHV%2BHrSuCAQ%40mail.gmail.com.


Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Mark Waite
On Thu, Sep 19, 2019 at 6:30 AM Jhonny Oliveira 
wrote:

> The idea is to have a self contained application (as in source repo),
> where you have everything you need to maintain its SDLC: source, build,
> tests (unit, regression, ...), continuous integration/automation
> (Jenkinsfile).
>
> The Jenkinsfile should be part of the source code and cover the entire
> process (end to end). Breaking it into pieces kind of defeats our main
> purpose of having everyone working together in the same source (developers,
> testers, operations, ...).
>
>
Yes, that's the right way to do it.  You've described the storage of the
definition of the application very well.  Keep it all in source code and
run it from source.

Place the limited use credential on a folder in Jenkins, then control who
is allowed to access that folder.  The jobs inside the folder will be able
to use the credential.  Jobs outside the folder won't have access to the
credential.


> Is there any chance such feature could be included in future releases? To
> whom can I address this question?
>
>
This is the right place to address the question.

I'm not aware of anyone working to add credentials to agents.  Since agents
are treated more and more as ephemeral workers that are exist only long
enough to perform their task and are then discarded, it seems unlikely that
anyone would add credential storage to agents.

There are still plenty of cases where agents live a long time (as in your
case), but Jenkins work now needs to consider both long-lived agents and
ephemeral agents.  Most capabilities that are being added are done so that
they can be used with all types of agents.


> --
> 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/fca0f38f-1b9a-4843-8572-fb77dc716aa7%40googlegroups.com
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFWwo4vp2sHhF5Og-N%2Bt4FoH6QaGNF%3DoCGuZsCE_0QUYg%40mail.gmail.com.


Re: Restrict credential retrieval to a specific slave

2019-09-19 Thread Mark Waite
On Thu, Sep 19, 2019 at 4:21 AM Jhonny Oliveira 
wrote:

> Hi!
>
> is it possible to limit the usage of a credential to a specific slave?
>

Not with Jenkins as far as I know.  Credentials can be defined on the
Jenkins master, on folders, and on multibranch Pipelines.  They can't be
defined on Freestyle jobs or on agents.


> With this restriction, I could fully empower developers to create their
> own Pipelines (Jenkinsfile) while avoiding passwords to be leaked in the
> wrong slaves/environments.
>

Could you attach the credentials to a folder and then limit access to the
folders instead?  Those with access to the folder can use the credential
attached to that folder.  Those without access to the folder could not use
that credential.


>
> Just for further context, in my scenario and at infrastructure level, only
> specific slaves are allowed to deploy to specific environments. E.g.:
> dev_slave -> deploy to DEV; tst_slave -> deploy to TST and so on.
>
> Cheers,
> Jhonny Oliveira
>
> --
> 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/2540cf8f-0413-4ec1-ae4a-136f2eeaf894%40googlegroups.com
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFCvn4k-DW%2BY5ew30bLAhaNBc-UHgaFx6dDTn17qAoyRQ%40mail.gmail.com.


Re: SSH agent uses username 'jenkins' instead of the one configured in the credential

2019-09-18 Thread Mark Waite
If you're running an outdated version of the git client plugin and a newer
version of OpenSSH (7.7 and later), then you might be encountering
https://issues.jenkins-ci.org/browse/JENKINS-50573 .  Git plugin versions
prior to

If you're running the current git client plugin (2.8.6) or running an
OpenSSH older than 7.7, then you might be mistakenly using an http or https
protocol URL.  The ssh protocol is either ssh://hostname/dir/path or
username@hostname:dir/path.  `git remote -v` will report the URL of the
remote in that repository.

On Tue, Sep 17, 2019 at 4:27 AM DexterMagnific 
wrote:

> Hi all,
>
> I have big troubles making 'git' commands inside a pipeline file.
>
> I have the following command:
>
>  stage('Download test database') {
>   steps {
> sshagent(credentials: ['----'])
> {*/
>   sh 'git submodule update --init --recursive'
> }
>   }
> }
>
> The problem is that git is called with the user 'jenkins' instead of the
> one that is specified inside the credential (which is 'jenkins-serv') I get
> a "permission denied" from the git server.
>
> [Pipeline] // stage
> [Pipeline] stage
> [Pipeline] { (Download test database)
> [Pipeline] sh
> + git submodule update --init --recursive
> Cloning into '/var/lib/jenkins/workspace/MyProject/testDB'...
> jenkins@192.168.20.23: Permission denied (publickey).
> fatal: Could not read from remote repository.
>
>
> Did I miss something on the pipeline setup ?
>
> 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/b5f85d92-adfd-496c-b7c8-2d7a34ad4b21%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/b5f85d92-adfd-496c-b7c8-2d7a34ad4b21%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFoQhjChuG5k7FLL3_tjGQNQsvWMFtupKLAdT7pOhTvTQ%40mail.gmail.com.


Re: git log master..hotfix/SFCC.1.11.0 --oneline | tail -1

2019-09-05 Thread Mark Waite
On Thu, Sep 5, 2019 at 7:47 AM Sandeep muthyapu 
wrote:

> Thank you so much for quick response ,
> Can you please help me how to do it ...I means how to Enable Branch
> concept in jenkins..
>
>
In the "Additional behaviours" section of Freestyle jobs and the "Add"
section for multibranch pipelines there is an entry which mentions "local
branch".  Click that to enable it, then either leave the value empty (to
accept the default) or insert the name of your branch.


>
> On Thu, Sep 5, 2019 at 6:13 AM Mark Waite 
> wrote:
>
>> Usually that message means that one or more of the names that you
>> referenced in the 'git log' command is not defined in the workspace where
>> the job is running. For example, a Jenkins workspace checkout as created by
>> the git plugin ny has no named branches.  It uses a "detached HEAD" rather
>> than a branch name checkout by default.  If you want to checkout with a
>> named branch, you need to enable the '
>>
>> You can check that case in the workspace with the command:
>>
>> $ git branch
>>
>> It will probably show that either there is no branch named "master" in
>> that workspace or no branch named "hotfix/SFCC.1.11.0".
>>
>> On Thu, Sep 5, 2019 at 1:31 AM SandeepM 
>> wrote:
>>
>>> git log master..hotfix/SFCC.1.11.0  --oneline | tail -1
>>>
>>> ERROR:
>>> fatal: ambiguous argument 'master..hotfix/SFCC.1.11.0': unknown revision
>>> or path not in the working tree.
>>> Use '--' to separate paths from revisions, like this:
>>> 'git  [...] -- [...]'
>>>
>>> When I executed above command through CLI it working fine. But when I
>>> have Executed command in jenkins execute shell am getting above error.
>>>
>>> --
>>> 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/089bb2c9-3426-4b0c-a175-ecaa52a7bfd0%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/089bb2c9-3426-4b0c-a175-ecaa52a7bfd0%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
>> --
>> 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/CAO49JtEY9mKOCgTjpDGdUXNTiXr-_jvq-jU5_a08b41rR%2BvLSQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEY9mKOCgTjpDGdUXNTiXr-_jvq-jU5_a08b41rR%2BvLSQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
> --
> 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/CACJCc0Swyp8ZDaHjMsYkb8zwY6KrQRq7qm8FbsmvQaLJ_oWEbw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CACJCc0Swyp8ZDaHjMsYkb8zwY6KrQRq7qm8FbsmvQaLJ_oWEbw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFUfaxNZb2yXGqHOLhL_gTpaQFvFufEZKZfzvx8wES3Jw%40mail.gmail.com.


Re: git log master..hotfix/SFCC.1.11.0 --oneline | tail -1

2019-09-05 Thread Mark Waite
Usually that message means that one or more of the names that you
referenced in the 'git log' command is not defined in the workspace where
the job is running. For example, a Jenkins workspace checkout as created by
the git plugin ny has no named branches.  It uses a "detached HEAD" rather
than a branch name checkout by default.  If you want to checkout with a
named branch, you need to enable the '

You can check that case in the workspace with the command:

$ git branch

It will probably show that either there is no branch named "master" in that
workspace or no branch named "hotfix/SFCC.1.11.0".

On Thu, Sep 5, 2019 at 1:31 AM SandeepM  wrote:

> git log master..hotfix/SFCC.1.11.0  --oneline | tail -1
>
> ERROR:
> fatal: ambiguous argument 'master..hotfix/SFCC.1.11.0': unknown revision
> or path not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git  [...] -- [...]'
>
> When I executed above command through CLI it working fine. But when I have
> Executed command in jenkins execute shell am getting above error.
>
> --
> 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/089bb2c9-3426-4b0c-a175-ecaa52a7bfd0%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/089bb2c9-3426-4b0c-a175-ecaa52a7bfd0%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEY9mKOCgTjpDGdUXNTiXr-_jvq-jU5_a08b41rR%2BvLSQ%40mail.gmail.com.


Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

2019-09-05 Thread Mark Waite
Because the code signing tool requires interaction with the desktop, it
requires that you must be logged in (or at least that is my theory).  There
are techniques to configure processes to run without being logged in, but
they all tend to leave the process with no access to the desktop or limited
access to the desktop.

You'll need to leave the agent connected to the master from a running
desktop session.

On Thu, Sep 5, 2019 at 12:53 AM *佳諭*  wrote:

> Hi Mark,
> Thanks for your reply.
> I have follow your suggestion, and add a slave node on the same computer.
> Because I can't find the "Jave web start" option in the Launch method, I
> create a slave node with "Launch agent by connecting it to the master "
> I download the agent.jar then execute the following command in the console
> with administrator privilege.
> "java -jar agent.jar -jnlpUrl
> http:///slave-agent.jnlp -screct
> xxx -workDir c:\x"
> Finally, my slave node online.
> But if I log out this computer (because this computer is a VM), my slave
> node offline (disconnect).
>
> I hope my code can submit from svn or git then automatically build through
> MSBuild which project have post-build event with the ev sign script.
> But if I use master node to build , I'll get the error about "No
> certificates were found that met all the given criteria".
> It seems master node not have enough privilege to interact with desktop
> sign application.
> If I build a new slave node with "Launch agent by connecting it to the
> master ", MSBuild and post-build sign event cant successfully build and
> sign code,
> but it need to keep the node login.
> If I login the vm, the slave node will disconnect.
>
> Is there any way to keep the slave node online? (and also can have enough
> privilege for ev usb token sign)
> Thanks for your help.
>
>
>
> Mark Waite  於 2019年9月5日 週四 上午6:14寫道:
>
>>
>>
>> On Wed, Sep 4, 2019 at 4:06 PM Chia-Yu Wu  wrote:
>>
>>> Hi Mark,
>>> I have the same issue with ev sign (usb token) code through jenkins.
>>> It work fine if i do ev sign in admin role command line.
>>> But if let it auto build and sign through, the jenkins console will show
>>> the following error message:
>>>
>>> "No certificates were found that met all the given criteria"
>>>
>>> I have read your suggestion, using the agent to "Launch agent via Java
>>> Web Start" instead of runnig jenkins as windows service.
>>> But I don't have a slave node, my jenkins only have a default master
>>> node, I can't config the master node "Launch agent via Java Web Start"
>>>
>>> Could you help me about this issue?
>>> I'll very appreciate your help.
>>>
>>>
>> If you're running the master as a service, then you'll need to add an
>> agent which is running on the desktop.  The agent can be on the same
>> computer where you run the Jenkins master, but the new agent will need to
>> be launched from the desktop.
>>
>> If you're running the master from a command line, then it should work.
>>
>> Thanks,
>> Mark Waite
>>
>>
>>>
>>> Mark Waite於 2019年5月9日星期四 UTC+8下午10時59分13秒寫道:
>>>>
>>>>
>>>>
>>>> On Thu, May 9, 2019 at 6:13 AM A M  wrote:
>>>>
>>>>> Thanks a lot Mark for your quick response!   As I understand it the
>>>>> goal is to create a slave/agent that will run the code signing directly on
>>>>> windows, instead of a service. great idea!
>>>>>
>>>>> However, I am stuck at step 4, I dond't see the "Launch agent via Java
>>>>> Web Start" option. I found a general solution online
>>>>> <https://stackoverflow.com/questions/40340097/there-is-no-launch-agent-via-java-web-start-option-in-my-jenkins-when-i-adding>,
>>>>> by specifying a concrete or random port in the Global Security TCP
>>>>> settings. I tried both, and even restarted Jenkins a couple of times, and
>>>>> it doesn't show up.
>>>>>
>>>>>
>>>> I think you are on the right path.  That solution is the correct
>>>> solution.
>>>>
>>>> Here are the screen shots that I used to confirm it is working with
>>>> Jenkins 2.164.2:
>>>>
>>>> *Jenkins -> Configure Global Security -> Agents -> Port 5*
>>>>
>>>> [image: Annotation 2019-05-09 084830.jpg]
>>>>
>>>> *Jenkins ->

Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

2019-09-04 Thread Mark Waite
On Wed, Sep 4, 2019 at 4:06 PM Chia-Yu Wu  wrote:

> Hi Mark,
> I have the same issue with ev sign (usb token) code through jenkins.
> It work fine if i do ev sign in admin role command line.
> But if let it auto build and sign through, the jenkins console will show
> the following error message:
>
> "No certificates were found that met all the given criteria"
>
> I have read your suggestion, using the agent to "Launch agent via Java Web
> Start" instead of runnig jenkins as windows service.
> But I don't have a slave node, my jenkins only have a default master node,
> I can't config the master node "Launch agent via Java Web Start"
>
> Could you help me about this issue?
> I'll very appreciate your help.
>
>
If you're running the master as a service, then you'll need to add an agent
which is running on the desktop.  The agent can be on the same computer
where you run the Jenkins master, but the new agent will need to be
launched from the desktop.

If you're running the master from a command line, then it should work.

Thanks,
Mark Waite


>
> Mark Waite於 2019年5月9日星期四 UTC+8下午10時59分13秒寫道:
>>
>>
>>
>> On Thu, May 9, 2019 at 6:13 AM A M  wrote:
>>
>>> Thanks a lot Mark for your quick response!   As I understand it the goal
>>> is to create a slave/agent that will run the code signing directly on
>>> windows, instead of a service. great idea!
>>>
>>> However, I am stuck at step 4, I dond't see the "Launch agent via Java
>>> Web Start" option. I found a general solution online
>>> <https://stackoverflow.com/questions/40340097/there-is-no-launch-agent-via-java-web-start-option-in-my-jenkins-when-i-adding>,
>>> by specifying a concrete or random port in the Global Security TCP
>>> settings. I tried both, and even restarted Jenkins a couple of times, and
>>> it doesn't show up.
>>>
>>>
>> I think you are on the right path.  That solution is the correct solution.
>>
>> Here are the screen shots that I used to confirm it is working with
>> Jenkins 2.164.2:
>>
>> *Jenkins -> Configure Global Security -> Agents -> Port 5*
>>
>> [image: Annotation 2019-05-09 084830.jpg]
>>
>> *Jenkins -> Build Executor Status -> New Node*
>>
>> [image: Annotation 2019-05-09 084942.jpg]
>>
>> *Node name -> Permanent Agent -> OK*
>>
>> [image: Annotation 2019-05-09 085016.jpg]
>>
>> Name -> Description -> Remote root directory -> Launch Method "Launch
>> agent via Java Web Start"
>>
>> [image: Annotation 2019-05-09 085149.jpg]
>>
>> Mark Waite
>>
>>
>>> I only see 1) Launch agent by connecting it to the master, 2) ... via
>>> execution of command on the master, 3) ... Let Jenkins control this Windows
>>> slave as a Windows service.
>>>
>>>
>> That likely indicates that you installed the 'windows-slaves' or
>> 'windows-agents' plugin.  You don't need that plugin and generally don't
>> want it.  The technique it uses to start the agent is based on DCOM, is
>> exceptionally brittle, and is very hard to use.  You can (and probably
>> should) remove the windows-slaves or windows-agents plugin.  Agents run on
>> Windows quite well without needing that plugin.
>>
>>
>>> Also checked if there are any updates of Jenkins, only some unrelated
>>> plugin-updates are available. Anything else I could check?
>>>
>>> Thank you!
>>>
>>> Am Mittwoch, 8. Mai 2019 16:05:00 UTC+2 schrieb Mark Waite:
>>>>
>>>>
>>>>
>>>> On Wednesday, May 8, 2019 at 7:18:31 AM UTC-6, A M wrote:
>>>>>
>>>>> hi Mark
>>>>>
>>>>> I am struggling with a very similar issue. What exactly do you mean by
>>>>> your comment and how do I achieve this?
>>>>>
>>>>>
>>>> I said:
>>>>
>>>> > Run the Windows agent from the Windows desktop rather than running it
>>>> from a service which has been allowed to interact with the desktop.
>>>>
>>>> The most direct way to implement what I described is to:
>>>>
>>>>1. Login to the Windows desktop machine where code signing will be
>>>>run
>>>>2. Open a web browser to the Jenkins server
>>>>3. Create an agent (a node) to represent that Windows computer
>>>>4. Configure the agent to "Launch agent via Java Web Start"
>>>>5. Define the req

Re: Bitbucket branch source - WARN: Could not find ref: XXX in refs/heads or refs/remotes/origin

2019-09-02 Thread Mark Waite
The branch sources (GitHub, Bitbucket, Gitea, and Gitlab) may configure the
checkout of a specific workspace to include only the changes for the branch
which that workspace is using.  That is a very good default choice because
it can reduce the data transfer from the git server to the workspace and
can reduce the disc use and clone time for the job.  It appears that your
use case may need to use changes from another branch which is related to
the branch the workspace is using.

If the build process (Sonar diff computation, etc.) needs more than the
changes for the specific branch that you're using, you may need to extend
the Jenkins Pipeline definition for that job to use a custom refspec to
include additional branches in the workspace.  The pipeline command
'checkout' allows custom refspecs to be defined and used.  You will likely
also need to use the clone option "Honor refspec on initial checkout" in
order to assure that the initial clone also uses the custom refspec
definition.

Mark Waite

On Mon, Sep 2, 2019 at 3:45 PM Dan Tran  wrote:

> Hi
>
> I am looking for suggestion on how to configure BB branch source plugin to
> fix the sonar/git issue discussed at
> https://community.sonarsource.com/t/error-warn-could-not-find-ref-develop-in-refs-heads-or-refs-remotes-origin-after-updating-to-7-6/6420
>
>
> Very much appreciated
>
> -D
>
> --
> 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/50e75680-a968-41b7-b483-a71e01848ca2%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/50e75680-a968-41b7-b483-a71e01848ca2%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFWXsPvYt5Us8a6Puk5Uzfnum5Gx5gDHSQ6Hp32fgX9Zw%40mail.gmail.com.


Re: Trigger build via REST API since 2.176.3

2019-09-02 Thread Mark Waite
I used curl to request the crumb and the session ID and then passed that
crumb and session ID to a later curl call which performed the work I needed
to do.

Refer to
https://github.com/MarkEWaite/jenkins-bugs/blob/6db4ea8ef277dbe496346d8ceaebdb12029d870c/reportScanLogResults#L56
for the "cookie jar" that remembers the session ID.

Refer to
https://github.com/MarkEWaite/jenkins-bugs/blob/6db4ea8ef277dbe496346d8ceaebdb12029d870c/reportScanLogResults#L89
for a use of that "cookie jar".

I think the topic of API use (including cookie use and various alternatives
to call the API) deserves a future topic for a "How-To Guide" to be added
to https://jenkins.io/doc/developer/guides/ .

On Mon, Sep 2, 2019 at 4:09 AM James Telfer  wrote:

> Hi,
>
> I've been bitten by the security fix in Jenkins LTS 2.176.3 to the CSRF
> protection, specifically the tying of a crumb to the session ID it was
> generated in.
>
> There is a note in the upgrade guide
> <https://jenkins.io/doc/upgrade-guide/2.176/#SECURITY-626> which suggests
> I can trigger builds using an API token without requiring a crumb, which is
> pretty much what I want to be able to do.  It appears that I should be able
> to do this by sending a POST of the form: http://: Token>@/build
>
>  But I always get back a 403 No valid crumb was included in the request,
> which while 100% accurate was not what I expected.
>
> Any idea how I can do 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/97c3ff89-83ab-42f9-bb89-72922a940383%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/97c3ff89-83ab-42f9-bb89-72922a940383%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGgKFcEcEgLwGe9iZW0%3Dq79S4JKQhBFJrnNObbH6W4uGQ%40mail.gmail.com.


Re: Generate API Token does not display token to user.

2019-08-29 Thread Mark Waite
That is quite unexpected.  I just used Jenkins 2.176.3 with Google Chrome
and confirmed that a token is generated as expected.  In my case, I am
connecting to Jenkins over SSL from the public internet, with the SSL
certificate handled by LetsEncrypt and the reverse proxy by nginx.

Can you describe the ways that your configuration is different from mine?

Are you running a reverse proxy?
Are you running a different web browser?
Are you running through a web proxy?
Are you running some software that might be filtering or blocking a portion
of the HTTP traffic from Jenkins?



On Thu, Aug 29, 2019 at 3:22 PM Philip Mason  wrote:

> Hi Jenkins folks. Running LTS 2.176.3.
>
> I find that "Add New Token" in the user configuration page isn't working.
>
> "Generate" button creates token, but it is never displayed to the user.
> Have to refresh the page to see that the token was created.
>
> The Script Console suggestion from Cloudbees to generate a token for a
> user throws an NPE at user.save().
>
> - - - Philip
>
> --
> 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/77cca0af-1244-4193-94fe-7e87d9de9a98%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/77cca0af-1244-4193-94fe-7e87d9de9a98%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGHpe5cQYSYExqDgEnZQqQkPjv0pZ9j4ZfJbOEidMDvvQ%40mail.gmail.com.


Re: Combining periodic SCM check with building individual commits

2019-08-28 Thread Mark Waite
You're using a relatively special case.  The git plugin does not support it
directly.

You might consider splitting the task into two Jenkins jobs:

   1. Job that takes a SHA-1 as a parameter that should be built, but never
   polls the repository
   2. Job that detects changes on the remote repository and runs a script
   that computes the list of changes since the last run, then launches the job
   defined step 1 with each of the SHA-1 values that have arrived since the
   last run

Mark Waite

On Wed, Aug 28, 2019 at 9:14 AM 'Mark Raynsford' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Hello.
>
> I use a pretty simple setup for each job. Each of my jobs is a GitHub
> project, and I use the "poll SCM" feature with a schedule of "H/53 * *
> * *" (in other words, poll randomly roughly hourly). My Jenkins setup
> is not externally accessible in any form, so I can't have an external
> service notifying my server that something has been updated.
>
> This all works fine, except that now I've started wanting to publish
> snapshots and releases automatically from Jenkins builds. This would be
> fine, except that Jenkins tends to only build the latest commit that it
> sees each SCM polling period, rather than building all of the
> individual commits that occurred between this and the last period. This
> means that it's possible for it to "miss" a tagged release commit and
> just build the latest development snapshot instead.
>
> Is there some way to get it to build all of the individual commits? In
> other words, if I've made five commits since the last polling period, I
> should see five new jobs scheduled next time the SCM is polled.
>
> --
> Mark Raynsford | http://www.io7m.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/20190828141416.572bca32%40almond.int.arc7.info
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEomY%3DGY5xZYzXS6AYPrsyROptBhRPU3bqd%2B_fSSZEG3A%40mail.gmail.com.


Re: Latest GitHub Branch Source not scanning with credentials?

2019-08-21 Thread Mark Waite
To bring this thread to closure, we discovered in a diagnostic session that
I had defined the credentials domain to be restricted to hosts named '
github.com'.  That precludes use of the 'api.github.com' host which is
needed for the API calls from the GitHub Branch Source plugin.

Define credential domains correctly, and the problem is resolved.

On Tue, Aug 20, 2019 at 7:40 AM Mark Waite 
wrote:

> The root issue seems to be the credentials being defined in the parent
> folder instead of being defined at the root.  I have several credentials
> defined in that folder and they were working previously as far as I can
> tell.  However, I'll need to do more searching to understand which change
> first introduced the behavior.
>
> On Mon, Aug 19, 2019 at 1:38 PM Mark Waite 
> wrote:
>
>>
>>
>> On Mon, Aug 19, 2019 at 9:13 AM Devin Nusbaum 
>> wrote:
>>
>>> If I understand correctly, the problem is that in the non-working case,
>>> branch indexing ends up using anonymous credentials instead of the ones you
>>> specified (and thus timing out due to rate limits), rather than failing
>>> with an explicit error message?
>>>
>>
>> Mostly correct.  Branch indexing uses anonymous credentials instead of
>> the ones I specified.  That takes a very long time due to rate limits.
>>
>> It is a public repository, so it will not fail with an error message when
>> not using credentials, it just takes a very long time because it exhausts
>> the anonymous rate limits very quickly.
>>
>>
>>>
>>> I don’t think it should matter, but just in case, what versions of
>>> workflow-cps-global-lib are you running in the working and non-working
>>> cases?
>>>
>>>
>> Working and non-working cases are both using workflow-cps-global-lib 2.15.
>>
>> I'll spend more time today investigating further in an attempt to
>> identify the most relevant differences between the working and the
>> non-working cases.
>>
>> Mark Waite
>>
>>
>>> On Aug 17, 2019, at 12:54, Mark Waite  wrote:
>>>
>>> I've updated to GitHub Branch Source 2.5.6 and seem to have a GitHub
>>> multibranch Pipeline job that refuses to use my credentials when scanning
>>> the repository.  The repository is a public repository, but I want it to
>>> scan the repository with my credentials so that I can use the larger GitHub
>>> API rate limits that are allowed by authenticated access.
>>>
>>> I see a job configuration change from "Repository Scan - Deprecated
>>> Visualization" to "Repository HTTPS URL" and I see the addition of the
>>> "Validate" button in the user interface to check my credentials.  I've
>>> validated the credentials using the "Validate" button, both for the job
>>> itself and for the Pipeline shared library that is defined in the job.
>>> I've created a new GitHub personal access token with 'repo' permission, and
>>> still can't persuade the pipeline scanner to use the credential.  The
>>> credentials I'm using are assigned to the parent folder of the multibranch
>>> Pipeline job.
>>>
>>> I have another machine which is able to scan with credentials and GitHub
>>> branch source using the same repository.  Some of the differences between
>>> the working and the non-working cases include:
>>>
>>>- Working - Pipeline shared library is defined at root, not working
>>>when defined in the multibranch Pipeline job
>>>- Working - Credentials are defined globally, not working when
>>>defined in the parent folder of the multibranch Pipeline job
>>>- Working - Git plugin 4.0 beta release, not working when using git
>>>plugin 3.11.0
>>>
>>> I suspect there are many more differences between the working and the
>>> non-working cases, but wanted to identify those few in case someone has
>>> more insights to offer.
>>>
>>> Has anyone else seen a similar behavior?
>>>
>>> Any pointers of things I should investigate (other than varying the
>>> parameters which are different between working and non-working cases, I'll
>>> certainly do that)?
>>>
>>> Job configuration screen looks like this (apologies for the wide
>>> screen..):
>>>
>>> 
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receivi

Re: how do I modify one option in scm.getUserRemoteConfigs without having to manually set all the options?

2019-08-21 Thread Mark Waite
I think you can assign the original to a new variable, then modify only the
precise portions that need to be changed.

Like this:

// Narrow the respec to only this branch
def branch = 'JENKINS-59016'
def myRemoteConfigs = scm.userRemoteConfigs
myRemoteConfigs[0].refspec =
"+refs/heads/${branch}:refs/remotes/origin/${branch}"

Then use the new variable as the value as in:

   userRemoteConfigs: myRemoteConfigs

Mark Waite

On Wed, Aug 21, 2019 at 2:56 PM red 888  wrote:

> in my jenkins pipeline i have this:
>
>
> checkout([$class: 'GitSCM',
>   branches: [[name: "${env.BRANCH_NAME}"]],
>   doGenerateSubmoduleConfigurations: false,
>   extensions: [
>   [$class: 'SubmoduleOption',
>disableSubmodules: false,
>parentCredentials: true,
>recursiveSubmodules: true,
>reference: '',
>trackingSubmodules: true],
>   [$class: 'CloneOption', timeout: config.timeout],
>   [$class: 'CheckoutOption', timeout: config.timeout],
>   [$class: 'GitLFSPull']
>   ],
>   submoduleCfg : [],
>   userRemoteConfigs: [[
>   //scm.userRemoteConfigs,
>   refspec: '+refs/tags/*:refs/remotes/origin/tags/*'
>   ]]
> ])
>
>
> I just want to modify the refspec and use the rest of the defaults in
> scm.userRemoteConfigs. How can I do that without having to manually set all
> of them because Im no longer just passing in scm.userRemoteConfigs
>
>
> Im trying to get jenkins to trigger a build when it sees a new tag (like
> it does with new branches) right now it indexes and gets the new tag but
> doesn't run a build
>
> --
> 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/7e5c1679-a40c-4364-b149-282008953df5%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/7e5c1679-a40c-4364-b149-282008953df5%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHDWP490_1YbKVUgX0ZkYxOV60A9SCQPkdgioitn70k3w%40mail.gmail.com.


Re: Jenkins: user is missing the Overall/Read permission - Issue

2019-08-21 Thread Mark Waite
Doesn't it resolve the issue if you check the "Read" box in the "Overall"
column for the user "manual"?

Mark Waite

On Wed, Aug 21, 2019 at 7:15 PM 'joe khese' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Hello
>
> did you get the solution to this error? I'm currently battling with the
> same error
>
> On Saturday, 3 March 2018 15:07:07 UTC+1, Poovaraj Thangamariappan wrote:
>>
>> Hello,
>>
>> I have created  *manual* user in Manger User and I have configured in  
>> Matrix-based
>> security. It is showing Manual user is missing the Overall/Read
>> permission'while login into jenkins.
>>
>> Pleaes find thebelow screenshot and config.xml file. Please help me to
>> fix this issue.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Regards,
>> Poovaraj
>>
>>
>> --
> 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/53b42b7e-cf04-4aec-a028-0752d4cddd28%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/53b42b7e-cf04-4aec-a028-0752d4cddd28%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFAYrLWEyWEeRq5gxk%3DQABWZi4wZjUt_dQJyUco5hSGuA%40mail.gmail.com.


Re: Jenkins job failure analysis

2019-08-20 Thread Mark Waite
If resource use on the "strained" machine decreased just enough to allow
the executed process to succeed, then Jenkins would report the job was a
success.  If resource use on the "strained" machine increased just enough
to cause the Linux kernel to kill the process or just enough to cause some
other overload condition to kill the process, then Jenkins would report the
job failed.

Overload conditions (high memory use, disc full, etc.) are common sources
of variability.  If that variability is unintentional, then it is best to
resolve the overload condition as you did.  Add capacity and allow the
tests to run with enough resources.

On Tue, Aug 20, 2019 at 7:47 AM Sameer Khan  wrote:

> My bad! Thanks for correcting me!
>
> Mark, in my case the build does go thru if re-built at times. Also when
> the machine was upgraded such failures are not observed.
>
> Thanks,
> Sameer
>
> On 20-Aug-2019, at 17:49, Mark Waite  wrote:
>
> This is a question best asked on the user mailing list.  The developer
> list is used for development discussions related to Jenkins and its
> components (plugins, modules, etc.).
>
> Jenkins executes processes (junit tests, for example) and reports the
> return value of those processes and optionally analyzes the results of
> those processes to decide the state of the job.  If a process returns a
> non-zero exit code, that will generally cause Jenkins to mark the job as
> failed.  If a junit process writes a report file that Jenkins analyzes and
> that file includes a failing test, that will generally cause Jenkins to
> mark the job as unstable.
>
> On Tue, Aug 20, 2019 at 2:53 AM Sameer  wrote:
>
>> Hi,
>>
>> I have been building my Java application using Jenkins (ver. 2.187) which
>> was running in an EC2 instance. My code has Junit tests also. However
>> sometimes the job fails for no reason valid to the code. Once the EC2
>> instance was upgraded with better resources it started working smoothly. Is
>> there way, I could find the root cause of failure in such a case? Basically
>> I want to understand at Jenkins level what made it to fail the job.
>>
>> Any pointers would be appreciated!
>>
>> Thanks,
>> Sameer
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/3867ea26-146f-4a32-84b3-08952c695f1a%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/3867ea26-146f-4a32-84b3-08952c695f1a%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/jMQm4d1tcsg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHDLL5WvuBpRXtqbDRtBuUB2yGB%2BUd%2BRJcZt0wobTs_ow%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtHDLL5WvuBpRXtqbDRtBuUB2yGB%2BUd%2BRJcZt0wobTs_ow%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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/1B30EB95-70BF-44E7-8445-0301EEFD369E%40gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/1B30EB95-70BF-44E7-8445-0301EEFD369E%40gmail.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHGP%2BHtgQ4Tcmyzk_t3xB%3DvhCnydEamx128UbJG4iPTjQ%40mail.gmail.com.


Re: Latest GitHub Branch Source not scanning with credentials?

2019-08-20 Thread Mark Waite
The root issue seems to be the credentials being defined in the parent
folder instead of being defined at the root.  I have several credentials
defined in that folder and they were working previously as far as I can
tell.  However, I'll need to do more searching to understand which change
first introduced the behavior.

On Mon, Aug 19, 2019 at 1:38 PM Mark Waite 
wrote:

>
>
> On Mon, Aug 19, 2019 at 9:13 AM Devin Nusbaum 
> wrote:
>
>> If I understand correctly, the problem is that in the non-working case,
>> branch indexing ends up using anonymous credentials instead of the ones you
>> specified (and thus timing out due to rate limits), rather than failing
>> with an explicit error message?
>>
>
> Mostly correct.  Branch indexing uses anonymous credentials instead of the
> ones I specified.  That takes a very long time due to rate limits.
>
> It is a public repository, so it will not fail with an error message when
> not using credentials, it just takes a very long time because it exhausts
> the anonymous rate limits very quickly.
>
>
>>
>> I don’t think it should matter, but just in case, what versions of
>> workflow-cps-global-lib are you running in the working and non-working
>> cases?
>>
>>
> Working and non-working cases are both using workflow-cps-global-lib 2.15.
>
> I'll spend more time today investigating further in an attempt to identify
> the most relevant differences between the working and the non-working cases.
>
> Mark Waite
>
>
>> On Aug 17, 2019, at 12:54, Mark Waite  wrote:
>>
>> I've updated to GitHub Branch Source 2.5.6 and seem to have a GitHub
>> multibranch Pipeline job that refuses to use my credentials when scanning
>> the repository.  The repository is a public repository, but I want it to
>> scan the repository with my credentials so that I can use the larger GitHub
>> API rate limits that are allowed by authenticated access.
>>
>> I see a job configuration change from "Repository Scan - Deprecated
>> Visualization" to "Repository HTTPS URL" and I see the addition of the
>> "Validate" button in the user interface to check my credentials.  I've
>> validated the credentials using the "Validate" button, both for the job
>> itself and for the Pipeline shared library that is defined in the job.
>> I've created a new GitHub personal access token with 'repo' permission, and
>> still can't persuade the pipeline scanner to use the credential.  The
>> credentials I'm using are assigned to the parent folder of the multibranch
>> Pipeline job.
>>
>> I have another machine which is able to scan with credentials and GitHub
>> branch source using the same repository.  Some of the differences between
>> the working and the non-working cases include:
>>
>>- Working - Pipeline shared library is defined at root, not working
>>when defined in the multibranch Pipeline job
>>- Working - Credentials are defined globally, not working when
>>defined in the parent folder of the multibranch Pipeline job
>>- Working - Git plugin 4.0 beta release, not working when using git
>>plugin 3.11.0
>>
>> I suspect there are many more differences between the working and the
>> non-working cases, but wanted to identify those few in case someone has
>> more insights to offer.
>>
>> Has anyone else seen a similar behavior?
>>
>> Any pointers of things I should investigate (other than varying the
>> parameters which are different between working and non-working cases, I'll
>> certainly do that)?
>>
>> Job configuration screen looks like this (apologies for the wide
>> screen..):
>>
>> 
>>
>>
>>
>> --
>> 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/d5bb65d3-7ec7-45ee-bfa6-fbf8d99bd6cc%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/d5bb65d3-7ec7-45ee-bfa6-fbf8d99bd6cc%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> 
>>
>>
>> --
>> 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
>

Re: Latest GitHub Branch Source not scanning with credentials?

2019-08-19 Thread Mark Waite
On Mon, Aug 19, 2019 at 9:13 AM Devin Nusbaum 
wrote:

> If I understand correctly, the problem is that in the non-working case,
> branch indexing ends up using anonymous credentials instead of the ones you
> specified (and thus timing out due to rate limits), rather than failing
> with an explicit error message?
>

Mostly correct.  Branch indexing uses anonymous credentials instead of the
ones I specified.  That takes a very long time due to rate limits.

It is a public repository, so it will not fail with an error message when
not using credentials, it just takes a very long time because it exhausts
the anonymous rate limits very quickly.


>
> I don’t think it should matter, but just in case, what versions of
> workflow-cps-global-lib are you running in the working and non-working
> cases?
>
>
Working and non-working cases are both using workflow-cps-global-lib 2.15.

I'll spend more time today investigating further in an attempt to identify
the most relevant differences between the working and the non-working cases.

Mark Waite


> On Aug 17, 2019, at 12:54, Mark Waite  wrote:
>
> I've updated to GitHub Branch Source 2.5.6 and seem to have a GitHub
> multibranch Pipeline job that refuses to use my credentials when scanning
> the repository.  The repository is a public repository, but I want it to
> scan the repository with my credentials so that I can use the larger GitHub
> API rate limits that are allowed by authenticated access.
>
> I see a job configuration change from "Repository Scan - Deprecated
> Visualization" to "Repository HTTPS URL" and I see the addition of the
> "Validate" button in the user interface to check my credentials.  I've
> validated the credentials using the "Validate" button, both for the job
> itself and for the Pipeline shared library that is defined in the job.
> I've created a new GitHub personal access token with 'repo' permission, and
> still can't persuade the pipeline scanner to use the credential.  The
> credentials I'm using are assigned to the parent folder of the multibranch
> Pipeline job.
>
> I have another machine which is able to scan with credentials and GitHub
> branch source using the same repository.  Some of the differences between
> the working and the non-working cases include:
>
>- Working - Pipeline shared library is defined at root, not working
>when defined in the multibranch Pipeline job
>- Working - Credentials are defined globally, not working when
>defined in the parent folder of the multibranch Pipeline job
>- Working - Git plugin 4.0 beta release, not working when using git
>plugin 3.11.0
>
> I suspect there are many more differences between the working and the
> non-working cases, but wanted to identify those few in case someone has
> more insights to offer.
>
> Has anyone else seen a similar behavior?
>
> Any pointers of things I should investigate (other than varying the
> parameters which are different between working and non-working cases, I'll
> certainly do that)?
>
> Job configuration screen looks like this (apologies for the wide screen..):
>
> 
>
>
>
> --
> 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/d5bb65d3-7ec7-45ee-bfa6-fbf8d99bd6cc%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/d5bb65d3-7ec7-45ee-bfa6-fbf8d99bd6cc%40googlegroups.com?utm_medium=email_source=footer>
> .
> 
>
>
> --
> 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/C67B3A88-4A62-4511-8ECE-C0E060D81C44%40cloudbees.com
> <https://groups.google.com/d/msgid/jenkinsci-users/C67B3A88-4A62-4511-8ECE-C0E060D81C44%40cloudbees.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtE%3DdVASVBWuQvLqBMj3m9niUyvMQdqJw_wMmUxonEFKGQ%40mail.gmail.com.


Re: Converting to pipeline questions

2019-08-15 Thread Mark Waite
On Thu, Aug 15, 2019 at 12:20 PM Louis Elston 
wrote:

> In Blue Ocean, if you create a new pipeline, and there is a Jenkinsfile in
> any branch in that repository, when you select “Create Pipeline”, it will
> execute the Jenkinsfile in each of those branches.  At this point, there is
> no ability to Configure anything.  Yes, if you then configure that new job
> you can restrict it to only execute on a particular branch.  This does not
> solve my problem.  Lets say that in ProductVersion1 branch there was a
> Jenkinsfile.  We are now Working on Version 2 of the product, and now have
> ProductVersion2 branch, which also has a JenkinsFile.  If I create a new
> Blue Ocean pipeline job (which initially cannot be configured to only
> execute on the new branch), then I am also going to execute a build of the
> previous branch (which I do not want to do because that version of the
> product has been released).  How to handle this, is it done in the script,
> in that I would need to edit the Jenkinsfiles in both branches before
> creating the new job?
>

Would it work for you if you took the following steps?

   1. Use Blue Ocean to create the first Pipeline on the branch that is the
   current product version.  Blue Ocean will create a multibranch pipeline job
   that will build all branches that contain a Jenkinsfile.  At this point,
   there is only one branch, so only one job will be created
   2. Edit the multibranch Pipeline job that Blue Ocean created, add the
   filter to specifically limit that job to only build the precise branch that
   is the currently active development branch
   3. When the time comes in the future that you are ready to add a
   Jenkinsfile on a new, independent branch of the same repository, add it
   from Blue Ocean or copy it from one branch to another with Git operations.
   Commit to the new branch, knowing that the new branch won't be built
   because it does not match the pattern for branches being selected for the
   multibranch pipeline definition
   4.  When you're ready to enable the new branch, change the definition of
   the multibranch pipeline to build both old and new branches.
   5. When you're ready to stop building the old branch, change the
   definition of the multibranch pipeline to only build the new branch

I think that workflow will allow you to use the multibranch pipeline job to
precisely define which branches are built and which are not built.  Whether
or not a Jenkinsfile exists on a branch, the multibranch pipeline job would
define which branches are allowed to build and which are ignored.

Thanks,
Mark Waite


>
>
> On Thursday, August 15, 2019 at 9:08:15 AM UTC-4, Mark Waite wrote:
>>
>>
>>
>> On Wednesday, August 14, 2019 at 1:34:10 PM UTC-7, Louis Elston wrote:
>>>
>>> " build only the branches that you specify.".  I am assuming that this
>>> is something in the script that does this, as when creating the MultiBranch
>>> job, I see no option to allow for the selection of doing executing the job
>>> for only one branch.  Not to harp on the documentation, but if this can be
>>> done, then document it up front (with an example).  This would make more
>>> users understand that Blue Ocean may be more applicable than it currently
>>> appears.
>>>
>>
>> Documentation pull requests are certainly welcomed and encouraged.  See
>> https://github.com/jenkins-infra/jenkins.io .
>>
>> The multibranch pipeline that is created by Blue Ocean has a "Configure"
>> page that allows you to limit the branch names which can be built..  In the
>> "Behaviors" section of that "Configure" page you select the "Add" button
>> and then select the row labeled "Filter by name (with wildcards)".  If you
>> need something more specific than wildcards will allow, you can use "Filter
>> by name (with regular expressions)".
>>
>> [image: filter-by-branch-with-wildcard.png]
>>
>> I have a private GitHub repository that includes several branches.  I
>> confirmed that it was able to filter by branch name with wildcards.
>>
>> Thanks,
>> Mark Waite
>>
>>
>>>
>>> On Wednesday, August 14, 2019 at 1:06:47 PM UTC-4, Mark Waite wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Aug 14, 2019 at 8:36 AM Louis Elston 
>>>> wrote:
>>>>
>>>>> This morning, I basically did what you just recommended.  I created a
>>>>> new Pipeline job (not using Blue Ocean), selected "Pipeline Script from
>>>>> SCM', and pointed to the Jenkinsfile that I had created yesterday in the
>>>>> master branch.  Because this job is not a M

Re: Converting to pipeline questions

2019-08-15 Thread Mark Waite


On Wednesday, August 14, 2019 at 1:34:10 PM UTC-7, Louis Elston wrote:
>
> " build only the branches that you specify.".  I am assuming that this is 
> something in the script that does this, as when creating the MultiBranch 
> job, I see no option to allow for the selection of doing executing the job 
> for only one branch.  Not to harp on the documentation, but if this can be 
> done, then document it up front (with an example).  This would make more 
> users understand that Blue Ocean may be more applicable than it currently 
> appears.
>

Documentation pull requests are certainly welcomed and encouraged.  See 
https://github.com/jenkins-infra/jenkins.io .

The multibranch pipeline that is created by Blue Ocean has a "Configure" 
page that allows you to limit the branch names which can be built..  In the 
"Behaviors" section of that "Configure" page you select the "Add" button 
and then select the row labeled "Filter by name (with wildcards)".  If you 
need something more specific than wildcards will allow, you can use "Filter 
by name (with regular expressions)".

[image: filter-by-branch-with-wildcard.png]

I have a private GitHub repository that includes several branches.  I 
confirmed that it was able to filter by branch name with wildcards.

Thanks,
Mark Waite
 

>
> On Wednesday, August 14, 2019 at 1:06:47 PM UTC-4, Mark Waite wrote:
>>
>>
>>
>> On Wed, Aug 14, 2019 at 8:36 AM Louis Elston  wrote:
>>
>>> This morning, I basically did what you just recommended.  I created a 
>>> new Pipeline job (not using Blue Ocean), selected "Pipeline Script from 
>>> SCM', and pointed to the Jenkinsfile that I had created yesterday in the 
>>> master branch.  Because this job is not a MultiBranch job, even thought you 
>>> can run it in Blue Ocean, because there are no 'Branches', the pipeline 
>>> editor pencil will not appearyou cannot edit the script in Blue Ocean.
>>>
>>> Are there any plans to modify Blue ocean so that the editor can be used 
>>> on any declarative script, MultiBranch or not?  If not, what is your 
>>> recommended alternative (besides the Pipeline Syntax \ Declarative 
>>> Directive Generator)?
>>>
>>>
>> There are no plans to modify the Blue Ocean editor to be used on 
>> pipelines outside of multibranch.
>>
>> You might try using a multibranch pipeline and define the multibranch 
>> pipeline to build only the branches that you specify.  Multibranch 
>> pipelines can be defined to build only a subset of the available branches.  
>> That would allow you to choose which branches are built based on the job 
>> definition of the multibranch pipeline and patterns for branch names, 
>> rather than creating individual jobs for each branch yourself.
>>  
>>
>>> Being that our development process does not involve test branches merged 
>>> up into the master, and instead is one branch per version of the product 
>>> where all development work is done, using a Multibranch job does not fit 
>>> our needs.  At least that is my impression, in that we do not want to 
>>> possibly have builds being run for any previous versions of the product 
>>> just because they have a Jenkinsfile.
>>>
>>> On Wednesday, August 14, 2019 at 9:33:02 AM UTC-4, Mark Waite wrote:
>>>>
>>>> When you used those steps in Blue Ocean, you defined a Pipeline in the 
>>>> branch where the Jenkinsfile was stored by Blue Ocean.  I think that is 
>>>> what you wanted in the SCM repository.  You're correct that Blue Ocean 
>>>> created a multibranch pipeline as part of that editing process.
>>>>
>>>> If you'd like a job which is not a multibranch Pipeline, create that 
>>>> job interactively with the Jenkins "New Item" menu.  Choose "Pipeline" as 
>>>> the item type and use "Pipeline from SCM" with the repository name and the 
>>>> branch name that you want to create.  In that case, the Jenkinsfile must 
>>>> already exist in the repository.  That's a less typical use case, since 
>>>> most users prefer to have Pipelines automatically created and deleted as 
>>>> branches are created and deleted on their git repository.
>>>>
>>>> If that is your preferred working model, then you could use Blue Ocean 
>>>> to create the Pipeline, delete the job which Blue Ocean created, then 
>>>> interactively create a Pipeline job which is not a multibranch Pipeline.
>>>>
>>>> Once the job is created (ei

Re: Converting to pipeline questions

2019-08-14 Thread Mark Waite
On Wed, Aug 14, 2019 at 8:36 AM Louis Elston  wrote:

> This morning, I basically did what you just recommended.  I created a new
> Pipeline job (not using Blue Ocean), selected "Pipeline Script from SCM',
> and pointed to the Jenkinsfile that I had created yesterday in the master
> branch.  Because this job is not a MultiBranch job, even thought you can
> run it in Blue Ocean, because there are no 'Branches', the pipeline editor
> pencil will not appearyou cannot edit the script in Blue Ocean.
>
> Are there any plans to modify Blue ocean so that the editor can be used on
> any declarative script, MultiBranch or not?  If not, what is your
> recommended alternative (besides the Pipeline Syntax \ Declarative
> Directive Generator)?
>
>
There are no plans to modify the Blue Ocean editor to be used on pipelines
outside of multibranch.

You might try using a multibranch pipeline and define the multibranch
pipeline to build only the branches that you specify.  Multibranch
pipelines can be defined to build only a subset of the available branches.
That would allow you to choose which branches are built based on the job
definition of the multibranch pipeline and patterns for branch names,
rather than creating individual jobs for each branch yourself.


> Being that our development process does not involve test branches merged
> up into the master, and instead is one branch per version of the product
> where all development work is done, using a Multibranch job does not fit
> our needs.  At least that is my impression, in that we do not want to
> possibly have builds being run for any previous versions of the product
> just because they have a Jenkinsfile.
>
> On Wednesday, August 14, 2019 at 9:33:02 AM UTC-4, Mark Waite wrote:
>>
>> When you used those steps in Blue Ocean, you defined a Pipeline in the
>> branch where the Jenkinsfile was stored by Blue Ocean.  I think that is
>> what you wanted in the SCM repository.  You're correct that Blue Ocean
>> created a multibranch pipeline as part of that editing process.
>>
>> If you'd like a job which is not a multibranch Pipeline, create that job
>> interactively with the Jenkins "New Item" menu.  Choose "Pipeline" as the
>> item type and use "Pipeline from SCM" with the repository name and the
>> branch name that you want to create.  In that case, the Jenkinsfile must
>> already exist in the repository.  That's a less typical use case, since
>> most users prefer to have Pipelines automatically created and deleted as
>> branches are created and deleted on their git repository.
>>
>> If that is your preferred working model, then you could use Blue Ocean to
>> create the Pipeline, delete the job which Blue Ocean created, then
>> interactively create a Pipeline job which is not a multibranch Pipeline.
>>
>> Once the job is created (either through Blue Ocean as a multibranch
>> pipeline or through the interactive "New Item" as a pipeline or through an
>> organization folder), then you can use Blue Ocean to launch jobs and to
>> view the execution progress of the pipeline.
>>
>> Thanks,
>> Mark Waite
>>
>> On Tuesday, August 13, 2019 at 1:14:54 PM UTC-7, Louis Elston wrote:
>>>
>>> Mark Wrote..."Blue Ocean is not limited to multibranch Pipelines.  You
>>> can use the Blue Ocean editor to create a Pipeline in a git repository that
>>> has no Jenkinsfile on any branch."
>>>
>>> Can someone point me to an example of this?  I have a GitHub repository
>>> with a master branch and a branch1 branch.  I used Blue Ocean, selected
>>> "new pipeline", selected to store the JenkinsFile in the Master, it created
>>> the pipeline.  When I select that particular new job, on the left hand
>>> side, it shows "Scan repository now, , ,Delete Multibranch Pipeline".  In
>>> other words, this is Multibranch pipeline.  Where is the option to use Blue
>>> Ocean to either create, or edit, a Non-MultiBranch pipeline?  What is it
>>> that I am missing or not understanding here?
>>>
>>> On Tuesday, August 6, 2019 at 12:07:24 PM UTC-4, Mark Waite wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Aug 6, 2019 at 9:36 AM Louis Elston 
>>>> wrote:
>>>>
>>>>> I believe that this is a bug.  What do I need to do to either get
>>>>> comments, or action on this?
>>>>>
>>>>>
>>>> I believe it is not a bug.  Blue Ocean is not designed, tested, or
>>>> expected to work with a git repository on a local file system.  It is
>>>> d

Re: Converting to pipeline questions

2019-08-14 Thread Mark Waite
Thanks also for detecting that issue.  The documentation does say that 
local repositories are supported.  I was wrong.  However, there are 
important limitations with local repositories that make them a poor choice 
for any user and an especially poor choice for first time users.

I've submitted https://github.com/jenkins-infra/jenkins.io/pull/2411 to 
guide users towards remote repositories.

Thanks!
Mark Waite

On Tuesday, August 6, 2019 at 2:54:29 PM UTC-7, Louis Elston wrote:
>
> I guess that either I misread this page, or it is out of date already...
> https://jenkins.io/doc/book/blueocean/creating-pipelines/ .  It says "You 
> now need to specify a local 
> <https://jenkins.io/doc/book/blueocean/creating-pipelines/#local-repository> 
> or 
> a remote 
> <https://jenkins.io/doc/book/blueocean/creating-pipelines/#remote-repository> 
> repository 
> from which to build your Pipeline project".  I was trying to test 
> converting our existing system to pipeline, and getting permission and 
> funding for another large GitHub repository was not in the cards right now, 
> so, I was attempting to do this work on a test system, with the repository 
> there.  I will try a Git repository on a different\remote system.  We do 
> not have Linux, and I do not have that experience (only Windows). 
>
> It also said "Note: Under the hood, a Pipeline project created through 
> Blue Ocean is actually "multibranch Pipeline". Therefore, Jenkins looks for 
> the presence of at least one Jenkinsfile in any branch of your repository.  
> So, your comment "Blue Ocean is not limited to multibranch Pipelines," is 
> news to me.
>
> My version of Jenkins is actually 2.176.2 (on my test VM), as I did 
> recently upgrade it.  When I mentioned 2.107, I was probably looking at the 
> actual production system.   I cannot even keep the current classic 
> Jenkins build system up to date (I see all kinds of red warnings when I go 
> into Manage), but it is feared that any change could possible cause a 
> problem that could delay a build or the release of the product.  So thus I 
> try to work on a test system.  We are behind corp firewalls, so they that 
> figure that the production system is safe.  
>
> I had worked my way through the cloudbees Blue Ocean tutorial, but only 
> with help from them.  I cannot recommend it.  I have found over the years, 
> that people who put together online course and write books, have someone 
> who is already familiar with the context, and can fill in the missing 
> pieces, do the reviewing.  No one uses someone new to the subject matter 
> try to work through it, to see if it really can be understood, and 
> completed successfully. Unless you are a real DevOps type, it can be 
> difficult to understand the documentation.  Also a lot the 
> courses\tutorials\books are using containers.  Again something that I do 
> not see them allowing me to play with, so that rules them out.  I had 
> recently purchased the book "Beginning Jenkins Blue Ocean".  No where in 
> the online information did it mention Docker, but that is what the book 
> requires.
>
> I do appreciate you responding, and I will look at the links that you 
> listed.
>
>
> On Tuesday, August 6, 2019 at 12:07:24 PM UTC-4, Mark Waite wrote:
>>
>>
>>
>> On Tue, Aug 6, 2019 at 9:36 AM Louis Elston  wrote:
>>
>>> I believe that this is a bug.  What do I need to do to either get 
>>> comments, or action on this?
>>>
>>>
>> I believe it is not a bug.  Blue Ocean is not designed, tested, or 
>> expected to work with a git repository on a local file system.  It is 
>> designed, tested, and known to work with remote git servers, including 
>> GitHub, Bitbucket, and plain Git.  A pull request is pending to include 
>> Perforce support as well.
>>
>> Why doesn't Blue Ocean support git repositories on a local file system?  
>> Git repositories on a local file system are only available from agents that 
>> share the same file system.  Most Jenkins best practices include the 
>> recommendation, "Do not run builds on the master, use an agent".  Running 
>> builds on the master provides the executing job with full access to the 
>> file system of the Jenkins master.
>>
>> Recommendation: Configure a git server and use that git server as your 
>> repository.  A git server could be as simple as a Linux computer with a 
>> shell account that hosts the bare repository or could include a web 
>> interface with Gitea (my favorite for local installation) or Gitlab or 
>> could use a remote repository (like GitHub, Bitbucket, Visual Studio, 
>> Assembla, Beanst

Re: Converting to pipeline questions

2019-08-14 Thread Mark Waite
When you used those steps in Blue Ocean, you defined a Pipeline in the 
branch where the Jenkinsfile was stored by Blue Ocean.  I think that is 
what you wanted in the SCM repository.  You're correct that Blue Ocean 
created a multibranch pipeline as part of that editing process.

If you'd like a job which is not a multibranch Pipeline, create that job 
interactively with the Jenkins "New Item" menu.  Choose "Pipeline" as the 
item type and use "Pipeline from SCM" with the repository name and the 
branch name that you want to create.  In that case, the Jenkinsfile must 
already exist in the repository.  That's a less typical use case, since 
most users prefer to have Pipelines automatically created and deleted as 
branches are created and deleted on their git repository.

If that is your preferred working model, then you could use Blue Ocean to 
create the Pipeline, delete the job which Blue Ocean created, then 
interactively create a Pipeline job which is not a multibranch Pipeline.

Once the job is created (either through Blue Ocean as a multibranch 
pipeline or through the interactive "New Item" as a pipeline or through an 
organization folder), then you can use Blue Ocean to launch jobs and to 
view the execution progress of the pipeline.

Thanks,
Mark Waite

On Tuesday, August 13, 2019 at 1:14:54 PM UTC-7, Louis Elston wrote:
>
> Mark Wrote..."Blue Ocean is not limited to multibranch Pipelines.  You can 
> use the Blue Ocean editor to create a Pipeline in a git repository that has 
> no Jenkinsfile on any branch."
>
> Can someone point me to an example of this?  I have a GitHub repository 
> with a master branch and a branch1 branch.  I used Blue Ocean, selected 
> "new pipeline", selected to store the JenkinsFile in the Master, it created 
> the pipeline.  When I select that particular new job, on the left hand 
> side, it shows "Scan repository now, , ,Delete Multibranch Pipeline".  In 
> other words, this is Multibranch pipeline.  Where is the option to use Blue 
> Ocean to either create, or edit, a Non-MultiBranch pipeline?  What is it 
> that I am missing or not understanding here?   
>
> On Tuesday, August 6, 2019 at 12:07:24 PM UTC-4, Mark Waite wrote:
>>
>>
>>
>> On Tue, Aug 6, 2019 at 9:36 AM Louis Elston  wrote:
>>
>>> I believe that this is a bug.  What do I need to do to either get 
>>> comments, or action on this?
>>>
>>>
>> I believe it is not a bug.  Blue Ocean is not designed, tested, or 
>> expected to work with a git repository on a local file system.  It is 
>> designed, tested, and known to work with remote git servers, including 
>> GitHub, Bitbucket, and plain Git.  A pull request is pending to include 
>> Perforce support as well.
>>
>> Why doesn't Blue Ocean support git repositories on a local file system?  
>> Git repositories on a local file system are only available from agents that 
>> share the same file system.  Most Jenkins best practices include the 
>> recommendation, "Do not run builds on the master, use an agent".  Running 
>> builds on the master provides the executing job with full access to the 
>> file system of the Jenkins master.
>>
>> Recommendation: Configure a git server and use that git server as your 
>> repository.  A git server could be as simple as a Linux computer with a 
>> shell account that hosts the bare repository or could include a web 
>> interface with Gitea (my favorite for local installation) or Gitlab or 
>> could use a remote repository (like GitHub, Bitbucket, Visual Studio, 
>> Assembla, Beanstalk, Gitlab, etc.).
>>
>> For your multibranch question, you need a Jenkinsfile on every branch 
>> that you want to run with a Pipeline from SCM.
>>
>> Blue Ocean is not limited to multibranch Pipelines.  You can use the Blue 
>> Ocean editor to create a Pipeline in a git repository that has no 
>> Jenkinsfile on any branch.
>>
>> The Jenkins community is a community.  Members of the community are 
>> motivated by different things to decide whether they will respond or not.
>>
>> In this case, Jenkins 2.107.1 is 15 months old.  The Jenkins community 
>> provides security updates for the current long term support release 
>> (2.176.2) and current weekly release (2.187).  LTS releases every 3 
>> months.  Jenkins 2.107.1 was released 16 months ago.  That is 5 LTS 
>> releases ago.  Some hesitation to respond may be due to the outdated 
>> version you're running.  There have been many improvements to Jenkins 
>> Pipeline in the 5 LTS versions since Jenkins 2.107.1.
>>
>> There are many different ways that you can learn more

Re: Gradle Tool Failed Download

2019-08-07 Thread Mark Waite
AccessorImpl.java:45)
>   at 
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1963)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1958)
>   at java.base/java.security.AccessController.doPrivileged(Native Method)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1957)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1525)
>   at 
> java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
>   at 
> java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:245)
>   at 
> org.jvnet.robust_http_client.RetryableHttpStream.getStream(RetryableHttpStream.java:98)
>   at 
> org.jvnet.robust_http_client.RetryableHttpStream.(RetryableHttpStream.java:91)
>   at hudson.ProxyConfiguration.getInputStream(ProxyConfiguration.java:285)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:924)
> Caused: java.io.IOException: Failed to install 
> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:938)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
>   at 
> hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
>   at 
> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
>   at 
> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
>   at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
>   at 
> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:92)
>   at 
> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:30)
>   at 
> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:152)
>   at 
> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:133)
>   at 
> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
>
> onsdag 7. august 2019 19.28.15 UTC+2 skrev Mark Waite følgende:
>>
>> I would guess that you may already be using a modified cacerts file which
>> does not include the authority that is certifying the validity of the SSL
>> certificate on the gradle site.
>>
>> When I download from that URL, my web browser reports no issues from
>> Google Chrome on Windows and no issues from wget on a FreeBSD computer.
>>
>> On Wed, Aug 7, 2019 at 10:51 AM Sverre Moe  wrote:
>>
>>> This has worked before. Now that we where to upgrade from Gradle 5.0 to
>>> 5.5 and added the tool gradle-5.5 it fails to retrieve the archive.
>>>
>>> Anyone have an idea what the problem might be?
>>>
>>> Running both Jenkins and Agents on Java 8 Update 221.
>>>
>>> Is there any way arround this without hacking the JRE cacerts with the
>>> gradle web site certificate?
>>>
>>> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
>>> valid certification path to requested target
>>> at 
>>> java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
>>> at 
>>> java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
>>> at 
>>> java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
>>> at 
>>> java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
>>> Caused: sun.security.validator.ValidatorException: PKIX path building failed
>>> at 
>>> java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
>>> at 
>>> java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidato

Re: Gradle Tool Failed Download

2019-08-07 Thread Mark Waite
OException: Failed to install 
> https://services.gradle.org/distributions/gradle-5.5.1-bin.zip to 
> /home/build/jenkins-test/tools/hudson.plugins.gradle.GradleInstallation/gradle-5.5
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:938)
>   at hudson.FilePath.installIfNecessaryFrom(FilePath.java:846)
>   at 
> hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:77)
>   at 
> hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69)
>   at 
> hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109)
>   at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
>   at 
> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:92)
>   at 
> hudson.plugins.gradle.GradleInstallation.forNode(GradleInstallation.java:30)
>   at 
> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:152)
>   at 
> org.jenkinsci.plugins.workflow.steps.ToolStep$Execution.run(ToolStep.java:133)
>   at 
> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:834)
>
> --
> 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/93ecd2ab-622a-4306-ad97-6546972c3471%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/93ecd2ab-622a-4306-ad97-6546972c3471%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGcos8AcPadeP2odSM%3DbynXGTswNg5j4ip%3D2mFpEk6rQg%40mail.gmail.com.


Re: Converting to pipeline questions

2019-08-06 Thread Mark Waite
On Tue, Aug 6, 2019 at 9:36 AM Louis Elston  wrote:

> I believe that this is a bug.  What do I need to do to either get
> comments, or action on this?
>
>
I believe it is not a bug.  Blue Ocean is not designed, tested, or expected
to work with a git repository on a local file system.  It is designed,
tested, and known to work with remote git servers, including GitHub,
Bitbucket, and plain Git.  A pull request is pending to include Perforce
support as well.

Why doesn't Blue Ocean support git repositories on a local file system?
Git repositories on a local file system are only available from agents that
share the same file system.  Most Jenkins best practices include the
recommendation, "Do not run builds on the master, use an agent".  Running
builds on the master provides the executing job with full access to the
file system of the Jenkins master.

Recommendation: Configure a git server and use that git server as your
repository.  A git server could be as simple as a Linux computer with a
shell account that hosts the bare repository or could include a web
interface with Gitea (my favorite for local installation) or Gitlab or
could use a remote repository (like GitHub, Bitbucket, Visual Studio,
Assembla, Beanstalk, Gitlab, etc.).

For your multibranch question, you need a Jenkinsfile on every branch that
you want to run with a Pipeline from SCM.

Blue Ocean is not limited to multibranch Pipelines.  You can use the Blue
Ocean editor to create a Pipeline in a git repository that has no
Jenkinsfile on any branch.

The Jenkins community is a community.  Members of the community are
motivated by different things to decide whether they will respond or not.

In this case, Jenkins 2.107.1 is 15 months old.  The Jenkins community
provides security updates for the current long term support release
(2.176.2) and current weekly release (2.187).  LTS releases every 3
months.  Jenkins 2.107.1 was released 16 months ago.  That is 5 LTS
releases ago.  Some hesitation to respond may be due to the outdated
version you're running.  There have been many improvements to Jenkins
Pipeline in the 5 LTS versions since Jenkins 2.107.1.

There are many different ways that you can learn more about Jenkins
Pipeline.

   - Tutorials -  https://jenkins.io/doc/tutorials/
   - User Handbook -  https://jenkins.io/doc/book/pipeline/
   - Jenkins Minute videos -
   https://jenkins.io/blog/2017/08/08/introducing-jenkins-minute/
   - CloudBees' free Pipeline Fundamentals core -
   
https://standard.cbu.cloudbees.com/cloudbees-university-jenkins-pipeline-fundamentals
   - Udemy courses on Jenkins Pipeline -
   https://www.udemy.com/courses/search/?src=ukw=jenkins%20pipeline

Mark Waite


> On Thursday, August 1, 2019 at 5:05:02 PM UTC-4, Louis Elston wrote:
>>
>> Studying and playing with pipelines.  I see that you can use Declarative
>> in the Pipeline Scrip window, but it still stores it in the config.xml
>> file.  And I have played with the combination of both Declarative and non
>> Declarative in the same script.
>>
>> I am trying to understand the Blue Ocean interface, the word
>> "MultiBranch" is throwing me a little.  We do not create test branches, and
>> them merge them back into the master.  In the repository, we have branches
>> for each release of the product, and we rarely go back to previous
>> branches\versions.  So, if I am working on branchV9 right now, do I also
>> need a Jenkinsfile in the Master branch, or any other of the previous
>> version branches?
>>
>> I have been playing with Blue Ocean (which only does MultiBranch
>> pipelines).  I am on a Windows system, Jenkins 2.176.2, and have all the
>> latest Blue Ocean plugins as of today (1.18.0).  I am accessing a local Git
>> repository (not GitHub), and am running into the following...
>>
>> If I try to use use “c:\GitRepos\Pipelines1\.git”, i get "not a valid
>> name"...
>>
>> [image: 1.PNG]
>>
>>
>> [image: 2.PNG]
>>
>>
>>
>> [image: 3.PNG]
>>
>>
>> [image: 4.PNG]
>>
>>
>> Why is this happening?
>>
>>
>>
>>
>>
>>
>> On Monday, July 29, 2019 at 11:40:56 AM UTC-4, Louis Elston wrote:
>>>
>>> 07/17/19 – wrote this…
>>>
>>> We are currently using Windows \ Jenkins 2.107.1 (no pipeline), and I am
>>> researching going to pipeline. We have a nightly build job, that fetches
>>> from repositories, and submits and waits on other jobs. I see 9 jobs
>>> running on the same Master node (we only have a master), at the same time.
>>> I am not clear on if we should have one Jenkinsfile or multiple
>>> Jenkinsfiles. It will not be a multibranch pipeline, as we do not create
>>> test branches and then

Re: Azure windows slave keeps disconnecting

2019-08-05 Thread Mark Waite
On Mon, Aug 5, 2019 at 9:33 AM Shubham Bansal  wrote:

>
> https://pastebin.com/yzL2vE9g
> Did you see these logs?
>
>
Yes. Did you see my quote from those logs in my reply 5 August 2019
18:17:05 UTC+5:30?

I don't have anything else to offer.  There are thousands of installations
successfully running Jenkins masters and Jenkins agents on different
machines using the same connection technique you're using.  I've made my
guesses about what might be different in your environment compared to those
other installations.

Mark Waite


>
> On Monday, 5 August 2019 21:01:46 UTC+5:30, Mark Waite wrote:
>>
>>
>>
>> On Mon, Aug 5, 2019 at 6:54 AM Shubham Bansal  wrote:
>>
>>> The protocol is chosen as "Inbound TCP Agent Protocol/4 (TLS
>>> encryption)" with fixed port "5378".
>>>
>>
>> That's a reasonable configuration.  That is listed as an unassigned port
>> in at least one of the ports databases
>> <https://www.speedguide.net/port.php?port=5378>, so it should be
>> reasonable to use that port number.
>>
>>
>>> What can possibly be an issue here?
>>>
>>
>> Something on the agent could be killing the agent process.
>> Something on the network between the agent and the master could be
>> breaking or damaging the communication.
>> Something on the master could be breaking or damaging the communication
>> between the agent and the master.
>>
>>
>>> And you have mentioned that something is changing the configuration, is
>>> there a way to figure that out what is the cause?
>>>
>>
>> Unless you see protocol 4 listed as disabled, then it is unlikely that
>> anything has changed the configuration.  I was speculating that something
>> might be changing the configuration, but if something is changing the
>> configuration, then you should see the protocol listed as 'disabled'
>> instead of 'enabled'.
>>
>> Mark Waite
>>
>>
>>>
>>> On Monday, 5 August 2019 18:17:05 UTC+5:30, Mark Waite wrote:
>>>>
>>>> When the master log says:
>>>>
>>>>
>>>>1. Aug 05, 2019 8:54:51 AM hudson.remoting.jnlp.Main$CuiListener
>>>>error
>>>>2. SEVERE: The server rejected the connection: None of the
>>>>protocols were accepted
>>>>3. java.lang.Exception: The server rejected the connection: None of
>>>>the protocols were accepted
>>>>4. at
>>>>hudson.remoting.Engine.onConnectionRejected(Engine.java:682)
>>>>5. at hudson.remoting.Engine.innerRun(Engine.java:639)
>>>>6. at hudson.remoting.Engine.run(Engine.java:474)
>>>>
>>>>
>>>> that might hint that either something is damaging the communication
>>>> between the agent or something is changing the configuration of the master
>>>> to reject agent protocols that were previously accepted.  The protocols
>>>> which are accepted can be modified from a "Configure Global Security" page
>>>> of "Manage Jenkins".  The "Agents" section of that page includes a link to
>>>> enable and disable specific protocols.
>>>>
>>>> On Mon, Aug 5, 2019 at 6:29 AM Shubham Bansal 
>>>> wrote:
>>>>
>>>>> https://pastebin.com/ib0PK5af
>>>>>
>>>>> Can you tell me more from these logs of the slave windows machine?
>>>>>
>>>>>
>>>>> On Monday, 5 August 2019 17:42:23 UTC+5:30, Mark Waite wrote:
>>>>>>
>>>>>> Connecting the agent to the master *is* a robust way to connect.
>>>>>> Many users around the world use that method to connect agents to masters,
>>>>>> including Windows masters, Linux masters, and other platforms.
>>>>>>
>>>>>> If the agent is being disconnected after some time, there may be
>>>>>> something on the agent computer which kills the client process that runs 
>>>>>> on
>>>>>> the agent (for example, some program that won't allow Java programs to 
>>>>>> run
>>>>>> for an extended period).  If the agent process dies or is killed on the
>>>>>> agent computer, the agent will be disconnected.  If you're running the
>>>>>> agent process from the command line, then you may find hints to the cause
>>>>>> of the command line failure in the command prompt window that launched 
>>>

Re: Azure windows slave keeps disconnecting

2019-08-05 Thread Mark Waite
On Mon, Aug 5, 2019 at 6:54 AM Shubham Bansal  wrote:

> The protocol is chosen as "Inbound TCP Agent Protocol/4 (TLS encryption)"
> with fixed port "5378".
>

That's a reasonable configuration.  That is listed as an unassigned port in
at least one of the ports databases
<https://www.speedguide.net/port.php?port=5378>, so it should be reasonable
to use that port number.


> What can possibly be an issue here?
>

Something on the agent could be killing the agent process.
Something on the network between the agent and the master could be breaking
or damaging the communication.
Something on the master could be breaking or damaging the communication
between the agent and the master.


> And you have mentioned that something is changing the configuration, is
> there a way to figure that out what is the cause?
>

Unless you see protocol 4 listed as disabled, then it is unlikely that
anything has changed the configuration.  I was speculating that something
might be changing the configuration, but if something is changing the
configuration, then you should see the protocol listed as 'disabled'
instead of 'enabled'.

Mark Waite


>
> On Monday, 5 August 2019 18:17:05 UTC+5:30, Mark Waite wrote:
>>
>> When the master log says:
>>
>>
>>1. Aug 05, 2019 8:54:51 AM hudson.remoting.jnlp.Main$CuiListener error
>>2. SEVERE: The server rejected the connection: None of the protocols
>>were accepted
>>3. java.lang.Exception: The server rejected the connection: None of
>>the protocols were accepted
>>4. at hudson.remoting.Engine.onConnectionRejected(Engine.java:682)
>>5. at hudson.remoting.Engine.innerRun(Engine.java:639)
>>6. at hudson.remoting.Engine.run(Engine.java:474)
>>
>>
>> that might hint that either something is damaging the communication
>> between the agent or something is changing the configuration of the master
>> to reject agent protocols that were previously accepted.  The protocols
>> which are accepted can be modified from a "Configure Global Security" page
>> of "Manage Jenkins".  The "Agents" section of that page includes a link to
>> enable and disable specific protocols.
>>
>> On Mon, Aug 5, 2019 at 6:29 AM Shubham Bansal  wrote:
>>
>>> https://pastebin.com/ib0PK5af
>>>
>>> Can you tell me more from these logs of the slave windows machine?
>>>
>>>
>>> On Monday, 5 August 2019 17:42:23 UTC+5:30, Mark Waite wrote:
>>>>
>>>> Connecting the agent to the master *is* a robust way to connect.  Many
>>>> users around the world use that method to connect agents to masters,
>>>> including Windows masters, Linux masters, and other platforms.
>>>>
>>>> If the agent is being disconnected after some time, there may be
>>>> something on the agent computer which kills the client process that runs on
>>>> the agent (for example, some program that won't allow Java programs to run
>>>> for an extended period).  If the agent process dies or is killed on the
>>>> agent computer, the agent will be disconnected.  If you're running the
>>>> agent process from the command line, then you may find hints to the cause
>>>> of the command line failure in the command prompt window that launched the
>>>> agent.  If you're running the agent process by clicking the "Launch" button
>>>> to launch the agent from the browser, you may want to try running the agent
>>>> from the command line instead, just in case some diagnostic messages might
>>>> help you.
>>>>
>>>> There may be something in the networking definition between the master
>>>> and the agents which is causing the agent process to die.  Usually, when
>>>> the network connection is interrupted between a master and  agent launched
>>>> to connect to the master.  This seems less likely to be the problem, since
>>>> you mentioned that the when running as a restart, the service restarted
>>>> frequently.
>>>>
>>>> On Mon, Aug 5, 2019 at 5:46 AM Shubham Bansal 
>>>> wrote:
>>>>
>>>>> I have a Linux Azure machine as master and it connects to the windows
>>>>> slave machine using the option "Launch Agent by connecting it to master"
>>>>>
>>>>> This connects the agent fine but gets disconnected after some time
>>>>> (around 20-30 minutes). I tried running the agent as windows service but
>>>>> the service keeps restarting freque

Re: Azure windows slave keeps disconnecting

2019-08-05 Thread Mark Waite
When the master log says:


   1. Aug 05, 2019 8:54:51 AM hudson.remoting.jnlp.Main$CuiListener error
   2. SEVERE: The server rejected the connection: None of the protocols
   were accepted
   3. java.lang.Exception: The server rejected the connection: None of the
   protocols were accepted
   4. at hudson.remoting.Engine.onConnectionRejected(Engine.java:682)
   5. at hudson.remoting.Engine.innerRun(Engine.java:639)
   6. at hudson.remoting.Engine.run(Engine.java:474)


that might hint that either something is damaging the communication between
the agent or something is changing the configuration of the master to
reject agent protocols that were previously accepted.  The protocols which
are accepted can be modified from a "Configure Global Security" page of
"Manage Jenkins".  The "Agents" section of that page includes a link to
enable and disable specific protocols.

On Mon, Aug 5, 2019 at 6:29 AM Shubham Bansal  wrote:

> https://pastebin.com/ib0PK5af
>
> Can you tell me more from these logs of the slave windows machine?
>
>
> On Monday, 5 August 2019 17:42:23 UTC+5:30, Mark Waite wrote:
>>
>> Connecting the agent to the master *is* a robust way to connect.  Many
>> users around the world use that method to connect agents to masters,
>> including Windows masters, Linux masters, and other platforms.
>>
>> If the agent is being disconnected after some time, there may be
>> something on the agent computer which kills the client process that runs on
>> the agent (for example, some program that won't allow Java programs to run
>> for an extended period).  If the agent process dies or is killed on the
>> agent computer, the agent will be disconnected.  If you're running the
>> agent process from the command line, then you may find hints to the cause
>> of the command line failure in the command prompt window that launched the
>> agent.  If you're running the agent process by clicking the "Launch" button
>> to launch the agent from the browser, you may want to try running the agent
>> from the command line instead, just in case some diagnostic messages might
>> help you.
>>
>> There may be something in the networking definition between the master
>> and the agents which is causing the agent process to die.  Usually, when
>> the network connection is interrupted between a master and  agent launched
>> to connect to the master.  This seems less likely to be the problem, since
>> you mentioned that the when running as a restart, the service restarted
>> frequently.
>>
>> On Mon, Aug 5, 2019 at 5:46 AM Shubham Bansal  wrote:
>>
>>> I have a Linux Azure machine as master and it connects to the windows
>>> slave machine using the option "Launch Agent by connecting it to master"
>>>
>>> This connects the agent fine but gets disconnected after some time
>>> (around 20-30 minutes). I tried running the agent as windows service but
>>> the service keeps restarting frequently causing the build to fail of it is
>>> triggered at this time of restart process.
>>>
>>> Can someone here suggest a more robust way to connect?
>>>
>>>
>>> --
>>> 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/245d1ca6-c04a-469d-a3c3-5ee1e96ba966%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/245d1ca6-c04a-469d-a3c3-5ee1e96ba966%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
> --
> 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/a1bcedbd-1fa4-4bf2-866e-7652d4d6c98e%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/a1bcedbd-1fa4-4bf2-866e-7652d4d6c98e%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEKRT8eYNUkoRTmMf%2B4sjKtbyCuBHp6TkVm%2B06JJFjSaA%40mail.gmail.com.


Re: Azure windows slave keeps disconnecting

2019-08-05 Thread Mark Waite
Connecting the agent to the master *is* a robust way to connect.  Many
users around the world use that method to connect agents to masters,
including Windows masters, Linux masters, and other platforms.

If the agent is being disconnected after some time, there may be something
on the agent computer which kills the client process that runs on the agent
(for example, some program that won't allow Java programs to run for an
extended period).  If the agent process dies or is killed on the agent
computer, the agent will be disconnected.  If you're running the agent
process from the command line, then you may find hints to the cause of the
command line failure in the command prompt window that launched the agent.
If you're running the agent process by clicking the "Launch" button to
launch the agent from the browser, you may want to try running the agent
from the command line instead, just in case some diagnostic messages might
help you.

There may be something in the networking definition between the master and
the agents which is causing the agent process to die.  Usually, when the
network connection is interrupted between a master and  agent launched to
connect to the master.  This seems less likely to be the problem, since you
mentioned that the when running as a restart, the service restarted
frequently.

On Mon, Aug 5, 2019 at 5:46 AM Shubham Bansal  wrote:

> I have a Linux Azure machine as master and it connects to the windows
> slave machine using the option "Launch Agent by connecting it to master"
>
> This connects the agent fine but gets disconnected after some time (around
> 20-30 minutes). I tried running the agent as windows service but the
> service keeps restarting frequently causing the build to fail of it is
> triggered at this time of restart process.
>
> Can someone here suggest a more robust way to connect?
>
>
> --
> 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/245d1ca6-c04a-469d-a3c3-5ee1e96ba966%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/245d1ca6-c04a-469d-a3c3-5ee1e96ba966%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGOi2C1UjaNb-9w%2B7Tk4OCeNenTDSQjDcac-i8KuDRi%2Bg%40mail.gmail.com.


Re: Statistics plugin to help identify bottlenecks

2019-08-02 Thread Mark Waite
You're correct that the DevOptics metrics are stored centrally in the cloud
rather than being hosted on your servers.

On Fri, Aug 2, 2019 at 5:54 AM Bjoern Hinrichs 
wrote:

> Hi Mark,
>
> thanks for your input.
> DevOptics seems promising, but as far as I can see DevOptics can't be
> hosted on-site, i.e. we would be dependent on (and sending internal data
> to) CloudBee's servers? Unfortunately, that's not possible for us.
>
> Regards
> Björn
>
> Am 8/1/2019 um 5:23 PM schrieb Mark Waite:
>
> I use CloudBees DevOptics to track utilization by label.  The label
> tracking portion ("Run Insights") is free.  I used it to confirm that my
> cluster is "unbalanced" and needs much more Windows execution capacity in
> order to be balanced.  See more at
> https://www.cloudbees.com/products/cloudbees-devoptics
>
> Here is a screenshot of a portion of the report showing my lack of Windows
> executors.  The top nodes listed are individual windows agents, then the
> bottom of the image is the aggregate "windows" label (maintained by the
> platform labeler plugin).
>
> [image: devoptics-labels.png]
>
> On Thu, Aug 1, 2019 at 9:13 AM Bjoern Hinrichs 
> wrote:
>
>> Hi,
>>
>> we use Matrix jobs for our build and test pipeline.
>> All of our test agents carry labels describing OS version, OS language,
>> whether other tools are installed (and in which version), ...
>>
>> To identify bottlenecks we need a plugin that allows us to see
>> statistics like utilization of our nodes and (especially) wait times in
>> queue per label.
>>
>> We tried several plugins, but couldn't find one that fits our needs; the
>> last one we tried was Cluster Statistics Plugin, which gives an average
>> wait time in queue, but unfortunately not per label.
>>
>> Are there any plugins out there that might work for us?
>>
>> Thanks in advance
>> Björn Hinrichs
>>
>> --
>> 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/39a95742-f7f7-bbf5-8244-7d9ec8b21237%40btc-es.de
>> .
>>
>
>
> --
> Thanks!
> Mark Waite
> --
> 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/CAO49JtEWbku0qFsYAXcwQuMpczGmubFmxC0sR_U5ZTOFxwrKGw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEWbku0qFsYAXcwQuMpczGmubFmxC0sR_U5ZTOFxwrKGw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> --
> 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/dc5909a4-1df5-aee3-28aa-119bfa849d04%40btc-es.de
> <https://groups.google.com/d/msgid/jenkinsci-users/dc5909a4-1df5-aee3-28aa-119bfa849d04%40btc-es.de?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFj6X4y0rx-E9p-NKVNbs4yg39bLYz%3D4kxUd4BjioD9iQ%40mail.gmail.com.


Re: Statistics plugin to help identify bottlenecks

2019-08-01 Thread Mark Waite
I use CloudBees DevOptics to track utilization by label.  The label
tracking portion ("Run Insights") is free.  I used it to confirm that my
cluster is "unbalanced" and needs much more Windows execution capacity in
order to be balanced.  See more at
https://www.cloudbees.com/products/cloudbees-devoptics

Here is a screenshot of a portion of the report showing my lack of Windows
executors.  The top nodes listed are individual windows agents, then the
bottom of the image is the aggregate "windows" label (maintained by the
platform labeler plugin).

[image: devoptics-labels.png]

On Thu, Aug 1, 2019 at 9:13 AM Bjoern Hinrichs 
wrote:

> Hi,
>
> we use Matrix jobs for our build and test pipeline.
> All of our test agents carry labels describing OS version, OS language,
> whether other tools are installed (and in which version), ...
>
> To identify bottlenecks we need a plugin that allows us to see
> statistics like utilization of our nodes and (especially) wait times in
> queue per label.
>
> We tried several plugins, but couldn't find one that fits our needs; the
> last one we tried was Cluster Statistics Plugin, which gives an average
> wait time in queue, but unfortunately not per label.
>
> Are there any plugins out there that might work for us?
>
> Thanks in advance
> Björn Hinrichs
>
> --
> 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/39a95742-f7f7-bbf5-8244-7d9ec8b21237%40btc-es.de
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEWbku0qFsYAXcwQuMpczGmubFmxC0sR_U5ZTOFxwrKGw%40mail.gmail.com.


Re: Windows 7 Agents (slaves) via SSH

2019-07-30 Thread Mark Waite
On Tue, Jul 30, 2019 at 4:35 PM Mark Waite 
wrote:

> I launch my Windows 10 ssh agents using the instructions from the
> ssh-slaves plugin page:
>
>
> https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/CONFIGURE.md#launch-windows-slaves-using-microsoft-openssh
>
> They use the Microsoft OpenSSH server on Windows 10.
>
> I launch JNLP Windows agents with the following batch script:
>

I launch *Windows agents* from the Windows Desktop (calling them JNLP in
that case seems like a misnomer).  They are not using "Java Web Start" to
launch.  They are launched from a batch file.


> @ECHO ON
> CD %HOME%\bin
> CALL clean-temp-dirs
> CD %TEMP%
> RMDIR /S/Q .
> C:
> CD C:\J
> ROBOCOPY %HOME%\bin . agent.jar
> SET JAVA_HOME=C:\Users\MarkE\tools\jdk8u222-b10
> SET PATH=%JAVA_HOME%\bin;%PATH%
> set SECRET=the-secret-has-been-removed-for-this-email
> java -jar agent.jar -jnlpUrl
> http://mark-pc2.markwaite.net:8080/computer/cb-pc/slave-agent.jnlp
> -secret %SECRET%
>
>
> On Tue, Jul 30, 2019 at 11:39 AM Steve K 
> wrote:
>
>>
>> Thanks once again Mark.
>> May I bug you for some more info?  I was really hoping to answer this on
>> my own, but I feel like I'm chasing my tail.  Whenever I do searches for
>> Jenkins agent launch methods, I'm predominantly directed to a description
>> of JNLP usage or, to a lesser extent, SSH; neither of which I want for the
>> Win 7 machines.
>> Could you please provide a sample script that you leverage?
>> That would be greatly appreciated!
>>
>> --
>> 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/68d09b75-bd6f-4ec8-afdf-000efe443fdb%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/68d09b75-bd6f-4ec8-afdf-000efe443fdb%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Thanks!
> Mark Waite
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGGuPRFWWhCtdBqPFQJ7GVyh33xXXVnmqS-WROJcRM1Ww%40mail.gmail.com.


Re: Windows 7 Agents (slaves) via SSH

2019-07-30 Thread Mark Waite
I launch my Windows 10 ssh agents using the instructions from the
ssh-slaves plugin page:

https://github.com/jenkinsci/ssh-slaves-plugin/blob/master/doc/CONFIGURE.md#launch-windows-slaves-using-microsoft-openssh

They use the Microsoft OpenSSH server on Windows 10.

I launch JNLP Windows agents with the following batch script:

@ECHO ON
CD %HOME%\bin
CALL clean-temp-dirs
CD %TEMP%
RMDIR /S/Q .
C:
CD C:\J
ROBOCOPY %HOME%\bin . agent.jar
SET JAVA_HOME=C:\Users\MarkE\tools\jdk8u222-b10
SET PATH=%JAVA_HOME%\bin;%PATH%
set SECRET=the-secret-has-been-removed-for-this-email
java -jar agent.jar -jnlpUrl
http://mark-pc2.markwaite.net:8080/computer/cb-pc/slave-agent.jnlp -secret
%SECRET%


On Tue, Jul 30, 2019 at 11:39 AM Steve K 
wrote:

>
> Thanks once again Mark.
> May I bug you for some more info?  I was really hoping to answer this on
> my own, but I feel like I'm chasing my tail.  Whenever I do searches for
> Jenkins agent launch methods, I'm predominantly directed to a description
> of JNLP usage or, to a lesser extent, SSH; neither of which I want for the
> Win 7 machines.
> Could you please provide a sample script that you leverage?
> That would be greatly appreciated!
>
> --
> 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/68d09b75-bd6f-4ec8-afdf-000efe443fdb%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/68d09b75-bd6f-4ec8-afdf-000efe443fdb%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEVOD_Dp3BnfYzRBv-_00dXjdLftptREcMnU669z0EHAw%40mail.gmail.com.


Re: Windows 7 Agents (slaves) via SSH

2019-07-29 Thread Mark Waite
On Mon, Jul 29, 2019 at 12:26 PM Steve K 
wrote:

> Thanks Mark,
> Web articles, such as this "Installing OpenSSH on Windows 7
> <https://www.mcclellandlegge.com/2017-02-24-installsshd/>" gave me hope
> of finding a workable solution.
> I had also considered trying to use Cygwin, as described by Kohsuke
> Kawaguci in the Wiki page "SSH slaves and Cygwin
> <https://wiki.jenkins.io/display/JENKINS/SSH+slaves+and+Cygwin>", but
> that seemed like too much overhead when several slaves/agents need to be
> configured.
>
> Launching an agent with a batch file seems like a good alternative. Have
> you been able to auto-start such a script (for example, to run at boot
> time)?
>

I have a batch file on the Desktop of the computer with a link to that
Desktop batch file in the Startup folder for the specific user.  The
specific user is configured to auto-login.  Thus, those machines run the
agent automatically when they boot.

Running from a running Desktop account also assures that desktop access is
available (for things like Selenium tests).


> Thanks again.
>
> --
> 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/d7a41896-cfd6-4dc6-8007-649097fa0304%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/d7a41896-cfd6-4dc6-8007-649097fa0304%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHnCTnEbJ4eiJxkyNGaVRY%2BLvZCbVrcFyCDSk%2B3%2BZFj%3DQ%40mail.gmail.com.


Re: Create new item - Item name error 'Only alphanumerical characters allowed'

2019-07-26 Thread Mark Waite
I've not seen any report of that issue from anyone other than you.

When I asked if a folder containing the job included an unexpected
character, I was thinking of a Jenkins folder more than a directory on the
file system.  The directory on the file system which represents that
Jenkins folder would be inside a subdirectory or series of subdirectories
of /var/lib/jenkins/jobs/.

If you don't use Jenkins folders to organize your jobs, then that is not
the issue.

What version of Jenkins are you running that is broken?  What version of
Jenkins were you running when it was working?



On Fri, Jul 26, 2019 at 7:05 AM Laura López Senderos <
laurapeopl...@gmail.com> wrote:

> Hi Mark,
>
> The folder where every jobs are created is '/var/lib/jenkins/jobs'. This
> is the default folder and we've been able to create items on it since now.
>
> Maybe some plugin update, or the jenkins instance update has broken
> something... We can't rename the jobs neither :/ It's like the regex that
> checks the name of the job is not working well.
>
> Is there anyone having the same issue?
>
> Thanks.
>
>
> El viernes, 26 de julio de 2019, 14:43:42 (UTC+2), Mark Waite escribió:
>>
>> Possibly the folder where you're creating those items has a character in
>> its name that is outside the allowed set of characters?
>>
>> On Fri, Jul 26, 2019 at 5:55 AM Laura López Senderos 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> Since the lastest releases of Jenkins we're having a problem when
>>> creating new items. We always get the 'Only alphanumerical characters
>>> allowed' error when trying to create a new item.
>>>
>>> We've tried from multiple browsers, changing our system language and the
>>> error persists. We don't know why this is happening suddenly and we can't
>>> find out a solutions :(
>>>
>>> We've 14 projects created without problems, but for a month or so we're
>>> unable to create new ones.
>>>
>>> Any help will be appreciated.
>>>
>>> Thanks in advance.
>>>
>>> --
>>> 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/7920a84b-3706-447d-8b71-d3d54036c6e0%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/7920a84b-3706-447d-8b71-d3d54036c6e0%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
> --
> 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/4649dca6-d02d-495c-bf96-45a0120bdaf0%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/4649dca6-d02d-495c-bf96-45a0120bdaf0%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtG%3DESAXtTZAJfPcV8kaQCbt%2BnF2f6X8adjArPKGAATyww%40mail.gmail.com.


Re: Create new item - Item name error 'Only alphanumerical characters allowed'

2019-07-26 Thread Mark Waite
Possibly the folder where you're creating those items has a character in
its name that is outside the allowed set of characters?

On Fri, Jul 26, 2019 at 5:55 AM Laura López Senderos <
laurapeopl...@gmail.com> wrote:

> Hi everyone,
>
> Since the lastest releases of Jenkins we're having a problem when creating
> new items. We always get the 'Only alphanumerical characters allowed' error
> when trying to create a new item.
>
> We've tried from multiple browsers, changing our system language and the
> error persists. We don't know why this is happening suddenly and we can't
> find out a solutions :(
>
> We've 14 projects created without problems, but for a month or so we're
> unable to create new ones.
>
> Any help will be appreciated.
>
> Thanks in advance.
>
> --
> 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/7920a84b-3706-447d-8b71-d3d54036c6e0%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/7920a84b-3706-447d-8b71-d3d54036c6e0%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGEyVUGeYYMYU7gQsBQw4zeSG5V3kTJsR9-SRfuS%3DBC0Q%40mail.gmail.com.


Re: Windows 7 Agents (slaves) via SSH

2019-07-25 Thread Mark Waite
On Thu, Jul 25, 2019 at 3:55 PM Steve K 
wrote:

> Hello,
>
> Has anyone successfully implemented the use of SSH to launch Windows 7
> agents (slaves)?
> I have been attempting to setup OpenSSH, but I'm falling short of getting
> it working.
> For one thing, the sshd never shows up as one of my Services, even though
> I believe I've followed the steps necessary to register the service.
> If I attempt to launch sshd manually, I get ACCESS DENIED, even though I
> can successfully launch ssh-agent.
>
>
I would not expect OpenSSH server to ever work with Windows 7.  It doesn't
work with the original releases of Windows 10.  Microsoft didn't make
OpenSSH server available until a relatively recent Windows 10 service
pack.  It has been working quite well for me from the Windows 10 service
pack on the 3 or 4 Windows 10 machines that I run.


> We have been happily using JNLP for our Windows agents, but, as we deploy
> Java 11 on our slaves, the JNLP method is no longer available.
>

Since you were using JNLP from a web browser previously, I assume that
means you were launching from a desktop login.  If you're launching from a
desktop login, then you can launch the agent with a batch file instead of
using JNLP.  That works with Java 11.

Don't forget that the Java version running the agent process must be the
same major Java version as the Java version running the master.  If you're
running Java 11 on your master, you need to run Java 11 on the agent.  If
you're running Java 8 on the master, you need to run Java 8 on the agents.


>
> Please share any tips and tricks you may have needed to employ to make the
> SSH slaves work as expected.
>
> Thanks in advance.
>
> Steve K.
>
> --
> 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/1298b6db-6dd5-4226-8d0e-f394e50e3077%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/1298b6db-6dd5-4226-8d0e-f394e50e3077%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtF%2B4fYjd7o5eyBW_sS7i2RB8Cfwtg01ZiEiOz-ja0b7bQ%40mail.gmail.com.


Re: Build failure in Jenkins: DependencyCheckAnalyzer

2019-07-25 Thread Mark Waite
I suspect that someone removed the OWASP dependency check plugin from your
Jenkins server.  That seems to be the plugin that is providing the
`dependencyCheckAnalyzer`
keyword for the domain specific language.

Alternately, has the plugin been disabled in your installation?

As another alternative, possibly there is some runtime bug that caused the
keyword to be removed from the DSL?  That seems unlikely to me, but I guess
it could be possible.

On Thu, Jul 25, 2019 at 9:18 AM Jason Flowers 
wrote:

> Nope
>
> On Thursday, July 25, 2019 at 9:48:28 AM UTC-4, slide wrote:
>>
>> Did anything get updated on your Jenkins instance?
>>
>> On Thu, Jul 25, 2019, 06:27 Jason Flowers  wrote:
>>
>>> I am getting a build failure in Jenkins with our maven
>>> dependencycheckanalyzer. This is a piece of code we haven't changed and was
>>> working for a long time and randomly started failing our builds yesterday..
>>> apart from commented out the code to run the dependency check, any idea on
>>> how to resolve?
>>>
>>>
>>> java.lang.NoSuchMethodError: No such DSL method 'dependencyCheckAnalyzer' 
>>> found among steps [ansiColor, ... ]
>>>
>>> --
>>> 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/df0c1698-f90d-498d-b112-4541874328b5%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/df0c1698-f90d-498d-b112-4541874328b5%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
> 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/9fea5d24-b69e-4f5b-b601-4e19243375b6%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/9fea5d24-b69e-4f5b-b601-4e19243375b6%40googlegroups.com?utm_medium=email_source=footer>
> .
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFhqGx9FswQErvKCpTGoEBgeLVZh0eFkaoYOUd5mnVCPA%40mail.gmail.com.


Re: Pipeline durability in GitHub Organization Project

2019-07-12 Thread Mark Waite
Are you running the most recent releases of the Pipeline plugins?  That
symbol was first included in workflow job plugin version 2.17.

On Fri, Jul 12, 2019 at 6:37 AM Jan Kosecki  wrote:

> Yes, I do.
> From what I see, "workflow-job" ID references "Pipeline: Job" plug-in chuj
> I have installed.
>
> On Fri, 12 Jul 2019, 13:10 Mark Waite,  wrote:
>
>> The durabilityHint symbol is provided by the workflow-job plugin.  Do you
>> have that plugin installed?
>>
>> On Fri, Jul 12, 2019 at 6:04 AM Jan Kosecki 
>> wrote:
>>
>>> Hi,
>>>
>>> I've got a GitHub Organization Project that loads all requested
>>> repositories of the organization and builds them using Jenkinsfiles inside
>>> each repository.
>>> I've read this article https://jenkins.io/blog/2018/02/22/cheetah/ and
>>> I'm tempted to set dev builds to use "PERFORMANCE_OPTIMIZED" and only
>>> release builds to use "MAX_SURVIVABILITY".
>>> I tried to use "options { durabilityHint('PERFORMANCE_OPTIMIZED') }"
>>> like in article but it gets rejected by jenkins.
>>>
>>> Invalid option type "durabilityHint". Valid option types: [ansiColor, 
>>> catchError, checkoutToSubdirectory, lock, retry, script, 
>>> skipDefaultCheckout, timeout, timestamps, waitUntil, warnError, withAWS, 
>>> withContext, withCredentials, withEnv, ws] @ line 94, column 11.
>>>  durabilityHint('MAX_SURVIVABILITY')
>>>
>>>
>>> How can I set durability for different builds in GitHub Organization 
>>> Project?
>>>
>>> --
>>> 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/da1bc51c-91b4-4e5f-885a-1396fe1f8e0f%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/da1bc51c-91b4-4e5f-885a-1396fe1f8e0f%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
>> --
>> 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/CAO49JtELM1WQF0W4hdKG610d5-_tiC-nvX6A3WdzKUPgp06-%3DA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtELM1WQF0W4hdKG610d5-_tiC-nvX6A3WdzKUPgp06-%3DA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> 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/CA%2BroAGMPMqAnw7iojpJ%2BNDN%3DdUOWc_cNZJcv9jAPxpX2SwRGrA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CA%2BroAGMPMqAnw7iojpJ%2BNDN%3DdUOWc_cNZJcv9jAPxpX2SwRGrA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: trying to get Jenkins pipeline to run across multiple nodes in parallel

2019-07-12 Thread Mark Waite
}
> }
>
> }
> }
> }
>
>
> But it's not dynamic, I need to have a stage per machine. Does anyone have a 
> suggestion
>
> about how I can achieve what I have in my original code?
>
> I want to dynamically decide what nodes to run the code on.
>
> --
> 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/b2ae506c-023e-4604-896e-50b4eac6d817%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/b2ae506c-023e-4604-896e-50b4eac6d817%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Pipeline durability in GitHub Organization Project

2019-07-12 Thread Mark Waite
The durabilityHint symbol is provided by the workflow-job plugin.  Do you
have that plugin installed?

On Fri, Jul 12, 2019 at 6:04 AM Jan Kosecki  wrote:

> Hi,
>
> I've got a GitHub Organization Project that loads all requested
> repositories of the organization and builds them using Jenkinsfiles inside
> each repository.
> I've read this article https://jenkins.io/blog/2018/02/22/cheetah/ and
> I'm tempted to set dev builds to use "PERFORMANCE_OPTIMIZED" and only
> release builds to use "MAX_SURVIVABILITY".
> I tried to use "options { durabilityHint('PERFORMANCE_OPTIMIZED') }" like
> in article but it gets rejected by jenkins.
>
> Invalid option type "durabilityHint". Valid option types: [ansiColor, 
> catchError, checkoutToSubdirectory, lock, retry, script, skipDefaultCheckout, 
> timeout, timestamps, waitUntil, warnError, withAWS, withContext, 
> withCredentials, withEnv, ws] @ line 94, column 11.
>  durabilityHint('MAX_SURVIVABILITY')
>
>
> How can I set durability for different builds in GitHub Organization Project?
>
> --
> 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/da1bc51c-91b4-4e5f-885a-1396fe1f8e0f%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/da1bc51c-91b4-4e5f-885a-1396fe1f8e0f%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtELM1WQF0W4hdKG610d5-_tiC-nvX6A3WdzKUPgp06-%3DA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Running jobs sequentially on Jenkins ?

2019-07-09 Thread Mark Waite
https://jenkins.io/doc/book/pipeline/  is the online documentation for
Jenkins Pipeline.

There are also several Jenkins Minute video tutorials
<https://www.youtube.com/watch?v=FhDomw6BaHU=PLvBBnHmZuNQJsTCaXs91HRrmso7RNSl-L>
available
from YouTube

   - Creating your first Pipeline in Blue Ocean -
   https://www.youtube.com/watch?v=FhDomw6BaHU
   - Recording test results and artifacts -
   https://www.youtube.com/watch?v=c9E8kGuAwLU
   
<https://www.youtube.com/watch?v=c9E8kGuAwLU=PLvBBnHmZuNQJsTCaXs91HRrmso7RNSl-L=4>
   - Parallel stages -  https://www.youtube.com/watch?v=cCSZx3HmCwY
   
<https://www.youtube.com/watch?v=cCSZx3HmCwY=PLvBBnHmZuNQJsTCaXs91HRrmso7RNSl-L=7>
   - Conditional stages -  https://www.youtube.com/watch?v=YWb5Is6VwPg
   
<https://www.youtube.com/watch?v=YWb5Is6VwPg=PLvBBnHmZuNQJsTCaXs91HRrmso7RNSl-L=8>
   - Using git environment variables -
   https://www.youtube.com/watch?v=tziVDpNYlgM
   
<https://www.youtube.com/watch?v=tziVDpNYlgM=PLvBBnHmZuNQJsTCaXs91HRrmso7RNSl-L=9>

CloudBees also offers a free self-paced course, "Pipeline Fundamentals" at
https://standard.cbu.cloudbees.com/cloudbees-university-jenkins-pipeline-fundamentals

There is also a 24 minute video on creating a Pipeline with Blue Ocean at
https://www.youtube.com/watch?v=LzFmTiH8nos


On Tue, Jul 9, 2019 at 6:35 AM srinivasa rao 
wrote:

> Request to everyone please share Jenkins pipeline flow document
>
> --
> 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/0cb1d349-16bf-4039-8973-5286b8d98f05%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHVpcTDnRUJModi6OyMmCOcCKR-5UbWhUQF6%2BpkAR6dQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Github Branch Source Plugin not allowing individual folder configuration

2019-07-08 Thread Mark Waite
Wouldn't it be best to make the necessary changes inside the build scripts
that are called from the Jenkinsfile?

On Mon, Jul 8, 2019 at 2:15 PM Yash Nalla  wrote:

> If my use case requires me to make changes to individual job definitions
> EX: the build path, does anyone have any suggestions on how to do so within
> a GitHub organization?
>
>>
> Best,
>
> Yash Nalla
>
> --
> 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/9c307d05-ea7e-4805-a782-c0f163bd29f6%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/9c307d05-ea7e-4805-a782-c0f163bd29f6%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEfeig%3DgkrE77LSZw%3DbLyaDu%3D3thK10L8o9-sPRA9EF1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Github Branch Source Plugin not allowing individual folder configuration

2019-07-08 Thread Mark Waite
I may also be completely wrong.  My recollection is only a poor memory, not
anything that I verified by checking the behavior of past releases.  As far
as I can tell, it is intentional that the jobs created by the GitHub Branch
Source plugin cannot be reconfigured.

On Mon, Jul 8, 2019 at 2:01 PM Yash Nalla  wrote:

> I just went through the changelogs of the plugin and nothing like that is
> mentioned? Though if all the edits to job definitions were already being
> rolled back periodically I guess just removing that ability doesn't change
> anything in the long term.
>
> On Monday, July 8, 2019 at 3:32:18 PM UTC-4, Mark Waite wrote:
>>
>> I believe that it once was possible to modify the individual job
>> definitions of a GitHub Branch Source folder.  However, I believe the
>> modifications were also periodically reset (possibly by scanning for new
>> changes or by detecting new branches).  I believe that the capability to
>> edit individual job definitions was intentionally removed.
>>
>> At least that has been my assumption.
>>
>> On Mon, Jul 8, 2019 at 1:29 PM Yash Nalla  wrote:
>>
>>> Hi all,
>>>
>>> The subject line kinda says it all. The documentation for Github Branch
>>> Source plugin:
>>> https://go.cloudbees.com/docs/plugins/github-branch-source/ says that
>>> users can go in and "configuring different settings on each of those
>>> folders[repositories] if needed." However when i navigate into any of these
>>> folders/or use the drop down I can only View Configuration rather than edit
>>> it. I believe this might be some sort of bug because many of the fields in
>>> the view configuration are editable and would make sense to be editable.
>>>
>>> Best,
>>>
>>> Yash nalla
>>>
>>> --
>>> 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/6b0971fa-c016-4822-a4a2-15cf239d6392%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/6b0971fa-c016-4822-a4a2-15cf239d6392%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
> --
> 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/08a6e802-48ae-40d9-9e51-c4da190c40f2%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/08a6e802-48ae-40d9-9e51-c4da190c40f2%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Github Branch Source Plugin not allowing individual folder configuration

2019-07-08 Thread Mark Waite
I believe that it once was possible to modify the individual job
definitions of a GitHub Branch Source folder.  However, I believe the
modifications were also periodically reset (possibly by scanning for new
changes or by detecting new branches).  I believe that the capability to
edit individual job definitions was intentionally removed.

At least that has been my assumption.

On Mon, Jul 8, 2019 at 1:29 PM Yash Nalla  wrote:

> Hi all,
>
> The subject line kinda says it all. The documentation for Github Branch
> Source plugin: https://go.cloudbees.com/docs/plugins/github-branch-source/ 
> says
> that users can go in and "configuring different settings on each of those
> folders[repositories] if needed." However when i navigate into any of these
> folders/or use the drop down I can only View Configuration rather than edit
> it. I believe this might be some sort of bug because many of the fields in
> the view configuration are editable and would make sense to be editable.
>
> Best,
>
> Yash nalla
>
> --
> 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/6b0971fa-c016-4822-a4a2-15cf239d6392%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/6b0971fa-c016-4822-a4a2-15cf239d6392%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Git Plugin - Too Verbose

2019-07-05 Thread Mark Waite
Unfortunately, there isn't currently a way to quiet the log file noise from
the git plugin.

On Fri, Jul 5, 2019 at 1:21 PM Shaun McArthur  wrote:

> Is there a way to impose something like --quiet on the Git Plugin?
>
> It's way too verbose and the console gets cluttered.
>
> Thanks,
> Shaun
>
> --
> 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/d83dd1a1-d2f0-4dfd-9db0-a435c4cbb6f7%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/d83dd1a1-d2f0-4dfd-9db0-a435c4cbb6f7%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Skip a Jenkins job build in a pipeline

2019-07-02 Thread Mark Waite
One technique is to create a single Jenkins Pipeline job that performs all
10 of those steps, then use the declarative Pipeline ability to
conditionally skip a step based on conditions you decide.

However, I've never tried to manage that complex a Pipeline job, so I can't
comment more than to suggest you might experiment with that technique.

On Tue, Jul 2, 2019 at 7:48 AM Vijay Gongle  wrote:

> I have a Jenkins pipeline which has 10 Jobs configured to run one after
> the other in the post build action.
> Anytime there's a change in Job's related git code, the build is triggered
> and all the following jobs run though rest of the Job code were not
> committed.
>
> For e.g, in a series of 10 jobs in the pipeline, if there's a code change
> in 2nd job but not in 3rd job then I would like to skip the 2nd job and
> build the 3rd job directly.
> Likewise, any job where the code is not changed, would like to skip and
> jump to following job.
>
> Please help me if there;s a way to resolve this unwanted builds in the
> pipeline.
>
> --
> 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/345f6008-fdd7-4ff8-bb84-4018c99dd956%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/345f6008-fdd7-4ff8-bb84-4018c99dd956%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: fatal: git index-pack failed

2019-07-02 Thread Mark Waite
That's great news.  A git repository that needs more than 10 minutes to
clone is a really good candidate for reference repositories and all the
other techniques suggested in the "Git in the Large" video.  The first
preference with repositories that large is to reduce their size by removing
large files from the repository.  Unfortunately, most organizations can't
do that.  A previous organization where I worked had a 25 GB repository
that just kept growing due to large binary checkins.  Git large file
storage (LFS) is another lifesaver to avoid creating large repositories.
Good luck!

On Tue, Jul 2, 2019 at 8:49 AM Kevin Stevens  wrote:

> Hi Mark - whilst looking for a place to stash my reference repo I
> discovered that Jenkins is keeping a cache of git checkouts in the
> /var/lib/jenkins/cache folder, and by deleting these files the multibranch
> pipeline scan now succeeds, so there was obviously something corrupt in
> that cache (possibly caused by a recent instability issue with the Jenkins
> server hardware), so I've not implemented a reference repo.
> Thanks for your help ;-)
>
> Kevin
>
> On Tuesday, 2 July 2019 15:25:41 UTC+1, Kevin Stevens wrote:
>>
>> Thanks for the responses and the issue link Mark, I've increased the Git
>> timeout value as described, and confirmed in the log that the 30 minute
>> timeout is in effect, but I'm still seeing the same failure (i.e. fatal
>> error in Scan Multibranch Pipeline Now).
>> I was pretty confident that there's not a timeout issue as the failure
>> occurs in a matter of seconds, so I'm going to try the reference repo
>> approach which seems like it should work, but it would appear to be an
>> issue within the git client parsing to me. I'll confirm my outcome.
>>
>> Regards, Kevin
>>
>> On Tuesday, 2 July 2019 13:37:41 UTC+1, Mark Waite wrote:
>>>
>>> Sorry, I didn't read your description thoroughly enough.  You said:
>>>
>>> I'm getting a fatal error reported when doing a repository scan (Scan
>>>> Multibranch Pipeline Now) which was previously working.
>>>>
>>>
>>> The command line git log output indicates that your repository is large
>>> enough that it may be reaching the default 10 minute clone timeout.  Refer
>>> to https://issues.jenkins-ci.org/browse/JENKINS-38973 for a discussion
>>> of possible workarounds.
>>>
>>> On Tue, Jul 2, 2019 at 6:31 AM Mark Waite  wrote:
>>>
>>>> The repository in the workspace on the agent running that build is
>>>> probably damaged.  Wipe the workspace on the agent and run the job again.
>>>>
>>>> If wiping the workspace and running the job again does not resolve it,
>>>> you may also be encountering a timeout while cloning the repository.
>>>> Increase the timeout for the repository clone from its default of 10
>>>> minutes to something large enough that it will allow you to clone the
>>>> repository.
>>>>
>>>> The amount of output you're showing hints that the repository is large
>>>> or the network connection between the agent and the upstream cloned
>>>> repository is slow.  In either of those cases, you probably want to reduce
>>>> the clone time and the disc space use by applying one or more of the
>>>> techniques described in "Git in the Large
>>>> <https://youtu.be/jBGFjFc6Jf8?t=6434>".  Those techniques include (1)
>>>> reference repositories on the agent, (2) narrow refspecs, (3) shallow
>>>> clones, and (4) sparse checkouts.
>>>>
>>>> If this is a Pipeline repository and the failure is during the initial
>>>> clone of the repository, then you may also need to use lightweight checkout
>>>> to only checkout the Jenkinsfile rather than the entire repository.
>>>> Alternately for Pipelines, if your git provider is GitHub, Bitbucket, or
>>>> Gitea, you can significantly improve performance by using those branch
>>>> source plugins to manage the Pipeline instead of relying on low-level
>>>> command line git calls.
>>>>
>>>> Reference repositories are usually the most effective technique to
>>>> reduce data transfer time and disc space use for large git repositories.
>>>> Allan Burdajewicz of CloudBees wrote a great article on reference
>>>> repositories at
>>>> https://support.cloudbees.com/hc/en-us/articles/115001728812-Using-a-Git-reference-repository
>>>>  .
>>>>
>>>> On Tue, Jul 2, 2019 at 5:51 AM Kevin Stevens  wrote:
>>>>
>&g

Re: fatal: git index-pack failed

2019-07-02 Thread Mark Waite
Sorry, I didn't read your description thoroughly enough.  You said:

I'm getting a fatal error reported when doing a repository scan (Scan
> Multibranch Pipeline Now) which was previously working.
>

The command line git log output indicates that your repository is large
enough that it may be reaching the default 10 minute clone timeout.  Refer
to https://issues.jenkins-ci.org/browse/JENKINS-38973 for a discussion of
possible workarounds.

On Tue, Jul 2, 2019 at 6:31 AM Mark Waite  wrote:

> The repository in the workspace on the agent running that build is
> probably damaged.  Wipe the workspace on the agent and run the job again.
>
> If wiping the workspace and running the job again does not resolve it, you
> may also be encountering a timeout while cloning the repository.  Increase
> the timeout for the repository clone from its default of 10 minutes to
> something large enough that it will allow you to clone the repository.
>
> The amount of output you're showing hints that the repository is large or
> the network connection between the agent and the upstream cloned repository
> is slow.  In either of those cases, you probably want to reduce the clone
> time and the disc space use by applying one or more of the techniques
> described in "Git in the Large <https://youtu.be/jBGFjFc6Jf8?t=6434>".
> Those techniques include (1) reference repositories on the agent, (2)
> narrow refspecs, (3) shallow clones, and (4) sparse checkouts.
>
> If this is a Pipeline repository and the failure is during the initial
> clone of the repository, then you may also need to use lightweight checkout
> to only checkout the Jenkinsfile rather than the entire repository.
> Alternately for Pipelines, if your git provider is GitHub, Bitbucket, or
> Gitea, you can significantly improve performance by using those branch
> source plugins to manage the Pipeline instead of relying on low-level
> command line git calls.
>
> Reference repositories are usually the most effective technique to reduce
> data transfer time and disc space use for large git repositories.  Allan
> Burdajewicz of CloudBees wrote a great article on reference repositories at
> https://support.cloudbees.com/hc/en-us/articles/115001728812-Using-a-Git-reference-repository
>  .
>
> On Tue, Jul 2, 2019 at 5:51 AM Kevin Stevens  wrote:
>
>> I'm getting a fatal error reported when doing a repository scan (Scan
>> Multibranch Pipeline Now) which was previously working.
>> I've run the git commands manually from the command line (copied and
>> pasted) and they appear to work correctly, so it seems like a problem with
>> the Jenkins git client plugin.
>>
>> The scan log is below (repository name and account information modified
>> for security reasons).
>> I'm not clear if this is a GIT or a Jenkins git client problem. I've
>> cleared the Jenkins workspace and updated to the latest Jenkins plugins
>> (running on Ubuntu 18.04).
>> Is anyone able to offer help in debugging this issue please?
>>
>>
>> [Tue Jul 02 09:48:00 BST 2019] Starting branch indexing...
>>  > git --version # timeout=10
>> using GIT_ASKPASS to set credentials Jenkins Bitbucket User
>>  > git ls-remote --symref 
>> g...@bitbucket.org:my-company-name/my-repository-name.git
>> # timeout=10
>>  > git rev-parse --is-inside-work-tree # timeout=10
>> Setting origin to g...@bitbucket.org:
>> my-company-name/my-repository-name.git
>>  > git config remote.origin.url 
>> g...@bitbucket.org:my-company-name/my-repository-name.git
>> # timeout=10
>> Fetching & pruning origin...
>> Listing remote references...
>>  > git config --get remote.origin.url # timeout=10
>>  > git --version # timeout=10
>> using GIT_ASKPASS to set credentials Jenkins Bitbucket User
>>  > git ls-remote -h g...@bitbucket.org:my-company-name/my-repository-name.git
>> # timeout=10
>> Fetching upstream changes from origin
>>  > git config --get remote.origin.url # timeout=10
>> using GIT_ASKPASS to set credentials Jenkins Bitbucket User
>>  > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
>> --prune
>> ERROR: [Tue Jul 02 09:48:10 BST 2019] Could not fetch branches from
>> source 498872a6-3888-419f-9d2f-a2baa4520968
>> hudson.plugins.git.GitException: Command "git fetch --tags --progress
>> origin +refs/heads/*:refs/remotes/origin/* --prune" returned status code
>> 128:
>> stdout:
>> stderr: remote: Counting objects: 114, done.
>> remote: Compressing objects:   0% (1/114)
>> remote: Compressing objects:   1% (2/114)
>> remote: Compressing objects:   2% (3/114)
>> remote: 

Re: fatal: git index-pack failed

2019-07-02 Thread Mark Waite
te: Compressing objects:  73% (84/114)
> remote: Compressing objects:  74% (85/114)
> remote: Compressing objects:  75% (86/114)
> remote: Compressing objects:  76% (87/114)
> remote: Compressing objects:  77% (88/114)
> remote: Compressing objects:  78% (89/114)
> remote: Compressing objects:  79% (91/114)
> remote: Compressing objects:  80% (92/114)
> remote: Compressing objects:  81% (93/114)
> remote: Compressing objects:  82% (94/114)
> remote: Compressing objects:  83% (95/114)
> remote: Compressing objects:  84% (96/114)
> remote: Compressing objects:  85% (97/114)
> remote: Compressing objects:  86% (99/114)
> remote: Compressing objects:  87% (100/114)
> remote: Compressing objects:  88% (101/114)
> remote: Compressing objects:  89% (102/114)
> remote: Compressing objects:  90% (103/114)
> remote: Compressing objects:  91% (104/114)
> remote: Compressing objects:  92% (105/114)
> remote: Compressing objects:  93% (107/114)
> remote: Compressing objects:  94% (108/114)
> remote: Compressing objects:  95% (109/114)
> remote: Compressing objects:  96% (110/114)
> remote: Compressing objects:  97% (111/114)
> remote: Compressing objects:  98% (112/114)
> remote: Compressing objects:  99% (113/114)
> remote: Compressing objects: 100% (114/114)
> remote: Compressing objects: 100% (114/114), done.
> Receiving objects:   0% (1/114)
> Receiving objects:   1% (2/114)
> Receiving objects:   2% (3/114)
> Receiving objects:   3% (4/114)
> Receiving objects:   4% (5/114)
> Receiving objects:   5% (6/114)
> Receiving objects:   6% (7/114)
> Receiving objects:   7% (8/114)
> Receiving objects:   8% (10/114)
> Receiving objects:   9% (11/114)
> Receiving objects:  10% (12/114)
> Receiving objects:  11% (13/114)
> Receiving objects:  12% (14/114)
> Receiving objects:  13% (15/114)
> Receiving objects:  14% (16/114)
> error: object file .git/objects/21/a28795e9c6fa55f026860e0c2f0b08d1b31611
> is empty
> fatal: cannot read existing object info
> 21a28795e9c6fa55f026860e0c2f0b08d1b31611
> fatal: index-pack failed
>
> at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042)
> at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761)
> at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72)
> at
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442)
> at
> jenkins.plugins.git.AbstractGitSCMSource$8.run(AbstractGitSCMSource.java:575)
> at
> jenkins.plugins.git.AbstractGitSCMSource$8.run(AbstractGitSCMSource.java:556)
> at
> jenkins.plugins.git.AbstractGitSCMSource.doRetrieve(AbstractGitSCMSource.java:367)
> at
> jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:556)
> at jenkins.scm.api.SCMSource._retrieve(SCMSource.java:373)
> at jenkins.scm.api.SCMSource.fetch(SCMSource.java:283)
> at
> jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:634)
> at
> com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:277)
> at
> com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:164)
> at
> jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1025)
> at hudson.model.ResourceController.execute(ResourceController.java:97)
> at hudson.model.Executor.run(Executor.java:429)
> Finished: FAILURE
>
> --
> 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/b6a89f4c-7b2e-441d-ba26-cf46a762b0af%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/b6a89f4c-7b2e-441d-ba26-cf46a762b0af%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtH0ivhBiPTaWa0B1BeT_9sYaXiNKzDcJShLU_%3DvWP%3DNWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: java.lang.NoClassDefFoundError: org/apache/sshd/common/KeyPairProvider on Fedora 30 fresh install of Jenkins

2019-06-29 Thread Mark Waite
If that is not sufficient to resolve the issue, you might also try the
following steps to confirm that your system is configured so that it can
run Jenkins.  Some of the steps you might check include:

Check that you are running either Java 8 or Java 11.  Other Java versions
are not supported.

$ java -version

Download the latest Jenkins long term support release and run it from the
war file to confirm that it runs and you can connect to it.  You don't want
to run it long term like that, just confirm that it works before installing
the operating system package.

$ wget http://mirrors.jenkins.io/war-stable/latest/jenkins.war && java -jar
jenkins.war



On Sat, Jun 29, 2019 at 10:38 AM Mark Waite 
wrote:

> That listing seems to indicate that if you attempt to install Jenkins from
> your current repository definition, it will install Jenkins 1.651.3.
> Jenkins 1.651.3 is very old.
>
> The Jenkins installation instructions for Fedora are available in the
> Jenkins User Handbook section on "Installing" at
> https://jenkins.io/doc/book/installing/#fedora .  Those instructions add
> https://jenkins.io/doc/book/installing/#fedora as a repository and they
> have you install with `dnf`.
>
> There are also instructions for CentOS and Red Hat at
> http://pkg.jenkins-ci.org/redhat/ .  They are not part of the Jenkins
> User Handbook, but I believe they are known to work for CentOS
> distributions.
>
> On Sat, Jun 29, 2019 at 6:32 AM Heymen Nicolaij 
> wrote:
>
>> Extra info I installed from RPM weekly:
>>
>> rpm -q -a|grep jenkins
>> jenkins-webapp-1.651.3-10.fc30.noarch
>> jenkins-credentials-plugin-1.27-1.fc25.noarch
>> trilead-ssh2-217-12.jenkins8.fc30.noarch
>> jenkins-cli-1.651.3-10.fc30.noarch
>> jenkins-core-1.651.3-10.fc30.noarch
>> js-yui2-jenkins-2.9.0-10.fc24.noarch
>> jenkins-remoting-webapp-2.62.3-1.fc26.noarch
>> jenkins-pam-auth-plugin-1.2-3.fc24.noarch
>> jenkins-instance-identity-1.4-5.fc24.noarch
>> jenkins-script-security-plugin-1.18.1-1.fc25.noarch
>> jenkins-commons-jelly-1.1.20120928-10.fc24.noarch
>> jenkins-extras-memory-monitor-1.9-3.fc24.noarch
>> jenkins-external-monitor-job-plugin-1.4-4.fc24.noarch
>> jenkins-matrix-project-plugin-1.6-2.fc24.noarch
>> jenkins-javadoc-plugin-1.3-4.fc24.noarch
>> jenkins-matrix-auth-plugin-1.2-3.fc24.noarch
>> jenkins-icon-shim-1.0.4-4.fc24.noarch
>> jenkins-ssh-cli-auth-1.2-8.fc24.noarch
>> jenkins-version-number-1.1-11.fc30.noarch
>> jenkins-mailer-plugin-1.17-1.fc25.noarch
>> jenkins-winstone-2.8-10.fc30.noarch
>> jenkins-crypto-util-1.4-6.fc24.noarch
>> jenkins-ssh-slaves-plugin-1.10-3.fc24.noarch
>> jenkins-ldap-plugin-1.11-3.fc24.noarch
>> jenkins-1.651.3-10.fc30.noarch
>> jenkins-executable-war-webroot-1.29-11.fc30.noarch
>> jenkins-remoting-2.62.3-1.fc26.noarch
>> jenkins-task-reactor-1.4-9.fc30.noarch
>> jenkins-jexl-1.1-5.20111212.fc24.noarch
>> jenkins-junit-plugin-1.12-1.fc25.noarch
>> jenkins-json-lib-2.4-16.fc30.noarch
>> jenkins-ant-plugin-1.2-6.fc24.noarch
>> jenkins-antisamy-markup-formatter-plugin-1.3-2.fc24.noarch
>> jenkins-ssh-credentials-plugin-1.11-4.fc24.noarch
>> jenkins-xstream-1.4.7-15.jenkins1.fc30.noarch
>>
>> And see the following command running:
>>
>> ps -ef|grep java
>> jenkins  23630 1  3 14:25 ?00:00:15 /etc/alternatives/java
>> -Dcom.sun.akuma.Daemon=daemonized -Djava.awt.headless=true
>> -DJENKINS_HOME=/var/lib/jenkins -cp
>> /usr/share/jenkins/webroot//:/usr/share/jenkins/webroot//winstone.jar:/usr/share/java/jetty8/jetty-servlet-8.1.jar:/usr/share/java/jetty8/jetty-util-8.1.jar:/usr/share/java/jetty8/jetty-security-8.1.jar:/usr/share/java/jetty8/jetty-webapp-8.1.jar:/usr/share/java/jetty8/jetty-server-8.1.jar:/usr/share/java/jetty8/jetty-xml-8.1.jar:/usr/share/java/jetty8/jetty-continuation-8.1.jar:/usr/share/java/jetty8/jetty-io-8.1.jar:/usr/share/java/jetty8/jetty-http-8.1.jar:/usr/share/java/jetty8/jetty-servlet-8.1.jar:/usr/share/java/jetty8/jetty-util-8.1.jar:/usr/share/java/jetty8/jetty-security-8.1.jar:/usr/share/java/jetty8/jetty-webapp-8.1.jar:/usr/share/java/jetty8/jetty-server-8.1.jar:/usr/share/java/jetty8/jetty-xml-8.1.jar:/usr/share/java/jetty8/jetty-continuation-8.1.jar:/usr/share/java/jetty8/jetty-io-8.1.jar:/usr/share/java/jetty8/jetty-http-8.1.jar:/usr/share/java/jetty8/jetty-servlet-8.1.jar:/usr/share/java/jetty8/jetty-util-8.1.jar:/usr/share/java/jetty8/jetty-security-8.1.jar:/usr/share/java/jetty8/jetty-webapp-8.1.jar:/usr/share/java/jetty8/jetty-server-8.1.jar:/usr/share/java/jetty8/jetty-xml-8.1.jar:/usr/share/java/jetty8/jetty-continuation-8.1.jar:/usr/share/java/jetty8/jetty-io-8.1.jar:/usr/share/java/jetty8/jetty-http-8.1.jar:/usr/share/jav

Re: java.lang.NoClassDefFoundError: org/apache/sshd/common/KeyPairProvider on Fedora 30 fresh install of Jenkins

2019-06-29 Thread Mark Waite
.1.jar:/usr/share/java/jetty8/jetty-xml-8.1.jar:/usr/share/java/jetty8/jetty-continuation-8.1.jar:/usr/share/java/jetty8/jetty-io-8.1.jar:/usr/share/java/jetty8/jetty-http-8.1.jar:/usr/share/java/jetty8/jetty-servlet-8.1.jar:/usr/share/java/jetty8/jetty-util-8.1.jar:/usr/share/java/jetty8/jetty-security-8.1.jar:/usr/share/java/jetty8/jetty-webapp-8.1.jar:/usr/share/java/jetty8/jetty-server-8.1.jar:/usr/share/java/jetty8/jetty-xml-8.1.jar:/usr/share/java/jetty8/jetty-continuation-8.1.jar:/usr/share/java/jetty8/jetty-io-8.1.jar:/usr/share/java/jetty8/jetty-http-8.1.jar:/usr/share/java/jetty8/jetty-servlet-8.1.jar:/usr/share/java/jetty8/jetty-util-8.1.jar:/usr/share/java/jetty8/jetty-security-8.1.jar:/usr/share/java/jetty8/jetty-webapp-8.1.jar:/usr/share/java/jetty8/jetty-server-8.1.jar:/usr/share/java/jetty8/jetty-xml-8.1.jar:/usr/share/java/jetty8/jetty-continuation-8.1.jar:/usr/share/java/jetty8/jetty-io-8.1.jar:/usr/share/java/jetty8/jetty-http-8.1.jar:/usr/share/java/jetty8/jetty-servlet-8.1.jar:/usr/share/java/jetty8/jetty-util-8.1.jar:/usr/share/java/jetty8/jetty-security-8.1.jar:/usr/share/java/jetty8/jetty-webapp-8.1.jar:/usr/share/java/jetty8/jetty-server-8.1.jar:/usr/share/java/jetty8/jetty-xml-8.1.jar:/usr/share/java/jetty8/jetty-continuation-8.1.jar:/usr/share/java/jetty8/jetty-io-8.1.jar:/usr/share/java/jetty8/jetty-http-8.1.jar:/usr/share/java/glassfish-servlet-api.jar
> Main --logfile=/var/log/jenkins/jenkins.log
> --extractedFilesFolder=/usr/share/jenkins/webroot/
> --webroot=/usr/share/jenkins/webroot/ --daemon --httpPort=9090
> --ajp13Port=8009 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20
>
>
> Op zaterdag 29 juni 2019 13:01:55 UTC+2 schreef Heymen Nicolaij:
>>
>> Hi,
>>
>> Following stacktrace appears on fresh install of Jenkins on Fedora 30
>> machine:
>>
>> java.lang.NoClassDefFoundError: org/apache/sshd/common/KeyPairProvider
>> at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>> at
>> java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3167)
>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2310)
>> at
>> org.jvnet.hudson.annotation_indexer.Index$2$1.fetch(Index.java:103)
>> at
>> org.jvnet.hudson.annotation_indexer.Index$2$1.hasNext(Index.java:73)
>> at
>> org.jvnet.hudson.annotation_indexer.SubtypeIterator.fetch(SubtypeIterator.java:18)
>> at
>> org.jvnet.hudson.annotation_indexer.SubtypeIterator.hasNext(SubtypeIterator.java:28)
>> at
>> hudson.init.TaskMethodFinder.discoverTasks(TaskMethodFinder.java:56)
>> at
>> hudson.init.InitializerFinder.discoverTasks(InitializerFinder.java:33)
>> at
>> hudson.init.TaskMethodFinder.discoverTasks(TaskMethodFinder.java:32)
>> at
>> org.jvnet.hudson.reactor.TaskBuilder$2.discoverTasks(TaskBuilder.java:63)
>> at org.jvnet.hudson.reactor.Reactor.(Reactor.java:151)
>> at org.jvnet.hudson.reactor.Reactor.(Reactor.java:156)
>> at jenkins.model.Jenkins$8.(Jenkins.java:909)
>> at jenkins.model.Jenkins.executeReactor(Jenkins.java:909)
>> at jenkins.model.Jenkins.(Jenkins.java:818)
>> at hudson.model.Hudson.(Hudson.java:83)
>> at hudson.model.Hudson.(Hudson.java:79)
>> at hudson.WebAppMain$3.run(WebAppMain.java:225)
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.sshd.common.KeyPairProvider
>> at java.base/java.net
>> .URLClassLoader.findClass(URLClassLoader.java:471)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>> at
>> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:430)
>> at
>> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:383)
>> ... 19 more
>>
>> Any ideas ?
>>
>> Full logging can be found attached.
>>
>> Kind regards, Heymen
>>
>> --
> 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/9f4dd97e-5e87-43b0-b590-32b70eafa31c%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/9f4dd97e-5e87-43b0-b590-32b70eafa31c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEeEssZWGfs-Gvy7ww7tHZ1kjBO%3DWRrkmBV6zq%2B0U%3DE2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: java.lang.NoClassDefFoundError: org/apache/sshd/common/KeyPairProvider on Fedora 30 fresh install of Jenkins

2019-06-29 Thread Mark Waite
I can't duplicate the problem you're reporting.  Unfortunately, lots of
information is missing from the report that might help others as they try
to help you.

I ran `docker run -t jenkins/jenkins:2.182` and confirmed there was no
failure in that execution.  Since you didn't describe the Jenkins version
you're using, I assumed the most recent weekly.  What Jenkins version
are you using?

I suspect there are many Jenkins users running various Jenkins versions on
Fedora 30.  What might be different about your installation compared to
those other users?  For example, are you using a different file system?
Did you install using the Jenkins RPM or are you running from a downloaded
copy of the war file?  Did you start the process from the command line or
are you running Jenkins as a daemon?

Did you start Jenkins with an empty JENKINS_HOME directory or were there
files or directories already in the JENKINS_HOME directory?  Are the file
and directory permissions correct in the JENKINS_HOME directory?

On Sat, Jun 29, 2019 at 5:13 AM Heymen Nicolaij 
wrote:

> There seem to several class path errors as if the lib folder of the web
> app can't be found since the required classes can be found there as far as
> I can see.
>
> Op zaterdag 29 juni 2019 13:01:55 UTC+2 schreef Heymen Nicolaij:
>>
>> Hi,
>>
>> Following stacktrace appears on fresh install of Jenkins on Fedora 30
>> machine:
>>
>> java.lang.NoClassDefFoundError: org/apache/sshd/common/KeyPairProvider
>> at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
>> at
>> java.base/java.lang.Class.privateGetDeclaredMethods(Class.java:3167)
>> at java.base/java.lang.Class.getDeclaredMethods(Class.java:2310)
>> at
>> org.jvnet.hudson.annotation_indexer.Index$2$1.fetch(Index.java:103)
>> at
>> org.jvnet.hudson.annotation_indexer.Index$2$1.hasNext(Index.java:73)
>> at
>> org.jvnet.hudson.annotation_indexer.SubtypeIterator.fetch(SubtypeIterator.java:18)
>> at
>> org.jvnet.hudson.annotation_indexer.SubtypeIterator.hasNext(SubtypeIterator.java:28)
>> at
>> hudson.init.TaskMethodFinder.discoverTasks(TaskMethodFinder.java:56)
>> at
>> hudson.init.InitializerFinder.discoverTasks(InitializerFinder.java:33)
>> at
>> hudson.init.TaskMethodFinder.discoverTasks(TaskMethodFinder.java:32)
>> at
>> org.jvnet.hudson.reactor.TaskBuilder$2.discoverTasks(TaskBuilder.java:63)
>> at org.jvnet.hudson.reactor.Reactor.(Reactor.java:151)
>> at org.jvnet.hudson.reactor.Reactor.(Reactor.java:156)
>> at jenkins.model.Jenkins$8.(Jenkins.java:909)
>> at jenkins.model.Jenkins.executeReactor(Jenkins.java:909)
>> at jenkins.model.Jenkins.(Jenkins.java:818)
>> at hudson.model.Hudson.(Hudson.java:83)
>> at hudson.model.Hudson.(Hudson.java:79)
>> at hudson.WebAppMain$3.run(WebAppMain.java:225)
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.sshd.common.KeyPairProvider
>> at java.base/java.net
>> .URLClassLoader.findClass(URLClassLoader.java:471)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:588)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>> at
>> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:430)
>> at
>> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:383)
>> ... 19 more
>>
>> Any ideas ?
>>
>> Full logging can be found attached.
>>
>> Kind regards, Heymen
>>
>> --
> 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/ff09aad6-b461-4fab-8bea-bd680648d3b7%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/ff09aad6-b461-4fab-8bea-bd680648d3b7%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHuWrM9Sa-Da3kL8XYo8axMU%2BcGyBcbAhZB-RPQ4iN7cQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: safe-shutdown does not wait for jobs to finish

2019-06-24 Thread Mark Waite
It is intentional that pipeline jobs do not prevent a shutdown of the
Jenkins server.  They are allowed to continue running on the agent hosting
them even while the Jenkins server restarts.  They are "durable" across
Jenkins server restarts.

When the Jenkins server restarts and the agent is reconnected, the status
of the job is communicated to the Jenkins server.

Refer to https://jenkins.io/doc/book/pipeline/scaling-pipeline/
<https://jenkins.io/doc/book/pipeline/scaling-pipeline/#what-am-i-giving-up-with-this-durability-setting-trade-off>
for
more details on pipeline durability settings and the compromises that you
may choose to make between pipeline durability and pipeline performance.

On Mon, Jun 24, 2019 at 6:45 AM Remo Meier  wrote:

> Hi
>
> We make use of:
>
> command: ["java", "-jar", "/var/jenkins_home/war/WEB-INF/jenkins-cli.jar", 
> "-s", "http://127.0.0.1:8080/scheduler;, "safe-shutdown"]
>
>
> To shutdown a Jenkins server. According to the documentation
> https://support.cloudbees.com/hc/en-us/articles/216118748-How-to-Start-Stop-or-Restart-your-Instance-
> and
> https://stackoverflow.com/questions/10238604/how-to-shutdown-my-jenkins-safely/13527164
> this should be fine to wait for job completion before shutdown. But the
> command for terminates the server immediately and restarts the Job after.
> Our job is a regular flow/pipeline definition:
>
> 
> 
> 
> 
> false
> 
> 
> 
> 
> 
> 0 3 * * *
> 
> 
> 
> 
> 
>  plugin="workflow-cps@2.55">
> 
> node {
> stage('Run') {
> sh '''
> #!/usr/bin/env bash
>
>
> exec kubectl run ...
>
> ...
> '''
> }
> }
> 
> true
> 
> 
> false
> 
>
>
> It shows log entries like:
>
> Ready to run at Mon Jun 24 11:46:22 GMT 2019
> Resuming build at Mon Jun 24 11:50:56 GMT 2019 after Jenkins restart
> Waiting to resume part of demo-import #71: Finished waiting
>
>
> In this case it runs some shell scripts. The documentation does not
> mention the use of termination signals or anything that would maybe stop
> the job?
>
> Thank you, Regards Remo
>
> --
> 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/c3fece50-f8b2-41e1-a2f3-9f5a7ce1bb38%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/c3fece50-f8b2-41e1-a2f3-9f5a7ce1bb38%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Unable to add a windows slave into Jenkins 2.177

2019-06-17 Thread Mark Waite
The "Unsupported major/minor version" message means that you are attempting
to run Java code that requires a Java 8 virtual machine on a Java version
that is less than Java 8.  It could be a configuration error in your PATH.
It could be an installation error on the computer.  It could be that the
default Java installed on the computer is older than Java 8.

Refer to
https://stackoverflow.com/questions/22489398/unsupported-major-minor-version-52-0

On Mon, Jun 17, 2019 at 5:41 AM ANKUSH CHANDEL 
wrote:

> Hello All,
>
> Please help me out with adding a Windows slave into Jenkins.
> I am using Launch Method as "Launch agent by connecting it to the master".
>
> Which provides me three options to connect the slave machine.
>
> Connect agent to Jenkins one of these ways:
>
>-
>
>[image: launch agent]
>
> <https://phlox-dv.itn.intraorange:4443/computer/WIN_10_Ankush/slave-agent.jnlp>
>  Launch
>agent from browser
>-
>
>Run from agent command line:
>
>javaws http://Location:Port/computer/WIN_10_X/slave-agent.jnlp
>
>-
>
>Or if the agent is headless:
>
>java -jar agent.jar 
> <https://phlox-dv.itn.intraorange:4443/jnlpJars/agent.jar> -jnlpUrl 
> http://Location:Port/computer/WIN_10_X/slave-agent.jnlp -workDir 
> "C:\Jenkins\
>
>
> I have tired these steps but it saying unable to launch the application.
>
> C:\Jenkins>java -jar agent.jar -jnlpUrl 
> http://Location:Port/computer/WIN_10_X/slave-agent.jnlp
> -workDir "C:\Jenkins"
> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> hudson/remoting/Launcher : Unsupported major.minor version 52.0
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(Unknown Source)
> at java.security.SecureClassLoader.defineClass(Unknown Source)
> at java.net.URLClassLoader.defineClass(Unknown Source)
> at java.net.URLClassLoader.access$100(Unknown Source)
> at java.net.URLClassLoader$1.run(Unknown Source)
> at java.net.URLClassLoader$1.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
> at java.lang.ClassLoader.loadClass(Unknown Source)
> at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
>
> C:\Jenkins>javaws http://Location:Port
> /computer/WIN_10_X/slave-agent.jnlp
>
> C:\Jenkins>java -jar agent.jar -jnlpUrl 
> http://Location:Port/computer/WIN_10_X/slave-agent.jnlp
> -workDir "C:\Jenkins"
> Error: Registry key 'Software\JavaSoft\Java Runtime
> Environment'\CurrentVersion'
> has value '1.8', but '1.7' is required.
> Error: could not find java.dll
> Error: Could not find Java SE Runtime Environment.
>
>
> Please help me out with 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/35fd8d79-455b-4f35-8f27-ee5135b71893%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/35fd8d79-455b-4f35-8f27-ee5135b71893%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: TCP port for JNLP slave agents section not found in configure global security

2019-06-12 Thread Mark Waite
On Wed, Jun 12, 2019 at 11:22 PM Jim Barnebee  wrote:

>
>
> On Friday, May 24, 2019 at 6:10:40 AM UTC-6, Emilio Escobar Reyero wrote:
>>
>> Hi,
>>
>> I have started a 2.178 instance from scratch, installing suggested
>> plugins, and the agent port configuration is behind Markup Formatter as
>> expected.
>>
>>
>> [image: Screenshot 2019-05-24 at 13.36.39.png]
>>
>> On Fri, May 24, 2019 at 12:00 PM abhay srivastava 
>> wrote:
>>
>>> Hello all,
>>>
>>> Please help me on this issue.
>>> I am using jenkins 2.178 <https://jenkins.io/> version but section TCP
>>> port for JNLP slave agents section not found in configure global security
>>>
>>> [image: image.png]
>>>
>>> --
>>> Regards,
>>> Abhay Srivastava
>>> ---
>>> Mob-9160512000
>>>
>>> --
>>> 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/CAPKgz8V0vk1RL1ujVYyQzVrK%3Dtr0RpkMpge5-WzvWQQOJJUAQw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/CAPKgz8V0vk1RL1ujVYyQzVrK%3Dtr0RpkMpge5-WzvWQQOJJUAQw%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>>
>> Emilio Escobar
>> Software Engineer
>>
>> CloudBees, Inc.
>>
>> [image: CloudBees-Logo.png] <http://www.cloudbees.com>
>>
>>
>> E: eescoba...@cloudbees.com
>> Skype: escoem
>>
>
> So on your picture, it shows The TCP agent protocols- nothing about JNLP
> or JAVA - nor is this in the documentation anywhere. The documentation does
> not explain what port should be set or how to get JNLP working for a
> windows agent- they all just say use "JNLP" and "Java web start" which
> don't exist in 2.18.0 by default. There are lots of documentation pages
> that provide lots of different static port options for JNLP, none of which
> make the start agent with java web start option work in the agent
> configuration.. and this is after checking all the documentation for the
> java version 8, etc down in the details of the comments. It seems from the
> release notes that it was very visible and straightforward in 2.16 but was
> hidden? So how do you get to see JNLP protocols in that picture you posted?
>
>
Since you're trying to connect agents and the agents communicate over TCP,
use the section labeled "Agents" and the line that says "TCP port for
inbound agents".  Insert a valid port value for the TCP port for inbound
agents.  Apply that change.

Then add an agent and choose "Launch agent by connecting it to the master".

The phrasing has been improved significantly in the user interface by
removing the references to "JNLP".  The key difference between the agent
protocols is not the underlying transport, but rather which end initiates
the connection.  The agent launch method that was formerly called "JNLP" is
a launch method that initiates the agent connection from the agent to the
master.  The launch method called "ssh" initiates the connection from the
master to the agent.

[image:
screencapture-mark-pc2-markwaite-net-8080-computer-createItem-2019-06-12-23_33_38.png]


> *This message (including any attachments) is only for the use of the
> person(s) for whom it is intended. It may contain privileged, confidential
> or proprietary information. If you are not the intended recipient, you
> should not copy, distribute or use this information for any purpose, you
> should delete this message and inform the sender immediately. *
>
> --
> 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/d3653328-8c10-42fe-ac66-66a78dc309c0%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/d3653328-8c10-42fe-ac66-66a78dc309c0%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: gitSCM failed after updates

2019-06-12 Thread Mark Waite
On Wed, Jun 12, 2019 at 9:52 AM Giles  wrote:

> Hi Mark.
>
> Correct again:
>
> - Git plugin 3.10.0, now downgraded to 3.9.1
>

Git plugin 3.10.0 is a good choice.  Upgrade to it.


> - Git client plugin 3.0.0-rc, now downgraded to 2.7.6
>
>
Git client plugin 3.0.0-rc is a bad choice.  Don't upgrade (yet) to any git
client plugin newer than 2.7.x


> Deploys do now appear to all be working (this time I waited until we'd
> done a fair bit of testing before reporting ...).
>
> I upgraded the above plugins to 4.0.0-rc and 3.0.0-rc back in February
> because there were security advisories: I don't usually upgrade major
> versions immediately (especially not RC), instead waiting for them to have
> time to stabilize.
>
>
I think that you may have misread the security advisory.  No security
advisory has been issued that would require installation of a release
candidate.  Those two releases (git plugin 4.0.0-rc and git client plugin
3.0.0-rc) have been removed from the update center.  They have serious
compatibility problems which have been resolved in later pre-releases of
the plugins.


> These downgrades means that I'm now getting a fair bit of messaging from
> Jenkins about things I should upgrade or change:
>
> *Dependency errors:*
>
> Some plugins could not be loaded due to unsatisfied dependencies. Fix
> these issues and restart Jenkins to restore the functionality provided by
> these plugins.
> Git Parameter Plug-In version 0.9.10Jenkins Git plugin version
> 3.9.1 is older than required. To fix, install version 3.9.3 or later.
> GitHub Branch Source Plugin version 2.5.3Jenkins Git plugin version
> 3.9.1 is older than required. To fix, install version 3.9.3 or later.
>
> Warnings have been published for the following currently installed
> components.Git plugin 3.9.1
> <http://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin>CSRF
> vulnerability
> <https://jenkins.io/security/advisory/2019-01-28/#SECURITY-1095>
>
> Given that everything is working, I take it I should just ignore these for
> now?  Or possibly remove "Git Parameter Plug-In" and "GitHub Branch Source
> Plugin" as we apparently don't use them at all ...
>
> Once again, thank you very much for your help.
>
>
> On Tuesday, 11 June 2019 19:02:56 UTC-4, Mark Waite wrote:
>>
>>
>>
>> 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 s

Re: gitSCM failed after updates

2019-06-11 Thread 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 store

Re: gitSCM failed after updates

2019-06-11 Thread 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.work

Re: gitSCM failed after updates

2019-06-11 Thread Mark Waite
clear 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
> >>> Pipeline: Stage Tags Metadata 1.3.8 ->
> 1.3.9
> >>> Pipeline: Step API 2.19 ->
> 2.20
> >>> Slack Notification 2.23 -> 2.24
>
> I've since rolled back all of the "Pipeline: ..." changes.  The problem
> didn't change.
>
> About 40 Cygwin updates (I didn't enumerate those.)
>
> --
> 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/2d7c0927-22ba-4443-8121-0867169df831%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/2d7c0927-22ba-4443-8121-0867169df831%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEygQMpku8DGpOa%3DhFp7mS5E5TUaVNxjJwoG4RC0BM%3DfQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Failed ANT build: Unable to locate tools.jar

2019-06-07 Thread Mark Waite
Most interesting.

Ant expects to have a full JDK available.  It depends on the tools.jar file
which is provided by the JDK but is not available with the JRE.  The
directory name "jre1.8.0_201" indicates that it is not a JDK, but a JRE.
You indicated that even that directory does not exist on the agent running
the build.  It might also indicate that the job is running on a Windows
agent that has the Oracle script in its path which attempts to dynamically
determine the path to the Java program.

The path that is being used to run ant indicates that you have a Jenkins
build tool defined for Ant 1.9.6.  That may indicate you also have a JDK
tool defined for JRE 1.8.0_201.  The Jenkins tool definitions are available
from the "Configure System" page and might help detect the source of the
jre1.8.0_201 setting.

Best of luck!
Mark Waite

On Fri, Jun 7, 2019 at 12:44 PM ABostonGal ABostonGal 
wrote:

> Thank you Mark. Yes, I checked for that the Environment Variables but
> unfortunately: nothing! I've tried adding a JAVA_HOME variable pointing to
> the place where the tools.jar is and the build failed.
> I'd really like to understand how the build files "think" they should be
> looking for this before I do anymore "experimenting"...
>
>
> On Friday, June 7, 2019 at 10:48:58 AM UTC-4, ABostonGal ABostonGal wrote:
>>
>> I have an ANT build that has been working just fine for quite a while and
>> suddenly it has stopped working and I am trying to figure out why. Here is
>> what the Jenkins console displays and my notes about it. I've obscure the
>> actual site name, directory values, and Jenkins job name, etc. "uvwx" is
>> the Jenkins job that is failing to build
>>
>> In Jenkins console:
>>
>> No changes for svn://ab/cd/ef/gh/ijk since the previous build
>>
>> Copied 3 artifacts from "lmnop" build number 137
>>
>> Copied 2 artifacts from "qrst" build number 2700
>>
>> [uvwx] $ cmd.exe /C
>> "C:\Users\jenkins\jenkins_home\tools\hudson.tasks.Ant_AntInstallation\Ant_1.9.6\bin\ant.bat
>> get-revision compile-tests compile-javadoc package-jar package-javadoc &&
>> exit %%ERRORLEVEL%%"
>> Unable to locate tools.jar. Expected to find it in C:\Program
>> Files\Java\jre1.8.0_201\lib\tools.jar
>>
>>
>> My notes about this:
>>
>> What I want to know is: WHY does the build "expect" to find it in
>> "c:\Program Files\Java\jre1.8.0_201"? There IS no such path on the machine
>> on which the job is building...
>>
>> How can I find out WHERE that value is coming from? I've been looking at
>> the ant, build files and source code and don't see where that value would
>> be set.
>>
>> Thank you.
>>
>>
>> --
> 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/bd6b7015-91fa-4e87-9543-2b6b4f3d4b4d%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/bd6b7015-91fa-4e87-9543-2b6b4f3d4b4d%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFPCH36rHw8_ip94KFaxf9u-GO-4TTnXEL39R_M41mx6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Failed ANT build: Unable to locate tools.jar

2019-06-07 Thread Mark Waite
I suspect that something (Jenkins tool definition, local setting on the
computer, etc.) is defining a JAVA_HOME environment variable as  c:\Program
Files\Java\jre1.8.0_201.

Add a bat step to the job prior to calling `ant` and run the command
`set`.  That will report the environment variable to confirm the guess that
something is placing value that into the environment.

On Fri, Jun 7, 2019 at 8:49 AM ABostonGal ABostonGal 
wrote:

> I have an ANT build that has been working just fine for quite a while and
> suddenly it has stopped working and I am trying to figure out why. Here is
> what the Jenkins console displays and my notes about it. I've obscure the
> actual site name, directory values, and Jenkins job name, etc. "uvwx" is
> the Jenkins job that is failing to build
>
> In Jenkins console:
>
> No changes for svn://ab/cd/ef/gh/ijk since the previous build
>
> Copied 3 artifacts from "lmnop" build number 137
>
> Copied 2 artifacts from "qrst" build number 2700
>
> [uvwx] $ cmd.exe /C
> "C:\Users\jenkins\jenkins_home\tools\hudson.tasks.Ant_AntInstallation\Ant_1.9.6\bin\ant.bat
> get-revision compile-tests compile-javadoc package-jar package-javadoc &&
> exit %%ERRORLEVEL%%"
> Unable to locate tools.jar. Expected to find it in C:\Program
> Files\Java\jre1.8.0_201\lib\tools.jar
>
>
> My notes about this:
>
> What I want to know is: WHY does the build "expect" to find it in
> "c:\Program Files\Java\jre1.8.0_201"? There IS no such path on the machine
> on which the job is building...
>
> How can I find out WHERE that value is coming from? I've been looking at
> the ant, build files and source code and don't see where that value would
> be set.
>
> Thank you.
>
>
> --
> 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/794e1399-0d52-42d9-b805-0e197667d3c6%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/794e1399-0d52-42d9-b805-0e197667d3c6%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtEjQTsh2fgCNtBP5PNcM_%3DbCBBpq0XGWExob6%3D7sv9yBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Pipeline with multiple Git repositories - how to checkout?

2019-05-28 Thread Mark Waite
Git takes full control of the directory for each checkout.  Thus, the last
checkout "wins" by containing the content of only that checkout.

Perform a checkout command for each repository in a separate directory.
Create the directory for each checkout with the dir() step or the ws()
step, and place the checkout inside the block from that step.  Something
like this:

dir('dir-1-for-repo-1') {
  checkout([$class: 'GitSCM', branches: [[name: gitBranch]], extensions: [[
$class: 'CloneOption', timeout: 120]],
  userRemoteConfigs: [[credentialsId: "${credentialsId}", url:
mainProjectGITURL ]  ]])
}
dir('dir-2-for-repo-2') {
  checkout([$class: 'GitSCM', branches: [[name: gitBranch]], extensions: [[
$class: 'CloneOption', timeout: 120]],
  userRemoteConfigs: [[credentialsId: "${credentialsId}", url:
list[0] ]  ]])
}

On Tue, May 28, 2019 at 4:14 AM Jacques van der Merwe 
wrote:

> I know this is fairly old thread but I have an issue
> when using the multi repo checkout it seems to remove the previous repo
> checkout before doing the new one.
> I have tried checking all the repos required for my build using the
> Jenkins Declarative "checkout" command
> checkout([$class: 'GitSCM', branches: [[name: "${gitBranch}"]],
> doGenerateSubmoduleConfigurations: false, extensions: [[$class:
> 'CloneOption', timeout: 120]], submoduleCfg: [], userRemoteConfigs: [
>  [credentialsId: "${credentialsId}", url: "${mainProjectGITURL}"],
>  [credentialsId: "${credentialsId}", url: "${list[0]}"],
>  [credentialsId: "${credentialsId}", url: "${list[1]}"],
>  [credentialsId: "${credentialsId}", url: "${list[2]}"],
>  [credentialsId: "${credentialsId}", url: "${list[3]}"]
>  ]])
> With this config I can see on my build server each project are being
> checked out but only the last project is availbale after this checkout.
>
>
Multiple userRemoteConfigs in a single checkout command will perform a
single checkout of one of the remote configs.  It won't iterate over the
list of remote configs and definitely won't create the separate
subdirectories that would be needed to retain a checkout of multiple
repositories.

Multiple userRemoteConfigs in a single checkout are allowed as a historical
use that was allowed for those rare cases where multiple locations
contained the same repository and any one of the repositories could be
used.  Multiple userRemoteConfigs won't help in this case and they don't
help in almost all cases.


> I also tried doing in a loop using "git" only
>def list = "${includedProjectsGITURLS}".split("\n")
> echo "Number of repos : " + list.size()
> echo "Checking out main project (${gitBranch}) :  " +
> mainProjectGITURL + "\n";
> git credentialsId: 'blablabla', url: "${mainProjectGITURL}"
> for (String gitSubURL:list)
>  {
> echo "Checking out sub project (${gitBranch}) :  " + gitSubURL + "\n";
> git credentialsId: 'blablabla', url: "${gitSubURL}"
>  }
> The result is the same, making me think "checkout" is just wrapper for GIT
>
>
The git step is a simplified form of the checkout step.  If your case does
not need the full capability of the checkout step, you are welcome to use
the git step.  I find that I almost always want the checkout step because
it allows me to control things more precisely.


> I also tried checking each repo into its own sub folder but the result is
> the same
>
>
We'll need more explanation of what was tried in this case, since that is
the technique that works for many users.

Thanks,
Mark Waite


> any ideas how I can checkout multiple repos in Jenkins declarative script
> for single build
>
>
>
> On Wednesday, December 21, 2016 at 7:25:43 PM UTC+2, Torsten Reinhard
> wrote:
>>
>> Hi,
>>
>> I have a pipeline doing a build and afterwards a deployment to the TEST
>> environment.
>>
>> For the build I need to
>> // checkout sources for building
>> checkout scm
>>
>> and later on I need to
>> //checkout configuration for TEST environment
>> checkout scm (config)
>>
>> I wasn´t able to configure a working directory for each repo - and the
>> "Multiple SCMs plugin" is deprecated with a hint to the Pipeline plugin.
>> How can I setup the Pipeline job so it´s using "Pipeline script from SCM"
>> AND additionally some files/configs from a different repo?
>>
>> I know about the workaround with subtrees and also this issue:
>> https://issues.jenkins-ci.org/browse/JENKINS-13228,
>> but I´m wondering why 

Re: multibranch pipeline & checkout over shh & permission denied

2019-05-23 Thread Mark Waite
You might double check that the private key credential you're using with
that checkout does not use a passphrase, or if it uses a passphrase, does
not include any shell special characters in the passphrase.  There is a
known bug in the git client plugin handling of ssh passphrases with shell
special characters.

You might also double check that the private key you're using is recognized
by both agent and server.  I've generated ed25519 private keys in the past
only to discover that they were not recognized on one or more of the old
systems that I needed to support.  I will be surprised if that is the case
here, since that usually has a different error message, but it is worth
checking.

On Thu, May 23, 2019 at 6:57 AM Ewelina Wilkosz  wrote:

> I see,
>
> but in my case I don't event get to submodules. multibranch pipeline fails
> on checking out main repo via ssh - I use checkout over SSH option - when a
> regular pipelineJob has no trouble with ssh
>
> On Thursday, May 23, 2019 at 2:44:23 PM UTC+2, Mark Waite wrote:
>>
>> Submodule authentication in the git plugin and git client plugin requires
>> that the same protocol must be used for the parent repository and the
>> submodules.  Different credential methods are required to provide command
>> line git with http/https credentials than with ssh credentials.  A mix of
>> the two in a single repository definition would require much more
>> sophisticated operations from the git plugin than it is currently able to
>> perform.
>>
>> If the submodules and the parent repo are all using the same protocol
>> (ssh or http), then you may need to enable the checkbox which causes the
>> git plugin to use credentials with submodule operations.  I believe it is
>> disabled by default.
>>
>>
>> On Thu, May 23, 2019 at 5:37 AM Ewelina Wilkosz 
>> wrote:
>>
>>> I have a pipelineJob where I use ssh to clone repository and configured
>>> credentials, let's call it X, are working great
>>>
>>> I also have a multibranch pipeline, where I configured "Checkout over
>>> SSH" and select same X credentials, but I can't clone
>>> I get
>>>
>>> ERROR: Error fetching remote repo 'origin'
>>> [...]
>>> stderr: Permission denied (public key)
>>> fatal: Could not read from remote repository
>>>
>>> The same user could clone via https, but there are some submodules
>>> configured via ssh, so I need ssh working...
>>>
>>> Any ideas?
>>>
>>> --
>>> 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/89f8e2a2-6082-4642-90ac-31f8da684c06%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/89f8e2a2-6082-4642-90ac-31f8da684c06%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
> --
> 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/a7a0bb7c-4b82-4f7f-b57e-29b9ff210f3e%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/a7a0bb7c-4b82-4f7f-b57e-29b9ff210f3e%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHaSC6QF%2Bfi%3DUp%2BLVKm4ViK_%3DiaaNwMcdXFhZq9wDvcYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: multibranch pipeline & checkout over shh & permission denied

2019-05-23 Thread Mark Waite
Submodule authentication in the git plugin and git client plugin requires
that the same protocol must be used for the parent repository and the
submodules.  Different credential methods are required to provide command
line git with http/https credentials than with ssh credentials.  A mix of
the two in a single repository definition would require much more
sophisticated operations from the git plugin than it is currently able to
perform.

If the submodules and the parent repo are all using the same protocol (ssh
or http), then you may need to enable the checkbox which causes the git
plugin to use credentials with submodule operations.  I believe it is
disabled by default.


On Thu, May 23, 2019 at 5:37 AM Ewelina Wilkosz  wrote:

> I have a pipelineJob where I use ssh to clone repository and configured
> credentials, let's call it X, are working great
>
> I also have a multibranch pipeline, where I configured "Checkout over SSH"
> and select same X credentials, but I can't clone
> I get
>
> ERROR: Error fetching remote repo 'origin'
> [...]
> stderr: Permission denied (public key)
> fatal: Could not read from remote repository
>
> The same user could clone via https, but there are some submodules
> configured via ssh, so I need ssh working...
>
> Any ideas?
>
> --
> 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/89f8e2a2-6082-4642-90ac-31f8da684c06%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/89f8e2a2-6082-4642-90ac-31f8da684c06%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Branch API Failed Update

2019-05-21 Thread Mark Waite
Not with branch api plugin, though I have seen those messages in the past.
They typically resolved themselves within a few hours after initial release
of the plugin.

On Tue, May 21, 2019 at 9:03 AM Steven Wall <
steve.w...@primetimesoftware.com> wrote:

> Hello,
>
> Is anyone else seeing this error when trying to update “Branch API”?
>
> Best,
>
> Steve
>
>
>
> java.io.FileNotFoundException:
> http://archives.jenkins-ci.org/plugins/branch-api/2.5.0/branch-api.hpi
>
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1890)
>
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
>
> at
> sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:3051)
>
> at
> java.net.URLConnection.getHeaderFieldLong(URLConnection.java:629)
>
> at
> java.net.URLConnection.getContentLengthLong(URLConnection.java:501)
>
> at java.net.URLConnection.getContentLength(URLConnection.java:485)
>
> at
> hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1158)
>
> Caused: java.io.FileNotFoundException:
> http://archives.jenkins-ci.org/plugins/branch-api/2.5.0/branch-api.hpi
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>
> at
> sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1944)
>
> at
> sun.net.www.protocol.http.HttpURLConnection$10.run(HttpURLConnection.java:1939)
>
> at java.security.AccessController.doPrivileged(Native Method)
>
> at
> sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1938)
>
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1508)
>
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1492)
>
> at
> hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1174)
>
> Caused: java.io.IOException: Failed to load
> http://updates.jenkins-ci.org/download/plugins/branch-api/2.5.0/branch-api.hpi
>  to /var/jenkins_home/plugins/branch-api.jpi.tmp
>
> at
> hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1181)
>
> Caused: java.io.IOException: Failed to download from
> http://updates.jenkins-ci.org/download/plugins/branch-api/2.5.0/branch-api.hpi
>  (redirected to:
> http://archives.jenkins-ci.org/plugins/branch-api/2.5.0/branch-api.hpi)
>
> at
> hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:1215)
>
> at
> hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1752)
>
> at
> hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:2015)
>
> at
> hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1726)
>
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>
> at
> hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:112)
>
> at java.lang.Thread.run(Thread.java:748)
>
>
>
> --
> 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/1f76738a-02d6-4842-b542-0f21e84e38ba%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/1f76738a-02d6-4842-b542-0f21e84e38ba%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFWdBmzEB1pfg%3DoyDmCDas0nHwjLA4-7WKEXzVYQY_4Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Jenkins replaces all occurrences of my user name in the log with asterisks. How can I change that?

2019-05-21 Thread Mark Waite
On Tue, May 21, 2019 at 7:26 AM Tim Jaacks  wrote:

> Thanks very much for the link. That is indeed exactly my issue.
>
> Is there an alternative to using the credentials binding plugin? I need
> the credentials to be inserted into an URL within the test script. How can
> I do this without the credentials binding plugin?
>

I don't know of a way to do that.

If it would work in your environment, you might consider switching to use a
different account to run the Jenkins agent than the account that provides
the credentials.  That's an ugly work around but may avoid many of the
problems.


>
> Am Dienstag, 21. Mai 2019 14:48:57 UTC+2 schrieb Mark Waite:
>>
>> Based on https://issues.jenkins-ci.org/browse/JENKINS-44860 , it appears
>> to be the credentials binding plugin.  Sorry for my misdirection.
>>
> --
> 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/e9881260-2c05-41eb-bf22-b4e17d58e70f%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/e9881260-2c05-41eb-bf22-b4e17d58e70f%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFnKWmq-xNMMSZQgTeA36kWjNnoZZ9%2BRPMF1mnGbP0P2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Jenkins replaces all occurrences of my user name in the log with asterisks. How can I change that?

2019-05-21 Thread Mark Waite
Based on https://issues.jenkins-ci.org/browse/JENKINS-44860 , it appears to
be the credentials binding plugin.  Sorry for my misdirection.

On Tue, May 21, 2019 at 5:36 AM Tim Jaacks  wrote:

> Thanks for your reply, Mark. I am using the credentials plugin to provide
> the stated credentials and I thought, that it is actually this plugin which
> performs the masking. If not, which plugin does this? I did not find any
> installed plugins in my instance which seem to do this.
>
> Am Dienstag, 21. Mai 2019 13:27:50 UTC+2 schrieb Mark Waite:
>>
>> The only solution that I am aware of is to not use the plugin that masks
>> usernames and passwords.  If you use the Jenkins credentials plugin and
>> provide all your credentials through the credentials plugin, you generally
>> should not need to mask references to usernames and generally won't show
>> passwords in the log files (or elsewhere).
>>
> --
> 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/5c846913-65ef-41b2-a470-1f305ac27f75%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/5c846913-65ef-41b2-a470-1f305ac27f75%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Jenkins replaces all occurrences of my user name in the log with asterisks. How can I change that?

2019-05-21 Thread Mark Waite
On Tue, May 21, 2019 at 5:24 AM Tim Jaacks  wrote:

> While this makes sense for actual occurrences (i.e. where the asterisk'ed
> text REALLY is my user name), it is quite counterproductive in situations
> where the user name accidentally matches some other strings in the log.
>
> For example, my user name I use in the credentials is "jenkins" (oh yeah,
> creative). Everywhere this name is used (e.g. in URLs like
> jenk...@myserver.de/somepath) it is correctly masked (showing @
> myserver.de/somepath).
> However, I have a script called "jenkins_patches.sh" which is called
> during the build. This gets logged as "_patches.sh", which is quite
> ridicoulous, because the credentials are not actually used here.
> Furthermore, my Jenkins instance is hosted under some URL like "
> http://mycompanyintranet/jenkins;, resulting in "
> http://mycompanyintranet/;, which makes all URLs in my build log
> unusable. This is quite annoying.
>
> Is there a solution to change this?
>

The only solution that I am aware of is to not use the plugin that masks
usernames and passwords.  If you use the Jenkins credentials plugin and
provide all your credentials through the credentials plugin, you generally
should not need to mask references to usernames and generally won't show
passwords in the log files (or elsewhere).

> --
> 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/dc508f41-cd5b-449b-a0d4-11d9aa5c2668%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/dc508f41-cd5b-449b-a0d4-11d9aa5c2668%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFDvenvJ16ZE15XBkLRnxzL%2BkYmekdsFzMpgy4s%2BjErwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Windows Master and Linux Slave give an error: Cannot run program "C:\Windows\system32\cmd.exe"

2019-05-20 Thread Mark Waite
If you'd like labels assigned automatically to your agents, install
the "Platform
Labeler Plugin <https://plugins.jenkins.io/platformlabeler>".

If the labels assigned by the platform labeler plugin are not generic
enough, install the "Implied Labels Plugin
<https://plugins.jenkins.io/implied-labels>" and you can define that all
agents with the label "CentOS" should also be assigned the label "linux"
(as an example).  It simplifies the management of labels.

If you'd like an example implied labels definition for various Linux
operating systems, I have one in my docker repository
<https://github.com/MarkEWaite/docker-lfs/blob/4a9773f22066c9db6fa7841fcbcfb14dacd26918/ref/org.jenkinsci.plugins.impliedlabels.Config.xml#L8>
.

On Mon, May 20, 2019 at 6:18 AM Bob TheBuilder 
wrote:

> Hi Gregory,
>
> what kind of Jenkinsfile do you use? Scripted or declarative?
> In scripted, you would enclose your sh in a
>
>> node('linux_label') {
>> sh "your shell script"
>> }
>
>
> , on declarative, use
> stage ("Run on Linux only") {
>agent { label "linux_label" }
>steps {
>script {
>  sh "you shell script"
>}
> }
>
>  with agent('linux_label'). Linux label would be a label you attached to
> the Linux slave/node
>
> --
> 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/e81a95b4-d8a4-4fa0-931a-f314e9616796%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/e81a95b4-d8a4-4fa0-931a-f314e9616796%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFJYtp5ZGSCnKmGAMbJt%2BOtg%3DXAT9jBN%3D-KRY8aQDoWig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: node parameter makes pipeline fail even if it's unused

2019-05-17 Thread Mark Waite
I failed to mention that performing git operations over NFS is much slower
than performance those operations with a local file system.  I'd generally
recommend that file systems on static agents should be locally attached
file systems rather than network file systems if possible.

On Fri, May 17, 2019 at 4:59 AM Mark Waite 
wrote:

>
>
> On Thu, May 16, 2019 at 7:13 AM gbon  wrote:
>
>> Hi All,
>> Asking for advice on this weird behavior:
>>
>> I have a (declarative) pipeline that works perfectly fine and selects the
>> agent like so
>>
>> pipeline {
>>   agent {
>> node {
>>   label "SOME_LABEL"
>> }
>>   }
>>   ...
>> }
>>
>> If I edit the pipeline configuration to add a parameter of type Node (
>> which I'm still not using in the pipeline! )  the pipeline fails
>> immediately with the following error
>>
>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>> --progress g...@my-super-secret-gitlab-repository.git 
>> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
>> stdout:
>> stderr: Could not create directory '/export/homes/my_user/.ssh'.
>> Host key verification failed.
>> fatal: Could not read from remote repository.
>>
>>
>>
>> That I think has nothing to do with git since it works perfectly fine and
>> the label is still hardcoded.
>> Seems like the job isn't correctly dispatched or something but I can't
>> figure out what's happening.
>>
>>
> The declarative Pipeline includes an implicit checkout of the repository
> on each agent that will be performing a step.  When you add the `node`
> step, declarative Pipeline attempts to perform a checkout on that node.  If
> you don't need that default checkout, the `skipDefaultCheckout` option is
> available.
>
> If you need that default checkout, then you probably need to fix the file
> system permissions of the /export/homes/my_user/.ssh directory so that the
> user executing the Pipeline job can read the .$HOME/.ssh directory.
> Command line git uses `ssh` to authenticate and clone repositories using
> the secure shell protocol.
>
> If the `/export/homes/my_user` directory is accessed over NFS, then you
> may also need to assure that the agent process is not running as root. Root
> access over NFS is usually not allowed.
>
> You could check for those types of conditions in your environment with a
> Jenkinsfile something like this:
>
> pipeline {
>   options {
> skipDefaultCheckout()
>   }
>   agent {
> node {
>   label "!windows"
> }
>   }
>   stages {
> stage('Report username') {
>   steps {
> sh 'id'
>   }
> }
>   }
> }
>
>
>
>> 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/0f7c8c1c-c1a8-4495-8be5-d00b5c5997ff%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/0f7c8c1c-c1a8-4495-8be5-d00b5c5997ff%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Thanks!
> Mark Waite
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGDDQkNQ72h5VyzhRO2_2GYfimE%3Da8UdVDo4aLW%3Di8yjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: node parameter makes pipeline fail even if it's unused

2019-05-17 Thread Mark Waite
On Thu, May 16, 2019 at 7:13 AM gbon  wrote:

> Hi All,
> Asking for advice on this weird behavior:
>
> I have a (declarative) pipeline that works perfectly fine and selects the
> agent like so
>
> pipeline {
>   agent {
> node {
>   label "SOME_LABEL"
> }
>   }
>   ...
> }
>
> If I edit the pipeline configuration to add a parameter of type Node (
> which I'm still not using in the pipeline! )  the pipeline fails
> immediately with the following error
>
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
> --progress g...@my-super-secret-gitlab-repository.git 
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> stdout:
> stderr: Could not create directory '/export/homes/my_user/.ssh'.
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
>
> That I think has nothing to do with git since it works perfectly fine and
> the label is still hardcoded.
> Seems like the job isn't correctly dispatched or something but I can't
> figure out what's happening.
>
>
The declarative Pipeline includes an implicit checkout of the repository on
each agent that will be performing a step.  When you add the `node` step,
declarative Pipeline attempts to perform a checkout on that node.  If you
don't need that default checkout, the `skipDefaultCheckout` option is
available.

If you need that default checkout, then you probably need to fix the file
system permissions of the /export/homes/my_user/.ssh directory so that the
user executing the Pipeline job can read the .$HOME/.ssh directory.
Command line git uses `ssh` to authenticate and clone repositories using
the secure shell protocol.

If the `/export/homes/my_user` directory is accessed over NFS, then you may
also need to assure that the agent process is not running as root. Root
access over NFS is usually not allowed.

You could check for those types of conditions in your environment with a
Jenkinsfile something like this:

pipeline {
  options {
skipDefaultCheckout()
  }
  agent {
node {
  label "!windows"
}
  }
  stages {
stage('Report username') {
  steps {
sh 'id'
  }
}
  }
}



> 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/0f7c8c1c-c1a8-4495-8be5-d00b5c5997ff%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/0f7c8c1c-c1a8-4495-8be5-d00b5c5997ff%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtFqxh-mHCxnLK_Rs-3WgXVkZWR8urCnPQ3k52pVDyzLRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Securing build scripts when building pull requests

2019-05-17 Thread Mark Waite
The pipeline library on ci.jenkins.io is a good example of a library
written to safely handle pull requests which might be malicious.  Refer to
isTrusted
<https://github.com/jenkins-infra/pipeline-library/blob/master/README.adoc#infraistrusted>
and how it is used to safeguard operations.

I believe ci.jenkins.io jobs are also configured to not allow Jenkinsfile
to be used from the target branch even for pull requests.  That avoids the
risk of a pull request submitted which executes a malicious Jenkinsfile.

On Fri, May 17, 2019 at 1:03 AM Simon Richter 
wrote:

> Hi,
>
> On Thu, May 16, 2019 at 12:11:54PM -0700, Christopher Weaver wrote:
>
> > For a project I work on, we have set up Jenkins, using the GitHub Branch
> > Source Plugin, to do automatic builds for pushes to our repository,
> > including test builds for pull requests. This is all working, but I am
> > concerned about the security implications for the pull requests.
>
> Yes, that is a common problem. Most people either only test pull requests
> from trusted people, or configure Jenkins to test inside a container with
> no network access and strict resource limits that is discarded after the
> build.
>
>Simon
>
> --
> 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/20190517080348.GA17598%40psi5.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHAT5tbH9%3Df%2BZEYJ%3DsO-6RisYM0spTQH9PKgu31WMCpmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Git scm fails to check the expected branch when another branch has the target branch name as a suffix

2019-05-16 Thread Mark Waite
I don't know if it will help, but you could try replacing the "syntactic
sugar" command `git` with the `checkout` command.  Pipeline Syntax link on
the Pipeline pages will help get the correct syntax for the details of the
checkout command.

On Thu, May 16, 2019 at 7:25 AM James Robson 
wrote:

>
>
> On Wednesday, 15 May 2019 21:28:52 UTC+1, Mark Waite wrote:
>>
>>
>> You can often avoid the guessing by naming the branch precisely, as in
>> 'origin/develop'.
>>
>
> I attempted to use 'origin/develop' as the branch name, but that causes
> the job to fail the checkout with "ERROR: Couldn't find any revision to
> build. Verify the repository and branch configuration for this job". Here's
> the pipeline I'm testing this with:
>
> node('linux') {
> stage('checkout') {
> git branch: 'origin/develop', ...
> }
> }
>
> The last line of output before the failure is a 'git fetch' call which is
> identical to a run using a branch name of 'develop' which will then
> checkout successfully.
>
> --
> 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/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtG%3D8AgjqrXmZpAHBsKPr6Ep7A-ZV%2BEfTGroc46VZB%3DvVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Credentials "secret text" -> bash -> expect ?

2019-05-15 Thread Mark Waite
I'm accustomed to seeing variable references in groovy strings as
"${variablename}", while it seemed in your example you were referencing it
as "$variablename".  Is that an intentional difference, or accidental?

On Wed, May 15, 2019 at 9:14 PM b o b i  wrote:

> It is a single line secret, but it wont work :|
>
> On Wednesday, May 15, 2019 at 7:31:27 PM UTC+2, Ivan Fernandez Calvo wrote:
>>
>> If your secret is multiline, the secret text does not work as expected,
>> you could store the one line base64 value of your secret and decode it
>> before send it, it could work
>
> --
> 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/85dc81a4-6206-4286-9578-42f1bec2fcfb%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/85dc81a4-6206-4286-9578-42f1bec2fcfb%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHicbtPTDKPBWyMBcgjcXj%2BNNRqNJv3CpvrGj5AwCm1%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Jenkins init groovy script to upload custom plugin

2019-05-15 Thread Mark Waite
On Wed, May 15, 2019 at 8:08 PM Nageswara Rao Palukuri Venkata <
pvnra...@gmail.com> wrote:

> Hi,
>
> I am creating a Jenkins instance using init scripts. I am able to
> configure all the required custom tools, extension and able to configure
> the jobs related to my project. I want to install the Veracode plugin also
> using the init script.
>
> Looking for any init script (groovy) to install Veracode plugin in Jenkins.
>

That feels like a complicated way to manage plugins, but it appears that
others have done something similar in the past.  Refer to
https://stackoverflow.com/questions/31457623/jenkins-plugin-installation as
one possible source of help, or the
https://github.com/blacklabelops-legacy/jenkins/blob/master/imagescripts/initplugins.sh
<https://github.com/blacklabelops-legacy/jenkins/blob/master/imagescripts/initplugins.sh#L22>
which
that page references.

I've preferred to manage my Jenkins instances as Docker images so that I
can specify the plugins to be installed in either a plugins.txt file or in
the ref/plugins directory.  That seems simpler to me than writing groovy
script functions to perform plugin installations during startup.



> Thanks
> Nageswara Rao
>
> On Wed, May 15, 2019 at 9:46 PM Mark Waite 
> wrote:
>
>>
>> On Wed, May 15, 2019 at 7:37 PM Nageswara Rao Palukuri Venkata <
>> pvnra...@gmail.com> wrote:
>>
>>> How can we upload a custom plugin file using groovy init script?
>>> Is there any init groovy script is available to upload custom plugin
>>> veracode (
>>> https://tools.veracode.com/integrations/Jenkins/bin/veracode-jenkins-plugin.hpi)
>>> ?
>>>
>>
>> I think you may be mixing terms in a way that needs more clarification
>> before someone can answer your question.
>>
>> Since Veracode is a static analysis tool, I assume that you want to
>> submit your source code or a portion of your source code to Veracode for
>> analysis.  You should probably refer to the Veracode help site which
>> describes "Using the Veracode Jenkins Plugin
>> <https://help.veracode.com/reader/PgbNZUD7j8aY7iG~hQZWxQ/_4G8gT1rhWMgVVtCI1C57A>"..
>> That page seems to describe how you can use the Veracode plugin to submit
>> source code for analysis by Veracode.
>>
>> I don't think you actually want an init groovy script, since they
>> generally only run when the system starts, not when a Jenkins job runs and
>> not when code is changed in a source code repository.
>>
>> I don't think you are creating a Jenkins plugin, so I assume you don't
>> want to upload a custom plugin to Veracode.  I assume you are creating your
>> own product and you want to upload its source code to Veracode.
>>
>> Let me know if I've made a wrong assumption somewhere in that list of
>> assumptions.
>>
>>
>>> --
>>> 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/df6be5c5-fc5d-4937-8690-c8012db8daaf%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/df6be5c5-fc5d-4937-8690-c8012db8daaf%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Thanks!
>> Mark Waite
>>
>> --
>> 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/CAO49JtEyCZTKgoQ6FJoBXtZVZVohb4ve_wCuARJ2s8VFvBFcoA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEyCZTKgoQ6FJoBXtZVZVohb4ve_wCuARJ2s8VFvBFcoA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> 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/CAPG8g7bgpx686UKjHaQsSv_ZpXkEr4owWCEOUNe0Jg6jHqUSCA%40mail.

Re: Jenkins init groovy script to upload custom plugin

2019-05-15 Thread Mark Waite
On Wed, May 15, 2019 at 7:37 PM Nageswara Rao Palukuri Venkata <
pvnra...@gmail.com> wrote:

> How can we upload a custom plugin file using groovy init script?
> Is there any init groovy script is available to upload custom plugin
> veracode (
> https://tools.veracode.com/integrations/Jenkins/bin/veracode-jenkins-plugin.hpi)
> ?
>

I think you may be mixing terms in a way that needs more clarification
before someone can answer your question.

Since Veracode is a static analysis tool, I assume that you want to submit
your source code or a portion of your source code to Veracode for
analysis.  You should probably refer to the Veracode help site which
describes "Using the Veracode Jenkins Plugin
<https://help.veracode.com/reader/PgbNZUD7j8aY7iG~hQZWxQ/_4G8gT1rhWMgVVtCI1C57A>"..
That page seems to describe how you can use the Veracode plugin to submit
source code for analysis by Veracode.

I don't think you actually want an init groovy script, since they generally
only run when the system starts, not when a Jenkins job runs and not when
code is changed in a source code repository.

I don't think you are creating a Jenkins plugin, so I assume you don't want
to upload a custom plugin to Veracode.  I assume you are creating your own
product and you want to upload its source code to Veracode.

Let me know if I've made a wrong assumption somewhere in that list of
assumptions.


> --
> 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/df6be5c5-fc5d-4937-8690-c8012db8daaf%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/df6be5c5-fc5d-4937-8690-c8012db8daaf%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Git scm fails to check the expected branch when another branch has the target branch name as a suffix

2019-05-15 Thread Mark Waite
The git plugin includes support for multiple remotes (origin, upstream,
downstream, etc.) and for multiple branches.  It includes guessing code for
those cases where a branch name is ambiguous (like 'develop' in a
repository which includes branches named 'develop', 'kassandra/develop',
and 'mwaite/develop'). in the context of multiple remotes or multiple
branch names.

You can often avoid the guessing by naming the branch precisely, as in
'origin/develop'.

Mark Waite

On Wed, May 15, 2019 at 1:18 PM James Robson 
wrote:

> I have a repo with a branch called ‘develop’ and another branch called
> ‘kassandra/develop’. I have created a pipeline job that is building on
> ‘develop’, set to trigger with the ‘GitHub hook trigger for GITScm
> polling’.
>
>
> I expect this job to run only when ‘develop’ is changed, however it is
> running on every commit to the repo. This seems to be because the scm
> polling logic is comparing the last built git hash to the git hash on
> ‘kassandra/develop’ (see excerpt of the polling log below).
>
>
> Is this behaviour expected? Is there a way to prevent these unwanted runs?
>
>
> Setup:
>
> Git plugin: 3.9.3
>
> git client plugin: 2.7.6
>
>
> Git poll log:
>
> [poll] Last Built Revision: Revision 576aad8bdbfbf422d6a98899fafe78cc095ebb81
>  (refs/remotes/origin/develop)
> 
> [poll] Latest remote head revision on refs/heads/kassandra/develop is: 
> a9b4791c65f1ed2f1dc5669501fbeee58323e11e
>
> --
> 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/b3d3df79-0ab9-4fd8-aeb7-1e70bc2e87ca%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/b3d3df79-0ab9-4fd8-aeb7-1e70bc2e87ca%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtHFeWBYBcgjO9%2BX9HGp_YiaLEEr661-ysf2aFrx1cdgnA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Is major version 2 security vulnerabilities applicable for major version 1

2019-05-12 Thread Mark Waite
Yes, if the capability exists in that version, then it is likely affected.
Versions that old are not tested for vulnerabilities nor are security fixes
provided for them.

On Sun, May 12, 2019, 5:43 PM agiri  wrote:

> Hi,
>
> As per the Jenkins Security Advisory below I see it mentions Affected
> Version as :
>
> Affected Versions
> 
>
>- Jenkins weekly up to and including 2.171
>- Jenkins LTS up to and including 2.164.
>
>
> https://jenkins.io/security/advisory/2019-04-10/
>
>
> Does this mean it affects the Jenkins major version 1 as well . Eg:
> version  1.650 ?
>
> Thanks
> AG
>
> --
> 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/27fccb07-4365-44c4-a95d-5d5d1f87b1dd%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/CAO49JtFPR-PR-txNVEUMg7iG%3Dg%2BBnqF4bxX31v9Uq%3DO%3DB2p84A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

2019-05-08 Thread Mark Waite


On Wednesday, May 8, 2019 at 7:18:31 AM UTC-6, A M wrote:
>
> hi Mark
>
> I am struggling with a very similar issue. What exactly do you mean by 
> your comment and how do I achieve this?
>
>
I said:

> Run the Windows agent from the Windows desktop rather than running it 
from a service which has been allowed to interact with the desktop.

The most direct way to implement what I described is to:

   1. Login to the Windows desktop machine where code signing will be run
   2. Open a web browser to the Jenkins server
   3. Create an agent (a node) to represent that Windows computer
   4. Configure the agent to "Launch agent via Java Web Start"
   5. Define the required agent fields (like a remote root directory - I 
   prefer 'C:\J\' to reduce problems with Windows and long paths) and save the 
   configuration of that agent
   6. Download the 'agent.jar' file from the hyperlink on the web page, 
   save it somewhere convenient (like C:\J\agent.jar)
   7. Open a command prompt window on the Windows desktop machine and 
   change to the convenient directory C:\J
   8. Copy the 'Run from agent command line" from the web page into the 
   command prompt window

Thanks for asking!
Mark Waite
 

> I want to run the signtool.exe together with the certificate on a USB 
> token as an AfterPublish job in Jenkins. Jenkins is running as admin. 
> Single sign-on is activated for the USB token. Running signtool.exe in the 
> admin console works, running the same command through Jenkins results in 
> the "No certificates were found that met all the given criteria." error.
>
> Any help is much appreciated. Thank you!
>>
>>

-- 
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/41f90117-e810-4b47-864e-839fc444fb86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: scripted pipeline: bash: date -> MissingPropertyException: No such property: ... for class: groovy.lang.Binding

2019-05-02 Thread Mark Waite


On Thursday, May 2, 2019 at 6:35:58 AM UTC-6, b o b i wrote:
>
> Thank you, that work.
>
> Could you explain me why "\$" worked, i.e. where it is documented? (I lost 
> pretty much time with such "nonsense"). (a bash variable should be expanded 
> inside a bash script as $var or "${var}" etc., i.e. why in a bash, the vars 
> are not bashingly treated?)
>
>
The pipeline domain specific language is based on groovy.  Groovy does not 
expand variable references in strings surrounded by single quote characters 
(ASCII 0x27).  Groovy expands variable references in strings surrounded by 
double quote characters (ASCII 0x22).  A groovy variable reference in a 
string can have the same syntax as a bash variable reference.

Thus, your text:

sh """
  echo ${mytime}
"""

attempts to resolve the groovy variable 'mytime'.

If you had used:
sh '''
  echo ${mytime}
'''

it would attempt to resolve the shell variable 'mytime'.

See http://groovy-lang.org/syntax.html#_single_quoted_string and 
http://groovy-lang.org/syntax.html#_double_quoted_string for more details.

Mark Waite

 

> On Thursday, May 2, 2019 at 2:27:40 PM UTC+2, Daniel Butler wrote:
>>
>> Replace ${mytime} with \$mytime
>>
>> The mytime variable you've created is a bash one.
>>
>> Regards 
>> Daniel 
>>
>>
>> On Thu, 2 May 2019, 1:16 pm b o b i,  wrote:
>>
>>> Jenkins 2.174, in a scripted pipeline the following
>>>
>>> sh """#!/bin/bash
>>>echo "TTT"
>>>mytime="`date '+%Y_%m_%d__%H_%M_%S'`"
>>>echo ${mytime}
>>> """
>>>
>>> produces
>>>
>>> groovy.lang.MissingPropertyException: No such property: mytime for class: 
>>> groovy.lang.Binding
>>> at groovy.lang.Binding.getVariable(Binding.java:63)
>>> at 
>>> org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:270)
>>> at org.kohsuke.groovy.sandbox.impl.Checker$6.call(Checker.java:289)
>>> at 
>>> org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:293)
>>> ...
>>>
>>> How can I have current time expanded as a string without the above error?
>>>
>>> -- 
>>> 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/3b826017-27f1-45c9-925c-f396b13bcea9%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-users/3b826017-27f1-45c9-925c-f396b13bcea9%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> 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/34eb7130-cee0-4cab-be7e-dfffcd1fd572%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Odd environment problem with git under Jenkins on AIX

2019-04-30 Thread Mark Waite
On Tue, Apr 30, 2019 at 7:02 AM Rich Stephens wrote:


> I would be happy to join the platform group, though I am not sure of what
> assistance I might be.  While I have used Jenkins on Linux, AIX, HPUX, and
> Windows, my experience is limited to simple master setups building a legacy
> C/C++ project.
>
>
Anyone with the skills to maintain an aging AIX environment will certainly
be able to contribute when we're evaluating platform topics.  There are
often interesting subtleties in using Jenkins on a different platform that
can help the community as a whole.

Mark Waite


> Again, thank you for your assistance.
>
> --
> 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/c458b5e6-71aa-48a7-8fc9-cbdf4bcea6c6%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/c458b5e6-71aa-48a7-8fc9-cbdf4bcea6c6%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Odd environment problem with git under Jenkins on AIX

2019-04-26 Thread Mark Waite
On Fri, Apr 26, 2019 at 2:28 PM Rich Stephens  wrote:

> It was a bit of a joke.  I’m sorry if it offended you.
> It didn’t seem to offend anyone actually involved in the conversation, but
> thanks for the tip.
>
>
That was the point where I decided to stop responding to the thread.  You
seemed determined to proceed on the path that you had chosen.  That's your
right, since it is your time that you're investing in your exploration.

I am very interested to hear more about your experiences with Jenkins
masters on AIX.  While the JDK on AIX is JDK 1.8, I believe it is using the
IBM J9 virtual machine rather than the virtual machine provided by
OpenJDK.  I expect many interesting discoveries await you in that
exploration.  I'm aware of Jenkins agents on AIX and Jenkins agents on s390
mainframes (likely all running the IBM J9 virtual machine), but am not
aware of any other users running a Jenkins master on AIX.

If you're interested in the history of the J9 virtual machine, refer to
https://en.wikipedia.org/wiki/OpenJ9.  If you'd like to run a J9 virtual
machine on commodity hardware, refer to https://adoptopenjdk.net/ where you
can download an OpenJ9 based JDK.

If you'd like to join the Jenkins platform Special Interest Group, refer to
https://jenkins.io/sigs/platform/ .  We'd love to have your help as we work
with various platforms and explore various platforms.

Thanks!
Mark Waite


> --
> 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/900a6243-75d1-4cb4-bb75-63ee035e2335%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtG28aqSfe%3DwpEEgzJt5hhxFrrO4DmFq_m%3DOvg06p0E9cQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Odd environment problem with git under Jenkins on AIX

2019-04-26 Thread Mark Waite
On Fri, Apr 26, 2019 at 6:06 AM Rich Stephens  wrote:

> I was thinking exactly the same thing.  I'd still have the same
> environment problem, either way.
>
>>
>>
You might, but you won't have git commands executed to scan multibranch
pipelines, since those are executed on the master.

I assume that adjusting the environment of the agent is simpler and faster
to test than adjusting the environment of the agent.

Running the master on Linux (or Windows) allows you to use the same JDK
that is used by many Jenkins users.  That will reduce the amount of code
that might detect problems in the IBM JDK on AIX.  It was a preventive
suggestion for future problems, with some distant hope that it might also
assist with this specific issue.


>
>> --
> 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/86743ecd-4ee4-4bcb-8b4e-b80c1586b76c%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/86743ecd-4ee4-4bcb-8b4e-b80c1586b76c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Odd environment problem with git under Jenkins on AIX

2019-04-25 Thread Mark Waite
Sorry, but no suggestions to offer on how to resolve that issue.

I would suggest that you host the Jenkins master on Linux or Windows and
run an agent on AIX.  Running the master on AIX probably places you in the
"less than 0.1% of all users" category.

On Thu, Apr 25, 2019 at 1:30 PM Rich Stephens  wrote:

> I have finally gotten Jenkins and the git plugin running (I have managed
> to upgrade to Java8).
>
> git works perfectly from the command line.
>
> If I include /opt/freeware/lib into the LIBPATH when starting jenkins,
> when I try to connect to a remove repository, I get basically this error:
>
> OpenSSL version mismatch. Built against 1000105f, you have 10bf
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> Coincidentally, this is the same error that I get if I include
> /opt/freeware/lib in my own LIBPATH.
>
> If I _don't_ include /opt/freeware/lib in the LIBPATH for jenkins, I get:
>
> Failed to connect to repository : Command "git ls-remote -h ssh://
> g...@stash.saas-p.com:7999/optio/core.git HEAD" returned status code 255:
> stdout:
> stderr: exec(): 0509-036 Cannot load program git because of the following
> errors:
> 0509-150   Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not
> be loaded.
> 0509-152   Member libiconv.so.2 is not found in archive
>
> If I don't include it in my own LIBPATH, git works normally.
>
> I tried reproducing my own PATH and LIBPATH in the startup script for git,
> but still no joy.  I get the second error.
>
>
> Obviously there is some sort of environment issue with jenkins, but I
> can't figure out what it is.
> Any thoughts?
>
>
>
>
>
>
>
> --
> 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/87b14e73-7fc1-49aa-b944-e227b473146c%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/87b14e73-7fc1-49aa-b944-e227b473146c%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

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


Re: Under Jenkins SignTool Error "No certificates were found", works fine logged on as user

2019-04-25 Thread Mark Waite
On Thu, Apr 25, 2019 at 7:10 AM Hello Universe  wrote:

> How to use installed certificates from win8 using signtool?
>
>
Run the Windows agent from the Windows desktop rather than running it from
a service which has been allowed to interact with the desktop.  There seem
to be cases where programs run from services allowed to interact with the
desktop don't have the exact same capabilities as programs run from the
desktop.

Mark Waite


> On Thursday, August 27, 2015 at 10:51:29 PM UTC+8, Ed of the Mountain
> wrote:
>>
>> When I try to code sign in my Jenkins job I receive a SignTool error:
>>
>>
>> c:\jenkins\workspace\codesign-windows>
>>
>> signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe
>>
>> SignTool Error: No certificates were found that met all the given criteria.
>>
>>
>> I am using a DigiCert Extend Validation ( EV ) USB token that requires the 
>> USB token be connected to the build machine.  This works fine when logged on 
>> as normal user.
>>
>>
>>- I am running Jenkins as a Windows service.
>>- Service Log On is set to Local System account.
>>- Service is *allowed to interact with desktop.*
>>
>>
>>
>> When I logon as a normal user to the build machine, it works fine.
>>
>>
>> 1 - signtool sign /t http://timestamp.digicert.com /n "Acme Inc." code.exe
>>
>> 2 - This triggers a pop-up "Token Logon" dialog that requires user 
>> interaction
>>
>> 3 - I have a separate "Token Logon" watcher that finds the WIndows ID and 
>> enters password.
>>
>> 4 - Code is signed automatically
>>
>>
>> C:\jenkins\workspace\codesign-windows>signtool sign /t 
>> http://timestamp.digicert
>> .com /n "The Charles Machine Works, Inc." token-logon.exe
>> Done Adding Additional Store
>> Successfully signed: token-logon.exe
>>
>>
>> Any suggestions to try are much appreciated,
>>
>>
>> -Ed
>>
>> --
> 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/5c8ab94c-96ef-433d-9753-44336a67f2d5%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/5c8ab94c-96ef-433d-9753-44336a67f2d5%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
Mark Waite

-- 
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/CAO49JtGEuESLQpVtO-XP9QwAies3w%3D0BV%2BNwt1MoWBLS%3DsyirA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Jenkins 2.164 Prompting Terminal for Passphrase

2019-04-24 Thread Mark Waite
On Wed, Apr 24, 2019 at 6:30 PM Mark Waite 
wrote:

>
>
> On Wed, Apr 24, 2019 at 4:54 PM Mark Waite wrote:
>
>>
>>
>> On Wed, Apr 24, 2019 at 4:27 PM Randall Becker  wrote:
>>
>>> My docker image is doing fine, but the standalone Jenkins just won't
>>> authenticate with either JGit or git. It would be really nice to be able to
>>> do this without docker. Is there a standard launch recipe for my situation
>>> (in Ubuntu) or is SSH with passphrases just not available anymore?
>>>
>>>
>> If ssh with passphrases is not available anymore, that is a catastrophic
>> bug.  I'm reasonably confident that ssh with passphrases continues to be
>> available.  However, I won't be able to configure the test setup until
>> later this evening.  My Ubuntu 16 machine is busy right now running a
>> Docker image that would conflict with the native package install.
>>
>>
> I can't duplicate the problem you're seeing.  Steps I took while
> attempting to duplicate the problem included:
>
>1. Create a passphrase protected RSA private key (no special
>characters in the passphrase, since the git client plugin is known to have
>issues with special characters in the passphrase)
>2. Register the public key of that passphrase protected RSA key with
>my account on bitbucket.org
>3. Update ~/.ssh/config so that ssh access to the bitbucket repository
>from my account 'mwaite' will use the newly created passphrase protected
>RSA private key
>4. Confirm that git clone from bitbucket.org prompts for the
>passphrase for that private key and fails if I do not provide that
>passphrase
>5. Confirm that git clone  from bitbucket.org prompts for the
>passphrase for that private key and succeeds when I provide the correct
>passphrase
>6. Install Jenkins 2.164.2 on a fully patched Ubuntu 16.04 machine
>using the instructions from
>https://jenkins.io/doc/book/installing/#debianubuntu.  I installed the
>recommended plugins from the installation wizard and made no other
>configuration changes (this installs and runs as the user 'jenkins', not
>the user 'mwaite')
>7. Define a Jenkins credential using the passphrase protected RSA
>private key
>
> I failed to note one subtle value in the credential definition.  Since the
clone url provided by bitbucket is 'g...@bitbucket.org', I defined the
credential with the username 'git', not with my bitbucket username.  Since
my bitbucket username includes the '@' character (mark.earl.wa...@gmail.com),
it is not usable as the username portion of the repository URL  If the
previous version of git client plugin that you were running was before git
client plugin 2.7.3, then the credential may have worked even with the
wrong username in the credential.

There was a change made several versions of the git client ago to adapt to
a change in OpenSSH.  OpenSSH versions prior to 7.7 would accept an
incorrect value for the username and would then override that username with
the username that was embedded in the repository URL.  OpenSSH versions 7.7
and later fixed that OpenSSH bug.

The git client plugin had a dependency on that OpenSSH bug.  I don't think
that bug affects this case, since the OpenSSH version on Ubuntu 16.04 is
7.2, however, you can read about it at
https://issues.jenkins-ci.org/browse/JENKINS-50573

-- 
Thanks!
Mark Waite

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


Re: Jenkins 2.164 Prompting Terminal for Passphrase

2019-04-24 Thread Mark Waite
On Wed, Apr 24, 2019 at 4:54 PM Mark Waite wrote:

>
>
> On Wed, Apr 24, 2019 at 4:27 PM Randall Becker  wrote:
>
>> My docker image is doing fine, but the standalone Jenkins just won't
>> authenticate with either JGit or git. It would be really nice to be able to
>> do this without docker. Is there a standard launch recipe for my situation
>> (in Ubuntu) or is SSH with passphrases just not available anymore?
>>
>>
> If ssh with passphrases is not available anymore, that is a catastrophic
> bug.  I'm reasonably confident that ssh with passphrases continues to be
> available.  However, I won't be able to configure the test setup until
> later this evening.  My Ubuntu 16 machine is busy right now running a
> Docker image that would conflict with the native package install.
>
>
I can't duplicate the problem you're seeing.  Steps I took while attempting
to duplicate the problem included:

   1. Create a passphrase protected RSA private key (no special characters
   in the passphrase, since the git client plugin is known to have issues with
   special characters in the passphrase)
   2. Register the public key of that passphrase protected RSA key with my
   account on bitbucket.org
   3. Update ~/.ssh/config so that ssh access to the bitbucket repository
   from my account 'mwaite' will use the newly created passphrase protected
   RSA private key
   4. Confirm that git clone from bitbucket.org prompts for the passphrase
   for that private key and fails if I do not provide that passphrase
   5. Confirm that git clone  from bitbucket.org prompts for the passphrase
   for that private key and succeeds when I provide the correct passphrase
   6. Install Jenkins 2.164.2 on a fully patched Ubuntu 16.04 machine using
   the instructions from
   https://jenkins.io/doc/book/installing/#debianubuntu.  I installed the
   recommended plugins from the installation wizard and made no other
   configuration changes (this installs and runs as the user 'jenkins', not
   the user 'mwaite')
   7. Define a Jenkins credential using the passphrase protected RSA
   private key
   8. Define a Jenkins freestyle job that clones a private repository.
   Confirm that without the credential, the job will not clone.  Confirm that
   with the credential, it clones as expected
   9. Enable JGit
   10. Reconfigure the freestyle job to use JGit instead of command line
   git as the implementation.  Confirm that with the credential, it clones as
   expected using JGit

As far as I can tell, passphrase protected private keys are working as
expected from Ubuntu 16.04 to bitbucket using either a Docker image (with
useSETSID=true) or the native package installation (with default value for
useSETSID).

Mark Waite


>
>
>> java -jar jenkins.war
>>
>> doesn't cut it.
>>
>> :(
>>
>> On Wednesday, April 24, 2019 at 3:14:49 PM UTC-4, Randall Becker wrote:
>>>
>>> I'm rebuilding both docker and standalone images and will compare. The
>>> docker image is fine with the key pair after I restarted it. I also had to
>>> pick off the host signature using ssh -i blah g...@bitbucket.org... THEN
>>> the docker image was able to authenticate. I'm going to try the same on the
>>> standalone.
>>>
>>> On Wednesday, April 24, 2019 at 2:57:59 PM UTC-4, Mark Waite wrote:
>>>>
>>>> I've been using 2.164.1 and 2.164.2 since their release with both Java
>>>> 8 and Java 11, alternating between various configurations, I'm confident
>>>> the update is not DOA.
>>>>
>>>> I use bitbucket repositories that are secured with passphrase protected
>>>> private keys.  I use GitHub repositories that are secured with passphrase
>>>> protected private keys.  Check your configuration carefully.  Has the
>>>> passphrase protected private key been disabled in bitbucket?  Is Jenkins
>>>> reporting any issue with the private key format?
>>>>
>>>> On Wed, Apr 24, 2019 at 12:53 PM Randall Becker 
>>>> wrote:
>>>>
>>>>> I went back to try to use 2.164 on Docker and am experiencing similar
>>>>> issues. I wonder whether this update is DOA.
>>>>>
>>>>> On Wednesday, April 24, 2019 at 2:45:16 PM UTC-4, Mark Waite wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 24, 2019 at 12:35 PM Randall Becker 
>>>>>> wrote:
>>>>>>
>>>>>>> I should qualify... the passphrase prompt disappeared when setsid is
>>>>>>> used, but that still does not allow a passphrase-less keypair.
>>>>>>>
>>>>>>>
>>>>

  1   2   3   4   5   6   7   8   9   10   >