In this post I wanted to show how you can run Jenkins behind a firewall (which could be a corporate firewall, a NAT’ed network like you have at home) but still receive webhooks in real time from GitHub.com. You can generalise this to other services too - such as BitBucket or DockerHub, or anything really that emits webhooks, but the instructions will be for GitHub projects hosted on github.com. What are webhooks Just a very quick refresher on what webhooks are: Messages (often JSON, but not always) typically posted by HTTP(S) from a server to a client that is listening for events. The events flow left to right, Jenkins sits there happily listing on paths like /github-webhook/ or /dockerhub-webhook/ etc for some HTTP request to tell it to wake up and do some work. GitHub/BitBucket may be reporting a new commit or PR, or DockerHub reporting an upstream image has changed. What all these things have in common is that they push to Jenkins, and expect to be able to push to it (ie that Jenkins is visible to them). This works great when the network is open - say GitHub Enterprise, or Jenkins is listening on the web. Not on the web The trick is when something gets in the middle, say a firewall: ( As is industry standard, all firewalls have to be a wall on fire. Please don’t somehow set bricks on fire in your organisation) This is just the same when you fire up Jenkins on your laptop, and want to receive webhooks from github.com (a legitimate thing, perhaps to test out your setup, perhaps to run builds for iOS on a mac, or some corner of a network that is not exposed to the web). Unless your laptop is addressable to the whole web that is (not likely), or your network is configured just right, the webhooks won’t be able to flow. This is fine - we can fall back to polling for changes. Except this is terrible. You burn through API quotas, and you don’t get changes in real time, and really no one is happy. Some problems are opportunities We can both solve this problem, but also, view this is an opportunity. Having things not addressable on the web, or locked down in some default way is a feature, not a bug. You massively reduce your attack surface, and can have defence in depth: A Webhook forwarding service Enter the memorably named Smee. This is an OSS project provided by GitHub and also helpfully hosted as a service by GitHub. This can capture and forward webhooks for you. I’ll try to explain it with a diagram: GitHub pushes an event (via HTTPS/json in this case) to Smee.io (the funny thing with circles, which is on the public web and accessible from GitHub.com) - and Jenkins in turn subscribes to Smee with an outgoing connection from a client. Note the direction of the arrows: Jenkins only makes an outbound connection. This is the important point: this will work as long as the firewall is one way (like a NAT typically is, and many networks). If the Jenkins side can’t connect to anything on the outside world - well, this won’t help with that of course (but that is not often the case). Setting it up Step 1: Firstly - go to https://smee.io/ and click “Start a new channel”: This will give you a unique URL (which you should copy for later use): Next you should install the smee client next to where you have the Jenkins server running: npm install --global smee-client (This will make the smee client/command available to receive and forward webhooks). Now start the smee client and point it to your Jenkins server. In this case I have it running on port 8080 (the default if you fire it up on your laptop, change both the port and the smee URL as needed): smee --url https://smee.io/GSm1B40sRfBvSjYS --path /github-webhook/ --port 8080 This says to connect to the smee service, and forward webhooks to /github-webhook/ (that trailing slash is important, don’t miss it). Once this is running, you will see it log that it is connected and forwarding webhooks. Leave this command running for as long as you want to receive webhooks. Next, you need to configure a pipeline that makes use of github. In this case I set up one from scratch. You can skip this if you already have a pipeline setup: I then chose “GitHub” as the where the code is: Then choose your repository. This will set things up ready to receive webhooks from GitHub. (also if you have an existing pipeline setup, and it is using GitHub as the SCM source, that is also fine). The final step is to tell GitHub to post webhook events for that repository (or organization, you can do that too) to Smee (which ultimately means Jenkins will receive them). Go to the settings tab for your GitHub repository, and then click “add webhook”: Next, configure the webhook: Paste in the “smee” URL you copied from the step above. Choose application/json as the content type Tell it to send everything (you can pick and choose what events, but I just did that as simpler). Press Add Webhook (or update) It should look something like this: OK - webhooks should be flowing now. You can make a change to your repository, and check that a build starts soon after: Good luck!

