Re: Memory issues with Jenkins

2019-08-14 Thread Sverre Moe
We got an 30 minute free CloudBees support. It was too short to dig deeper 
to find the problem, but the person I was talking to (after examining our 
logs) mentioned what he thought was the problem and gave a suggestion.

We should not use Jenkins master at all for builds (allocated with the 
node("master") step). We had 15 Executors for Jenkins master.

We could also try to Increase limits of hard nofile and nproc for jenkins 
user, but the main recomondation was to remove all Executors for Jenkins 
master.
> /etc/security/limits.conf
jenkins  softcoreunlimited 
jenkins  hardcoreunlimited 
jenkins  softfsize   unlimited 
jenkins  hardfsize   unlimited 
jenkins  softnofile  4096 
jenkins  hardnofile  10240 #Was 8192
jenkins  softnproc   30654 
jenkins  hardnproc   60654 #Was 30654


To remove Jenkins master Executors will take some time. We use Jenkins 
master when we publish our build artifacts RPMs to our NFS file storage. 
Since our RPM NFS is only attached to the Jenkins master it is not possible 
at the moment. Unless we can use any other agent, then do a SCP onto our 
Jenkins master with the RPM artifacts.


We had a few other circumstances where we used Jenkins master. Like 
checking out a file to determine which build agent to actually use. These I 
have already changed to use any available build agent instead.

tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
>
> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
>
> We do however use NFS for the location where builds copy the RPM build 
> artifacts.
>
> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>
>> Hi, 
>>
>> Severe has another email thread open, I think it is the same Jenkins 
>> instance 
>> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer.
>>  
>> I dunno what happens on your instance but probably it isn’t better that you 
>> open another email thread with the description of your 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/3e728790-b2f5-4ae1-a9fe-512a5c912d61%40googlegroups.com.


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 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

Accessing user build variables of another build

2019-08-14 Thread 'Yasin Jamal' via Jenkins Users
Hi,
We have Jenkins 2.0 , Scripted Pipeline and i want to 
1. Push an environment variable VAR1=FOO in a Job A, and2. Access that 
environment variable from another Job B.
Job A and B both are independent.
When I invoke Job B, I want to go and find the latest build of Job A and then 
read the value of VAR1.
I tried the below that gives me the 'lastbuld of JobA' but how do i access VAR1 
of JobA ?
def currentJob = Jenkins.instance.getItemByFullName('JobA')def build = 
currentJob.getLastBuild()
Tried build.getEnvironment() but that gives me environment variables of JobA, 
NOT the one that I set. Also tried buld.getBuildVariables() but it throws 
error. I believe the getBuildVariables() method is for 'downstream' jobs.
Any idea how do i do this ?
BTW: I am seeting VAR1=FOO in JobA as env.VAR1="FOO"
Any help much appreciated.
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/1536195463.5250882.1565787195573%40mail.yahoo.com.


Re: Memory issues with Jenkins

2019-08-14 Thread Devin Nusbaum
I have not read the whole thread in detail, but the “Unable to create new 
native thread” OutOfMemoryErrors from your original thread where one of the 
stack traces involves 
org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing
 looks like it could be related to 
