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 <[email protected]> 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 [email protected]. >>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c83b0909-6384-4065-8817-2bb3c038fa2b%40googlegroups.com.
