" 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 

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 <louels...@gmail.com 
> <javascript:>> 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 appear....you 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 <louels...@gmail.com> 
>>>>> 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&q=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 merge back to a master. In the repository we 
>>>>>>>> have 
>>>>>>>> product1.0 branch, product2.0 branch etc., and build only one branch 
>>>>>>>> (the 
>>>>>>>> latest one). While I do like the Blue Ocean editor, it is only for 
>>>>>>>> MultiBranch pipelines.
>>>>>>>> Looking for directions and\or examples on how to convert existing 
>>>>>>>> Jenkins non-pipeline systems, to pipeline.  I did find this…
>>>>>>>> https://wiki.jenkins.io/display/JENKINS/Convert+To+Pipeline+Plugin. 
>>>>>>>> It does help a little in that it gives you some converted steps, but 
>>>>>>>> cannot 
>>>>>>>> convert all the steps, and will give comments in the pipeline script 
>>>>>>>> "//Unable to convert a build step referring to...please verify and 
>>>>>>>> convert 
>>>>>>>> manually if required." There is an option "Recursively convert 
>>>>>>>> downstream 
>>>>>>>> jobs if any" and if you select that, it appears to add all the 
>>>>>>>> downstream 
>>>>>>>> jobs to the same pipeline script, and really confuses the job 
>>>>>>>> parameters. 
>>>>>>>> There is also an option to "Commit JenkinsFile" (if doing 
>>>>>>>> declarative). I 
>>>>>>>> will play with this some more, but it is not the be all and end all of 
>>>>>>>> converting to pipeline, and I still am not sure of whether I should be 
>>>>>>>> have 
>>>>>>>> one or more scripts.
>>>>>>>> Added 07/26/19 - Let’s see if I have my research to date correct…
>>>>>>>> A Declarative pipeline (Pipeline Script from SCM), is stored in a 
>>>>>>>> Jenkinsfile in the repository. Every time that this Jenkins job is 
>>>>>>>> executed, a fetch from the repository is done (to get the latest 
>>>>>>>> version of 
>>>>>>>> the Jenkinsfile).
>>>>>>>> A Pipeline script is stored as part of the config.xml file in the 
>>>>>>>> Jenkins\Jobs folder (it is not stored in the repository, or in a 
>>>>>>>> separate 
>>>>>>>> Jenkinsfile in the jobs folder). There is a fetch from the repository 
>>>>>>>> only 
>>>>>>>> if you put it in (you do not need to do a repository fetch to get the 
>>>>>>>> Pipeline script).
>>>>>>>> Besides our nightly product build, we also have other jobs. I could 
>>>>>>>> create a separate Declarative Jenkinsfile for each of them 
>>>>>>>> (JenkinsfileA, 
>>>>>>>> JenkinsfileB, etc.) for each of the other jobs and store then in the 
>>>>>>>> repository also (in the same branch as the main Jenkinsfile), but that 
>>>>>>>> would mean that every one of those additional jobs, to get the 
>>>>>>>> particular 
>>>>>>>> Jenkinsfile for that job, would also need to do a repository fetch 
>>>>>>>> (basically fetching\cloning the repository branch for each job, and 
>>>>>>>> have 
>>>>>>>> multiple versions of the repository branch unnecessarily downloaded to 
>>>>>>>> the 
>>>>>>>> workspace of each job).
>>>>>>>> That does not make sense to me (unless my understanding of things 
>>>>>>>> to date is incorrect). Because the main product build does require a 
>>>>>>>> fetch 
>>>>>>>> every time it is run (to get any possible developer check-ins), I do 
>>>>>>>> not 
>>>>>>>> see a problem doing Declarative Jenkinsfile for that job. For the 
>>>>>>>> other 
>>>>>>>> jobs (if we do not leave then for the time being in the classic 
>>>>>>>> (non-pipeline) format)), they will be Pipeline scripts.
>>>>>>>> Is there any way of (or plans for), being able to do Declarative 
>>>>>>>> pipeline without having to store in the repository and doing a fetch 
>>>>>>>> every 
>>>>>>>> time (lessening the need to become a Groovy developer)? The Blue Ocean 
>>>>>>>> script editor appears to be an easier tool to use to create pipeline 
>>>>>>>> scripts, but it is only for MultiBranch pipelines (which we don’t do).
>>>>>>>> Serialization (restarting a job), is that only for when a node goes 
>>>>>>>> down, or can you restart a pipeline job (Declarative or Scripted), 
>>>>>>>> from any 
>>>>>>>> point if it fails?
>>>>>>>> I see that there are places to look to see what Jenkins plugin’s 
>>>>>>>> have been ported to pipeline, but is there anything that can be run to 
>>>>>>>> look 
>>>>>>>> at the classic jobs that you have, to determine up front which jobs 
>>>>>>>> are 
>>>>>>>> going to have problems being converted to pipeline (non supported 
>>>>>>>> plugins)?
>>>>>>> -- 
>>>>>> 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/912b3b5f-a204-4b83-ad35-9fd94dcb2aa4%40googlegroups.com
>>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/912b3b5f-a204-4b83-ad35-9fd94dcb2aa4%40googlegroups.com?utm_medium=email&utm_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 jenkins...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/2f528dcf-ccc2-4031-8ec2-18496f1a4921%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/2f528dcf-ccc2-4031-8ec2-18496f1a4921%40googlegroups.com?utm_medium=email&utm_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 

Reply via email to