https://issues.jenkins-ci.org/browse/JENKINS-58684 
, which is a thread leak 
caused by the SSE Gateway Plugin. You could try reverting the SSE Gateway 
Plugin to version 1.17 to see if that helps, although that might reintroduce a 
different, somewhat rarer memory leak 
(https://issues.jenkins-ci.org/browse/JENKINS-51057 
). To test my hypothesis, 
if you are running SSE Gateway Plugin version 1.19, you can collect thread 
dumps over time and see if you seem to have a large number of threads named 
“EventDispatcher.retryProcessor” (unfortunately in version 1.18 and below the 
threads are automatically named “Timer #n”, which is less useful), which would 
confirm that you are hitting JENKINS-58684 
.

The advice to stop building on master is definitely a good idea as well.

> On Aug 14, 2019, at 07:11, Sverre Moe  wrote:
> 
> We got an 30 minute free CloudBees support. It was too short to dig deeper to 
> find the problem, but the person I was talking to (after examining our logs) 
> mentioned what he thought was the problem and gave a suggestion.
> 
> We should not use Jenkins master at all for builds (allocated with the 
> node("master") step). We had 15 Executors for Jenkins master.
> 
> We could also try to Increase limits of hard nofile and nproc for jenkins 
> user, but the main recomondation was to remove all Executors for Jenkins 
> master.
> > /etc/security/limits.conf
> jenkins  softcoreunlimited 
> jenkins  hardcoreunlimited 
> jenkins  softfsize   unlimited 
> jenkins  hardfsize   unlimited 
> jenkins  softnofile  4096 
> jenkins  hardnofile  10240 #Was 8192
> jenkins  softnproc   30654 
> jenkins  hardnproc   60654 #Was 30654
> 
> 
> To remove Jenkins master Executors will take some time. We use Jenkins master 
> when we publish our build artifacts RPMs to our NFS file storage. 
> Since our RPM NFS is only attached to the Jenkins master it is not possible 
> at the moment. Unless we can use any other agent, then do a SCP onto our 
> Jenkins master with the RPM artifacts.
> 
> 
> We had a few other circumstances where we used Jenkins master. Like checking 
> out a file to determine which build agent to actually use. These I have 
> already changed to use any available build agent instead.
> 
> tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
> 
> We do however use NFS for the location where builds copy the RPM build 
> artifacts.
> 
> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
> Hi, 
> 
> Severe has another email thread open, I think it is the same Jenkins instance 
> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer
>  
> .
>  I dunno what happens on your instance but probably it isn’t better that you 
> open another email thread with the description of your 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/3e728790-b2f5-4ae1-a9fe-512a5c912d61%40googlegroups.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/9FACF73D-081E-4DA8-92F0-86027EAC0868%40cloudbees.com.


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 
>  
> or 
> a remote 
>  
> 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, 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 
>> motivat

Re: Memory issues with Jenkins

2019-08-14 Thread Félix Belzunce Arcos
Hi Sverre Moe,

I am the person who talked to you this morning :-)

Long term solution is to avoid building on the master to avoid performance 
issue and the need to increase the number of processes and open files in 
the machine where the jenkins master is located. Building on the master is 
also not recommended from a security point of view.

Short term solution would be to increase the number of new processes on 
this machine + take thread dumps from the master each 10 minutes. For this, 
you can create a cron freestyle job executed every 10 minutes executing 
jstack . When the issue happens, you could take a look at the 
latest 10 builds with their thread dumps and try to figure out what is 
actually consuming so many threads on the master.

I hope this helps,