I use macOS day to day, and often struggle to keep my devtools up to date. This isn’t any fault of packaging or tools, more just that I get tired of seeing the beachball: The demands on dev machines grow, developers are now working across a more diverse set of technologies than just a JVM or a single scripting language these days. This keeping up to date is a drag on time (and thus money). There are lots of costs involved with development, and I have written about about the machine cost for development (how using something like GKE can be much cheaper than buying a new machine) but there is also the cost of a developer’s time. Thankfully, there are ways to apply the same smarts here to save time as well as money. And time is money, or money is time? Given all the work done in automating the detection and installation of required tools, environments, and libraries that goes on when you run ‘jx import’ in Jenkins X, it makes sense to also make those available for development time, and the concept of “DevPods” was born. The pod part of the name comes from the Kubernetes concept of pods (but you don’t have to know about Kubernetes or pods to use Jenkins X. There is a lot to Kubernetes but Jenkins X aims to provide a developer experience that doesn’t require you to understand it). Why not use Jenkins X from code editing all the way to production, before you even commit the code or open a pull request? All the tools are there, all the environments are there, ready to use (as they are used at CI time!). This rounds out the picture: Jenkins X aims to deal with the whole lifecycle for you, from ideas/issues, change requests, testing, CI/CD, security and compliance verification, rollout and monitoring. So it totally makes sense to include the actual dev time tools. If you have an existing project, you can create a DevPod by running (with the jx command): jx create devpod This will detect what type of project is (using build packs) and create a DevPod for you with all the tools pre-installed and ready to go. Obviously, at this point you want to be able to make changes to your app and try it out. Either run unit tests in the DevPod, or perhaps see some dev version of the app running in your browser (if it is a web app). Web-based code editors have been a holy grail for some time, but never have quite taken off in the mainstream of developers (despite there being excellent ones out there, most developers prefer to develop on their desktop). Ironically, the current crop of popular editors are based around “electron” which is actually a web technology stack, but it runs locally (Visual Studio Code is my personal favourite at the moment), in fact Visual Studio Code has a Jenkins X extension (but you don’t have to use it): To get your changes up to the Dev Pod, in a fresh shell run (and leave it running): jx sync This will watch for any changes locally (say you want to edit files locally on your desktop) and sync them to the Dev Pod. Finally, you can have the Dev Pod automatically deploy an “edit” version of the app on every single change you make in your editor: jx create devpod --sync --reuse ./watch.sh The first command will create or reuse an existing Dev Pod and open a shell to it, then the watch command will pick up any changes, and deploy them to your “edit” app. You can keep this open in your browser, make a change, and just refresh it. You don’t need to run any dev tools locally, or any manual commands in the Dev Pod to do this, it takes care of that. You can have many DevPods running (jx get devpods), and you could stop them at the end of the day (jx delete devpod), start them at the beginning, if you like (or as I say: keep them running in the hours between coffee and beer). A pod uses resources on your cluster, and as the Jenkins X project fleshes out its support for dev tools (via things like VS Code extensions) you can expect even these few steps to be automated away in the near future, so many of the above instructions will not be needed! End-to-end experience So bringing it all together, let me show a very wide (you may need to zoom out) screen shot of this workflow: From Left to Right : I have my editor (if you look closely, you can see the Jenkins X extension showing the state of apps, pipelines and the environments it is deployed to). In the middle I have jx sync running, pushing changes up to the cloud from the editor, and also the ‘watch’ script running in the DevPod. This means every change I make in my editor, a temporary version of the app (and its dependencies are deployed). On the right is my browser open to the “edit” version of the app. Jenkins X automatically creates an “edit” environment for live changes, so if I make a change to my source on the left, the code is synced, build/tested and updated so I can see the change on the right (but I didn’t build anything locally, it all happens in the DevPod on Jenkins X). On visual studio code: The Jenkins X extension for visual studio code can automate the creation of devpods and syncing for you. Expect richer support soon for this editor and others. Explaining things with pictures To give a big picture of how this hangs together: In my example, GitHub is still involved, but I don’t push any changes back to it until I am happy with the state of my “edit app” and changes. I run the editor on my local workstation and jx takes care of the rest. This gives a tight feedback loop for changes. Of course, you can use any editor you like, and build and test changes locally (there is no requirement to use DevPods to make use of Jenkins X). Jenkins X comes with some ready to go environments: development, staging and production (you can add more if you like). These are implemented as Kubernetes namespaces to avoid the wrong app things talking to the wrong place. The development environment is where the dev tools live: and this is also where the DevPods can live! This makes sense as all the tools are available, and saves the hassle of you having slightly different versions of tools on your local workstation than what you are using in your pipeline. DevPods are an interesting idea, and at the very least a cool name! There will be many more improvements/enhancements in this area, so keep an eye out for them. They are a work in progress, so do check the documentation page for better ways to use them. Some more reading: Docs on DevPods on jenkins-x.io The Visual Studio Code extension for Jenkins X (what a different world: an open source editor by Microsoft!) James Strachan’s great intro to Jenkins X talk at Devoxx-UK also includes a DevPod demo

(adapted from this blog post by Daniel Nurmi) As more and more Jenkins users ship docker containers, it is worth thinking about the security implications of this model, where the variance in software being included by developers has increased dramatically from previous models. Security implications in this context include what makes up the image, but also the components of the app that get bundled into your image. Docker images are increasingly becoming a “unit of deployment”, and if you look at a typical app (especially if it is a microservice), much of the components, libraries, and system are someone else’s code. Anchore exists to provide technology to act as a last line of defense, verifying the contents of these new deployable units against user specified policies to enforce security and compliance requirements. In this blog you will get a quick tour of this capability, and how to add the open-source Anchore Engine API service into your pipeline to validate that the flow of images you are shipping comply with your specific requirements, from a security point of view. Key among the fundamental tenets of agile development is the notion of “fail fast, fail often”, which is where CI/CD comes in: A developer commits code into the source code repository, such as git, that automatically triggers Jenkins to perform a build of the application that is then run through automated tests. If these tests fail the developer is notified immediately and can quickly correct the code. This level of automation increases the overall quality of code and speeds development. While some may feel that “fail fast” sounds rather negative (especially regarding security), you could better describe this process as “learn fast” as mistakes are found earlier in the development cycle and can be easily corrected. The increased use of CI/CD platforms such as Jenkins has helped to improve the efficiency of development teams and streamlined the testing process. We can leverage the same CI/CD infrastructure to improve the security of our container deployments. For many organizations the last step before deploying an application is for the security team to perform an audit. This may entail scanning the image for vulnerable software components (like outdated packages that contain known security vulnerabilities) and verifying that the applications and OS are correctly configured. They may also check that the organization’s best practices and compliance policies have been correctly implemented. In this post we walk through adding security and compliance checking into the CI/CD process so you can “learn fast” and correct any security or compliance issues early in the development cycle. This document will outline the steps to deploy Anchore’s open source security and compliance scanning engine with Jenkins to add analytics, compliance and governance to your CI/CD pipeline. Anchore has been designed to plug seamlessly into the CI/CD workflow, where a developer commits code into the source code management system, which then triggers Jenkins to start a build that creates a container image. In the typical workflow this container image is then run through automated testing. If an image does not meet your organization’s requirements for security or compliance then it makes little sense to invest the time required to perform automated tests on the image, it would be better to “learn fast” by failing the build and returning the appropriate reports back to the developer to allow the issue to be addressed. Anchore has published a plugin for Jenkins which, along with Anchore’s open source engine or Enterprise offering, allows container analysis and governance to be added quickly into the CI/CD process. Requirements This guide presumes the following prerequisites have been met: Jenkins 2.x installed and running on a virtual machine or physical server. Anchore-Engine installed and running, with accessible engine API URL (later referred to as) and credentials (later referred to as and) available - see Anchore Engine overview and installation. Anchore’s Jenkins plugin can work with single node installations or installations with multiple worker nodes. Step 1: Install the Anchore plugin The Anchore plugin has been published in the Jenkins plugin registry and is available for installation on any Jenkins server. From the main Jenkins menu select Manage Jenkins, then Manage Plugins, select the Available tab, select and install Anchore Container Image Scanner. Step 2: Configure Anchore Plugin. Once the Anchore Container Image Scanner plugin is installed - select Manage Jenkins menu click Configure System, and locate the Anchore Configuration section. Select and enter the following parameters in this section: Click Enable Anchore Scanning Select Engine Mode Enter your in the Engine URL text box - for example: http://your-anchore-engine.com:8228/v1 Enter your and in the Engine Username and Engine Password fields, respectively Click Save An example of a filled out configuration section is below, where we’ve used “http://192.168.1.3:8228/v1” as, “admin” as and “foobar” as : At this point the Anchore plugin is configured on Jenkins, and is available to be accessed by any project to perform Anchore security and policy checks as part of your container image build pipeline. Step 3: Add Anchore image scanning to a pipeline build. In the Pipeline model the entire build process is defined as code. This code can be created, edited and managed in the same way as any other artifact of your software project, or input via the Jenkins UI. Pipeline builds can be more complex including forks/joins and parallelism. The pipeline is more resilient and can survive the controller node failure and restarts. To add an Anchore scan you need to add a simple code snippet to any existing pipeline code that first builds an image and pushes it to a docker registry. Once the image is available in a registry accessible by your installed Anchore Engine, a pipeline script will instruct the Anchore plugin to: Send an API call to the Anchore Engine to add the image for analysis Wait for analysis of the image to complete by polling the engine Send an API call to the Anchore Engine service to perform a policy evaluation Retrieve the evaluation result and potentially fail the build if the plugin is configured to fail the build on policy evaluation STOP result (by default it will) Provide a report of the policy evaluation for review Below is an example end-to-end script that will make a Dockerfile, use the docker plugin to build and push the a docker container image to dockerhub, perform an Anchore image analysis on the image and the result, and cleanup the built container. In this example, we’re using a pre-configured docker-exampleuser named dockerhub credential for dockerhub access, and exampleuser/examplerepo:latest as the image to build and push. These values would need to be changed to reflect your own local settings, or you can use the below example to extract the analyze stage to integrate an anchore scan into any pre-existing pipeline script, any time after a container image is built and is available in a docker registry that your anchore-engine service can access. pipeline { agent any stages { stage('build') { steps { sh''' echo 'FROM debian:latest’ > Dockerfile echo ‘CMD ["/bin/echo", "HELLO WORLD...."]' >> Dockerfile ''' script { docker.withRegistry('https://index.docker.io/v1/', 'docker-exampleuser') { def image = docker.build('exampleuser/examplerepo:latest') image.push() } } } } stage('analyze') { steps { sh 'echo "docker.io/exampleuser/examplerepo:latest `pwd`/Dockerfile" > anchore_images' anchore name: 'anchore_images' } } stage('teardown') { steps { sh''' for i in `cat anchore_images | awk '{print $1}'`;do docker rmi $i; done ''' } } } } This code snippet writes out the anchore_images file that is read by the plugin to determine which image is to be added to Anchore Engine for scanning. This code snippet can be crafted by hand or built using the Jenkins UI, for any Pipeline project. In the project configuration, select Pipeline Syntax from the Project. This will launch the Snippet Generator where you can enter the available plugin parameters and press the Generate Pipeline Script button which will produce a snippet that you can use as a starting point. Using our example from above, next we save the project: Note that once you are happy with your script, you could also check it into a Jenkinsfile, alongside the source code. Step 4: Run the build and review the results. Finally, we run the build, which will generate a report. In the below screenshots, we’ve scanned the image docker.io/library/debian:latest to demonstrate some example results. Once the build completes, the final build report will have some links that will take you to a page that describes the result of the Anchore Engine policy evaluation and security scan: In this case, since we left the Fail build on policy STOP result as its default (True), the build has failed due to anchore-engine reporting a policy violation. In order to see the results, click the Anchore Report (STOP) link: Here, we can see that there is a single policy check that has generated a ‘STOP’ action, which triggered due to a high severity vulnerability being found against a package installed in the image. If there were only ‘WARN’ or ‘GO‘ check results here, they would also be displayed, but the build would have succeeded. With the combination of Jenkins pipeline project capabilities, plus the Anchore scanner plugin, it’s quick and easy to add container image security scanning and policy checking to your Jenkins project. In this example, we provide the mechanism for adding scanning to a Jenkins pipeline project using a simple policy that is doing an OS package vulnerability scan, but there are many more policy options that can be configured and loaded into Anchore Engine ranging from security checks to your own site-specific best practice checks (software licenses, package whitelist/blacklist, dockerfile checks, and many more). For more information about the breadth of Anchore policies, you can find information about Anchore Engine configuration and usage here. For more information on Jenkins Pipelines and Anchore Engine, check out the following information sources: https://anchore.com/ https://anchore.com/opensource/ https://github.com/anchore/anchore-engine https://anchore.freshdesk.com/support/home Chat on Anchore open source slack