El miércoles, 14 de agosto de 2019, 15:38:17 (UTC+2), Devin Nusbaum 
escribió:
>
> I have not read the whole thread in detail, but the “Unable to create new 
> native thread” OutOfMemoryErrors from your original thread where one of the 
> stack traces involves 
> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing
>  looks 
> like it could be related to 
> https://issues.jenkins-ci.org/browse/JENKINS-58684, which is a thread 
> leak caused by the SSE Gateway Plugin. You could try reverting the SSE 
> Gateway Plugin to version 1.17 to see if that helps, although that might 
> reintroduce a different, somewhat rarer memory leak (
> https://issues.jenkins-ci.org/browse/JENKINS-51057). To test my 
> hypothesis, if you are running SSE Gateway Plugin version 1.19, you can 
> collect thread dumps over time and see if you seem to have a large number 
> of threads named “EventDispatcher.retryProcessor” (unfortunately in version 
> 1.18 and below the threads are automatically named “Timer #n”, which is 
> less useful), which would confirm that you are hitting JENKINS-58684 
> .
>
> The advice to stop building on master is definitely a good idea as well.
>
> On Aug 14, 2019, at 07:11, Sverre Moe > 
> wrote:
>
> We got an 30 minute free CloudBees support. It was too short to dig deeper 
> to find the problem, but the person I was talking to (after examining our 
> logs) mentioned what he thought was the problem and gave a suggestion.
>
> We should not use Jenkins master at all for builds (allocated with the 
> node("master") step). We had 15 Executors for Jenkins master.
>
> We could also try to Increase limits of hard nofile and nproc for jenkins 
> user, but the main recomondation was to remove all Executors for Jenkins 
> master.
> > /etc/security/limits.conf
> jenkins  softcoreunlimited 
> jenkins  hardcoreunlimited 
> jenkins  softfsize   unlimited 
> jenkins  hardfsize   unlimited 
> jenkins  softnofile  4096 
> jenkins  hardnofile  10240 #Was 8192
> jenkins  softnproc   30654 
> jenkins  hardnproc   60654 #Was 30654
>
>
> To remove Jenkins master Executors will take some time. We use Jenkins 
> master when we publish our build artifacts RPMs to our NFS file storage. 
> Since our RPM NFS is only attached to the Jenkins master it is not 
> possible at the moment. Unless we can use any other agent, then do a SCP 
> onto our Jenkins master with the RPM artifacts.
>
>
> We had a few other circumstances where we used Jenkins master. Like 
> checking out a file to determine which build agent to actually use. These I 
> have already changed to use any available build agent instead.
>
> tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
>>
>> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
>>
>> We do however use NFS for the location where builds copy the RPM build 
>> artifacts.
>>
>> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>
>>> Hi, 
>>>
>>> Severe has another email thread open, I think it is the same Jenkins 
>>> instance 
>>> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer.
>>>  
>>> I dunno what happens on your instance but probably it isn’t better that you 
>>> open another email thread with the description of your 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 jenkins...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/3e728790-b2f5-4ae1-a9fe-512a5c912d61%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To

Re: Memory issues with Jenkins

2019-08-14 Thread Sverre Moe
I only have the option to downgrade to 1.18 of Server Sent Events (SSE) 
Gateway Plugin
I would have to download the 1.17 and manually downgrade it.

>From the discussions it seems I also need to downgrade BlueOcean to 1.17
> Downgrading to BlueOcean 1.17 (which in turn uses sse-gateway 1.17) 
appears to have resolved our issue

This would be much more work. I would need to install all the BlueOcean 
1.17 manually as I can only downgrade to 1.18.0

I might be willing to try this, even with the risk 
of https://issues.jenkins-ci.org/browse/JENKINS-51057

I am running SSE 1.19, and have previously recorded jstack from Jenkins 
PID. I could not find any EventDispatcher.retryProcessor \t

onsdag 14. august 2019 15.38.17 UTC+2 skrev Devin Nusbaum følgende:
>
> I have not read the whole thread in detail, but the “Unable to create new 
> native thread” OutOfMemoryErrors from your original thread where one of the 
> stack traces involves 
> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing
>  looks 
> like it could be related to 
> https://issues.jenkins-ci.org/browse/JENKINS-58684, which is a thread 
> leak caused by the SSE Gateway Plugin. You could try reverting the SSE 
> Gateway Plugin to version 1.17 to see if that helps, although that might 
> reintroduce a different, somewhat rarer memory leak (
> https://issues.jenkins-ci.org/browse/JENKINS-51057). To test my 
> hypothesis, if you are running SSE Gateway Plugin version 1.19, you can 
> collect thread dumps over time and see if you seem to have a large number 
> of threads named “EventDispatcher.retryProcessor” (unfortunately in version 
> 1.18 and below the threads are automatically named “Timer #n”, which is 
> less useful), which would confirm that you are hitting JENKINS-58684 
> .
>
> The advice to stop building on master is definitely a good idea as well.
>
> On Aug 14, 2019, at 07:11, Sverre Moe > 
> wrote:
>
> We got an 30 minute free CloudBees support. It was too short to dig deeper 
> to find the problem, but the person I was talking to (after examining our 
> logs) mentioned what he thought was the problem and gave a suggestion.
>
> We should not use Jenkins master at all for builds (allocated with the 
> node("master") step). We had 15 Executors for Jenkins master.
>
> We could also try to Increase limits of hard nofile and nproc for jenkins 
> user, but the main recomondation was to remove all Executors for Jenkins 
> master.
> > /etc/security/limits.conf
> jenkins  softcoreunlimited 
> jenkins  hardcoreunlimited 
> jenkins  softfsize   unlimited 
> jenkins  hardfsize   unlimited 
> jenkins  softnofile  4096 
> jenkins  hardnofile  10240 #Was 8192
> jenkins  softnproc   30654 
> jenkins  hardnproc   60654 #Was 30654
>
>
> To remove Jenkins master Executors will take some time. We use Jenkins 
> master when we publish our build artifacts RPMs to our NFS file storage. 
> Since our RPM NFS is only attached to the Jenkins master it is not 
> possible at the moment. Unless we can use any other agent, then do a SCP 
> onto our Jenkins master with the RPM artifacts.
>
>
> We had a few other circumstances where we used Jenkins master. Like 
> checking out a file to determine which build agent to actually use. These I 
> have already changed to use any available build agent instead.
>
> tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
>>
>> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
>>
>> We do however use NFS for the location where builds copy the RPM build 
>> artifacts.
>>
>> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:
>>>
>>> Hi, 
>>>
>>> Severe has another email thread open, I think it is the same Jenkins 
>>> instance 
>>> https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer.
>>>  
>>> I dunno what happens on your instance but probably it isn’t better that you 
>>> open another email thread with the description of your 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 jenkins...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/3e728790-b2f5-4ae1-a9fe-512a5c912d61%40googlegroups.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-us

Re: Memory issues with Jenkins

2019-08-14 Thread Sverre Moe
I created a Pipeline job to run jstack every 10 minutes (though running on 
Jenkins master since that is where the Jenkins is running).

onsdag 14. august 2019 16.07.02 UTC+2 skrev Félix Belzunce Arcos følgende:
>
> Hi Sverre Moe,
>
> I am the person who talked to you this morning :-)
>
> Long term solution is to avoid building on the master to avoid performance 
> issue and the need to increase the number of processes and open files in 
> the machine where the jenkins master is located. Building on the master is 
> also not recommended from a security point of view.
>
> Short term solution would be to increase the number of new processes on 
> this machine + take thread dumps from the master each 10 minutes. For this, 
> you can create a cron freestyle job executed every 10 minutes executing 
> jstack . When the issue happens, you could take a look at the 
> latest 10 builds with their thread dumps and try to figure out what is 
> actually consuming so many threads on the master.
>
> I hope this helps,
>
>
> El miércoles, 14 de agosto de 2019, 15:38:17 (UTC+2), Devin Nusbaum 
> escribió:
>>
>> I have not read the whole thread in detail, but the “Unable to create new 
>> native thread” OutOfMemoryErrors from your original thread where one of the 
>> stack traces involves 
>> org.jenkinsci.plugins.ssegateway.sse.EventDispatcher.scheduleRetryQueueProcessing
>>  looks 
>> like it could be related to 
>> https://issues.jenkins-ci.org/browse/JENKINS-58684, which is a thread 
>> leak caused by the SSE Gateway Plugin. You could try reverting the SSE 
>> Gateway Plugin to version 1.17 to see if that helps, although that might 
>> reintroduce a different, somewhat rarer memory leak (
>> https://issues.jenkins-ci.org/browse/JENKINS-51057). To test my 
>> hypothesis, if you are running SSE Gateway Plugin version 1.19, you can 
>> collect thread dumps over time and see if you seem to have a large number 
>> of threads named “EventDispatcher.retryProcessor” (unfortunately in version 
>> 1.18 and below the threads are automatically named “Timer #n”, which is 
>> less useful), which would confirm that you are hitting JENKINS-58684 
>> .
>>
>> The advice to stop building on master is definitely a good idea as well.
>>
>> On Aug 14, 2019, at 07:11, Sverre Moe  wrote:
>>
>> We got an 30 minute free CloudBees support. It was too short to dig 
>> deeper to find the problem, but the person I was talking to (after 
>> examining our logs) mentioned what he thought was the problem and gave a 
>> suggestion.
>>
>> We should not use Jenkins master at all for builds (allocated with the 
>> node("master") step). We had 15 Executors for Jenkins master.
>>
>> We could also try to Increase limits of hard nofile and nproc for jenkins 
>> user, but the main recomondation was to remove all Executors for Jenkins 
>> master.
>> > /etc/security/limits.conf
>> jenkins  softcoreunlimited 
>> jenkins  hardcoreunlimited 
>> jenkins  softfsize   unlimited 
>> jenkins  hardfsize   unlimited 
>> jenkins  softnofile  4096 
>> jenkins  hardnofile  10240 #Was 8192
>> jenkins  softnproc   30654 
>> jenkins  hardnproc   60654 #Was 30654
>>
>>
>> To remove Jenkins master Executors will take some time. We use Jenkins 
>> master when we publish our build artifacts RPMs to our NFS file storage. 
>> Since our RPM NFS is only attached to the Jenkins master it is not 
>> possible at the moment. Unless we can use any other agent, then do a SCP 
>> onto our Jenkins master with the RPM artifacts.
>>
>>
>> We had a few other circumstances where we used Jenkins master. Like 
>> checking out a file to determine which build agent to actually use. These I 
>> have already changed to use any available build agent instead.
>>
>> tirsdag 6. august 2019 09.48.50 UTC+2 skrev Sverre Moe følgende:
>>>
>>> Sadly I was mistaken. We do not use NFS for JENKINS_HOME.
>>>
>>> We do however use NFS for the location where builds copy the RPM build 
>>> artifacts.
>>>
>>> mandag 5. august 2019 22.17.46 UTC+2 skrev Ivan Fernandez Calvo følgende:

 Hi, 

 Severe has another email thread open, I think it is the same Jenkins 
 instance 
 https://groups.google.com/d/msgid/jenkinsci-users/cc2d0bdb-b15f-4bec-a0a3-0562ea8c7df7%40googlegroups.com?utm_medium=email&utm_source=footer.
  
 I dunno what happens on your instance but probably it isn’t better that 
 you 
 open another email thread with the description of your 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 jenkins...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/

Re: Converting to pipeline questions

2019-08-14 Thread Louis Elston
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)?

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 
>>> 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 
>

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
 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

Re: Does Jenkins have a restriction (limit) with the number of concurrent connections to a Git repo (via Bitbucket) ?

2019-08-14 Thread Gareth Bowles
BitBucket server and other Git servers do have a limit on the maximum number of 
concurrent clones, which is a factor of the resources you have on the BitBucket 
server machine. See 
https://confluence.atlassian.com/bitbucketserver062/scaling-bitbucket-server-969537534.html

-- 
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/6cd7e11d-1a31-4a8c-ac50-673c6684d472%40googlegroups.com.


Re: Does Jenkins have a restriction (limit) with the number of concurrent connections to a Git repo (via Bitbucket) ?

2019-08-14 Thread Tony Cappellini
Oh, that is very helpful!

I had searched with so many terms, EXCEPT for scaling. Duh.

Thank you

On Wed, Aug 14, 2019 at 10:07 AM Gareth Bowles  wrote:
>
> BitBucket server and other Git servers do have a limit on the maximum number 
> of concurrent clones, which is a factor of the resources you have on the 
> BitBucket server machine. See 
> https://confluence.atlassian.com/bitbucketserver062/scaling-bitbucket-server-969537534.html
>
> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/jenkinsci-users/JzXBUT8rGjw/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6cd7e11d-1a31-4a8c-ac50-673c6684d472%40googlegroups.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/CABRXM4%3DX9ve%3DvHVHC1e%3Dg69O1Krm2zdQyLwghFDFm5aQdiYs-w%40mail.gmail.com.


Re: Jenkins Overwriting JobDSL Configured Job

2019-08-14 Thread Baptiste Mathus
What does the changelog for the plug-in say that could relate to your
problem?

Le mar. 13 août 2019 à 16:20, Chris McIntosh 
a écrit :

> Thanks for the help all,
>
> This is fixed.  I saw that the jobDsl plugin had an update, so I bumped
> the version up to 1.75 and it started working again.  (I should have
> mentioned I am using code that worked last month).
> I don't have a satisfying explanation other than my plugins may have been
> fighting with each other somehow.
>
> Thanks,
>
> Chris
>
> On Tue, 13 Aug 2019 at 08:29, Chris McIntosh 
> wrote:
>
>> Hi Reinhold,
>>
>> We are using pipeline jobs via a jenkinsfile.
>> I will double check my xml from the configure block vs the xml generated
>> by jenkins when manually adding the section through the UI.
>> I thought it was the same, though the UI added a bunch of extra sections
>> to the xml unrelated to my specific change.
>>
>> Thanks again for the help.
>>
>> Chris
>>
>> On Thu, 8 Aug 2019 at 08:12, Reinhold Füreder 
>> wrote:
>>
>>> Hi Chris,
>>>
>>>
>>>
>>> after re-reading also your initial email I have the feeling my pipeline
>>> focused/related answer is not helpful at all, as you are not using pipeline
>>> jobs, but presumably freestyle jobs?
>>>
>>>
>>>
>>> Another very naïve guess:
>>>
>>>- Could it be that using the JobDSL configure { } block changes the
>>>“config.xml” as you think is expected (because you “just” look at the
>>>“config.xml”), but in fact it is invalid and during opening the job
>>>configuration via Jenkins UI (via “Configure” button) it reads in the
>>>invalid “config.xml” and then detects and removes the invalid elements
>>>(that were added via JobDSL configure { } block)?
>>>
>>>
>>>
>>> Please note that I have no idea about JobDSL implementation, so this 2nd
>>> naïve guess could be even less helpful than the first one :-o
>>>
>>>
>>>
>>> Reinhold
>>>
>>>
>>>
>>>
>>>
>>> *From:* jenkinsci-users@googlegroups.com <
>>> jenkinsci-users@googlegroups.com> *On Behalf Of *Chris McIntosh
>>> *Sent:* Donnerstag, 8. August 2019 14:59
>>> *To:* jenkinsci-users@googlegroups.com
>>> *Subject:* Re: Jenkins Overwriting JobDSL Configured Job
>>>
>>>
>>>
>>> Thanks Reinhold,
>>>
>>>
>>>
>>> Any way you could think of to get the job to load first before it
>>> executes?
>>> I tried reloading all the config from disk which didn't work.  I didn't
>>> have a chance to try restarting it yet.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Chris
>>>
>>>
>>>
>>> On Wed, 7 Aug 2019 at 23:54, Reinhold Füreder 
>>> wrote:
>>>
>>> Hi Chris,
>>>
>>>
>>>
>>> just a very naive guess:
>>>
>>>- there are certain pipeline options or also called pipeline job
>>>properties (e.g. build discarder policy or pipeline triggers or pipeline
>>>parameters) that lead to updates of the pipeline job config once the
>>>corresponding “properties” step (of scripted) pipeline is executed
>>>
>>>
>>>
>>> HTH Reinhold
>>>
>>>
>>>
>>>
>>>
>>> *From:* jenkinsci-users@googlegroups.com <
>>> jenkinsci-users@googlegroups.com> *On Behalf Of *Chris McIntosh
>>> *Sent:* Mittwoch, 7. August 2019 22:25
>>> *To:* jenkinsci-users@googlegroups.com
>>> *Subject:* Jenkins Overwriting JobDSL Configured Job
>>>
>>>
>>>
>>> Hey All,
>>>
>>>
>>>
>>> Hoping somebody can shed some light on this.
>>>
>>>
>>>
>>> I am using the jobDsl plugin with a seed job to configure a job.
>>>
>>> The job is using a configure {} block to configure some aspect of the
>>> job for a plugin that doesn't have a jobDsl extension (Office365Connector).
>>>
>>>
>>> When I run the seed job, the config.xml file for the job is updated as
>>> expected with the plugin configuration.
>>>
>>> When i go to open the job in the Jenkins UI the plugin is not
>>> configured.  When I open the config.xml file for the job on the Jenkins
>>> Master filesystem, the config has been reverted somehow to remove the
>>> config block my jobDsl job has defined.
>>>
>>> I configured auditd to watch the config file and I see two log entries
>>> done by the jenkins user within a few seconds of each other indicating to
>>> me that something in Jenkins is causing the job config to get overwritten
>>> after my seed job has defined the job.
>>>
>>> Anybody have any clue how I can go about debugging this?
>>>
>>> Jenkins master is running on Ubuntu 18.04.  I can provide any other info
>>> needed.
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Chris
>>>
>>> --
>>> 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/CAJq9cAoMLWof5Y9nrQ5Ee0WxDVVqs8QP8NfKQ5r5c1WiuM2pdA%40mail.gmail.com
>>> 
>>> .
>>>
>>> -

Re: Converting to pipeline questions

2019-08-14 Thread Louis Elston
" 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.

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 (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, t