I recently wrote about how all the cloud platforms are all in Kubernetes and so are developers. It is an exciting time, but the problem for many is that this is a huge blank sheet of paper for how to build and deploy applications. A white space, a void, a limitless canvas of possibilities. Insert metaphors here. The problem, as you may guess, is that few people really like or are able to start with a blank canvas. I know I prefer to start with something working and iterate towards a solution, or be given some rails to stay on (again with the metaphors). That’s where the Jenkins X project comes in. Jenkins X is a Kubernetes-native continuous integration and continuous delivery platform for developing cloud native applications that was recently introduced as a Jenkins Enhancement Proposal, sponsored by James Strachan. There is a lot to take in but at it’s heart, this is an open source opinionated way to do continuous delivery with Kubernetes, natively, without necessarily having to learn all the things I talked about in my last blog post. I shall attempt to explain what this is all about and why it matters to developers. As someone said on the jenkins-dev mailing list “We have the two glued together with baling wire and twine” - Jenkins X aims to simplify how to work with continuous delivery and Kubernetes. First and most importantly, let’s see the logo: You can see the nautical theme leaking through (and Kubernetes). Whilst it is called Jenkins X, it is about quite a lot more than Jenkins. Jenkins X makes decisions for you Jenkins X presents itself to you initially as a handy sleek command line (a native binary you can install called jx - the debate is on as to how pronounce it). Let’s take a tour (sail?): jx import my-app If you have an existing project, this will detect what type of project it is, build a pipeline for you (and a bunch of Kubernetes things, like Helm Charts), add it to your project and set it up in GitHub, WebHooks and all, build the project (run the pipeline) and deploy a version to a “staging” environment. If it looks ok, you can promote it to production: jx promote --env production --version 1.0.1 my-app If something went wrong in production, you can roll back an app to any version (the version numbers are made for you): jx promote --env production --version 1.0.0 my-app > jx get apps # list versions An environment is a well-established concept for web developers using continuous delivery: out of the box Jenkins X makes three of them for you (dev, staging and production), but you can make as many as you like. Environments have rules around how things are promoted into them (and they also have their own extensible pipelines, but you can just use them as-is to start). You can also create a Spring Boot microservice app: jx create spring Answer a few questions and it will set everything up for you. Any changes you make to your app automatically are built, and if the build looks good, they go through to the staging environment. WebHooks are setup for you (if you are using GitHub) to smooth this over. For those looking at starting from pre-made apps, there are "quickstarts": jx create quickstart They are based on a growing set of starter apps, in a variety of languages and tech stacks. Review apps for your changes: Each pull request is built/tested, and a “review app” is made available in a temporary environment. That means each proposed change, before it goes to the default branch (master), has an environment made (temporary) that it can be tried out in. In GitHub, this shows up as a comment in the pull request: Project type detection As you can see, so far there is no editing or manual creation of pipelines, or scripting or setup, just importing or creating your app and go. This is powered by Draft “packs” (a handy project that came out of Azure). What you end up with is a Jenkinsfile in your project repository. You may want to edit it one day, or you may be happy with it as is! Jenkins is famous for being un-opinionated in what you do, but Jenkins X has strong opinions (but you can extend and customise). image::/images/jenkins-x/draft-logo.png[Draft Logo, width=300] Deploying or promoting to environments Deploying happens via pipelines behind the scenes - when a change is pushed, or a version promoted. You don’t need to directly interact with Kubernetes if you don’t need to. A tool called Helm does the heavy lifting: Helm is used to package and perform installations and upgrade for your apps. There is a little more magic going on here with environments, which you don’t see at first. Each environment, for a team, is represented by a Git repository behind the scenes. Configuration as code is a well-established best practice these days, so why not use it to track deployments and initiate deployments. I also mentioned in my previous post how declarative Kubernetes is: it is perfect for keeping all config in a repository, of the desired system state. Each promotion is actually a pull request to a per-environment repository. This repository is made and managed for you (and kept outside of the main application code repository), you don’t have to look at it, but you can extend things there should you need to. Specific environment repositories may have different access rules, or be controlled by a different team (perhaps even deploy to a different cluster). Some have coined the term for this as “GitOps.” I first came across this concept on a WeaveWorks blog. I’ll try and explain this one with a diagram: The pipeline is actually split in the middle. On the left is the more familiar continuous integration pipeline. This works on pull requests, pre-release version of things and is all about testing(automated and manual review). The source of truth for this is the configuration in the applications repository: branches, pull requests and so on. The right-hand side is the continuous delivery pipeline. This kicks in when the application is ready to be updated with a new release. This is the “GitOps” repo behind the scenes that controls the state of things in Kubernetes. A promotion on this side is a pull request, and then a merge, from the staging repository to the production repository. Installing Jenkins X The jx command line has a jx install command that installs it into a Kubernetes cluster. The best experience initially is using Google’s excellent GKE service: jx create cluster gke This will ask a few questions, and go and set it all up for you in a cluster set aside for Jenkins X (recommended). Jenkins X runs entirely as services on top of a Kubernetes cluster. jx install Is designed to work with a Kubernetes cluster (if it already exists, recommendation is to have a cluster put aside for Jenkins X if possible). Amazon EKS support is coming (mostly it is around testing), that service is in beta/early access so it is still a work in progress, as is Microsoft Azures excellent AKS service. So where is Jenkins? Good question, thanks for asking. Well, it is behind the scenes. As you have seen, there was no direct interaction with Jenkins, but it is there, running the pipelines for continuous integration and continuous delivery of the respective repositories, and orchestrating things with Kubernetes. If you run jx get pipelines you can see URLs to the various pipelines that have been setup for you are part of interacting with Jenkins X. By the way, James Strachan has written an extensive blog on jenkins.io that really explores the Jenkins X project in-depth. Once you finish reading this blog, take a stroll on over there and read James'. He also provides several ways you can get involved in the project. What else can I do with the command line? Lots, the jx command line has built in help: jx open open apps, services or pipelines in your browser jx activity explains how things got to where they are, a history jx get environments list environments jx get apps show the state of applications, what versions are in what environments. What’s next There is a whole lot more to this, and lots more moving parts and services that are set up for you that are very useful, but it is best to head over to jenkins-x.io and have a look. This project is obviously in early stages (it is stll a Draft JEP after all) and there is lots happening. Check out the Jenkins X community if you want to chat on slack, IRC, issues or email. Also, read the Jenkins Enhancement Proposal doc.

We’re counting down the weeks until Blue Ocean 1.0, and we’re getting close! In this past week, the first release candidate has gone out to the Update Center, along with a new Pipeline Editor plugin. The Blue Ocean Pipeline Editor is its own plugin which integrates into Blue Ocean, so this was a coordinated release with Blue Ocean 1.0 rc1. Noteworthy this week: RC1 includes the Blue Ocean Pipeline Editor, which is integrates support for branch editing and saving the Pipeline back to GitHub (also referred to as "round-tripping"). Many dependencies have been upgraded Per-stage raw logs can be downloaded, this will be included in the next release. Editor design improvements Fixes for overflowing text The new sleeker favorite card design has been released, so you can fit more favorites on your screen! The Blue Ocean Pipeline Editor is better integrated into a few different screens in Blue Ocean. For example, you can open the editor from the results screen (top right): Or open the editor from branch listings: Up next: More bug-bashing! Please join us in testing the release candidate. Instructions for trying Blue Ocean can be found on our project page. Another release candidate Enjoy! If you’re interested in helping to make Blue Ocean a great user experience for Jenkins, please join the Blue Ocean development team on Gitter!

We’re counting down the weeks until Blue Ocean 1.0. This week was one of continuing consolidation and polish. We also released b25 (beta #25), a collectors edition. The next version we will likely release will be a release candidate (RC). The b25 release however contained a number of fixes and features, such as branch filtering. Some other updates of note from this past week: Updated a bunch of dependencies around Pipeline and fixed a whole lot of long standing bugs. Some work went on to make acceptance tests run on varied browsers via Sauce Labs thanks to @halkeye! The Blue Ocean Pipeline Editor had its Save to SCM/GitHub functionality merged to master branch. It won’t be released to the Update Center until the next Blue Ocean release, there are a few more things to iron out. As the Blue Ocean Pipeline Editor is now considered to be part of Blue Ocean now, more people are kicking the tires, and starting to contribute fixes to improve it! The swishy "Blue Ocean" logo is gone, Jenkins branding is back (mixed feelings!) Fixes for concurrent users of input Fixes for handling errors around favoriting of Pipelines and more. Speeding up creation of Multibranch Pipelines via the new "Creation" flow. And of course, a nice pretty screenshot of editing and saving a Multibranch Pipeline with the Blue Ocean Pipeline Editor: Up next for the Blue Ocean project: More consolidation and polish. A first release candidate out the door (!) New, sleeker, favorite card design, possibly a table design too. Also note that there are changelogs maintained and visible on the Blue Ocean plugin page. Enjoy! If you’re interested in helping to make Blue Ocean a great user experience for Jenkins, please join the Blue Ocean development team on Gitter!

We’re counting down the weeks until Blue Ocean 1.0. This week was relatively quiet with a few people away for a few days, and mostly about consolidation. There was a beta late last week, so this week we thought we would let people have a rest from the upgrade treadmill for once. One notable feature that has recently landed is "escaping to Classic" When you see the exit symbol (door with arrow) it will take you to an equivalent page in classic Jenkins (if one exists). You will notice this in a few places in the app now. Some other things that made it to master branch which have not yet been released in a beta: An API to save/branch to GitHub was finished, and tested with "round tripping" with the Editor in some form New compact form of duration reporting (old style was too verbose for most screens) Fixed a bug with input submissions with concurrent browser sessions which was quite a tricky bug to chase down! Only show Admin link when appropriate. Many many bug fixes and polishing. There has also been an uptick in activity on the Gitter channel with an increased number of questions about usage and Pipelines. But also questions from people starting to extend, or add features, to Blue Ocean, which is very nice to see. Gavin Mogan has been looking at integrating the Sauce OnDemand plugin into Blue Ocean for better browser-test reporting. Tangentially related, we also are planning to improve browser-testing in Blue Ocean as well. What is perhaps more exciting is that more people, like Paul Dragoonis and other folks, are starting to contribute some fixes which have been lingering around for a while. Up Next: Round trip Blue Ocean Pipeline Editor changes with load/save Bundling the Blue Ocean Pipeline Editor with the "aggregator" Blue Ocean plugin. Some release candidates! Enjoy! If you’re interested in helping to make Blue Ocean a great user experience for Jenkins, please join the Blue Ocean development team on Gitter!

We’re counting down the weeks until Blue Ocean 1.0. In all the excitement I forgot to post a dev log last week, so I will make up for it this week. In the last 10 days, 2 betas went out: b22 and b23, and a preview release of the editor. We expect the next release will be named a release candidate (we know there is still more to go in, but want to signal that things are getting into the final stages!). The Gitter chat room is getting busier, so join in! Also last week, the Blue Ocean Pipeline Editor was presented at the Jenkins Online Meetup, embedded below. Feature Highlights You can now create Pipelines from GitHub in Blue Ocean. Either one Pipeline at a time, or let it discover all your Pipelines for a GitHub Organization. When you press the "Create" button, it will open the new creation flow by default now; the feature was previously hidden behind a feature switch. You can filter the activity screen by branch! That way you can see a history of Pipeline runs for just one branch. If you like long names for stages - it now won’t pollute the screen when space is at a premium (truncated names on screen). Blue Ocean events ( SSE) should now work on Microsoft Edge again You can see durations when you hover the mouse over indicators Up next: A release candidate is expected soon Integration work with the Editor to save to branches Some updates to the design around tables Bundling of the Editor with Blue Ocean Don’t forget, there is also a Blue Ocean Docker image published weekly with usually the latest released version. If you have Docker installed, this can be as simple as: docker run -p 8080:8080 jenkinsci/blueocean* Then browse to localhost:8080/blue - possibly the quickest way to try things. Enjoy! If you’re interested in helping to make Blue Ocean a great user experience for Jenkins, please join the Blue Ocean development team on Gitter!