Recently some UI improvements around the Manage Jenkins page have been introduced. The visual changes are very subtle but behind them, there are interesting benefits.

Some of the goals that we have tried to achieve:

In order to provide a quick overview of the visual changes, let’s take a look at these screenshots.

Let’s use a real example for showing how this proposal works.

This is the original UI implementation of HudsonHomeDiskUsageMonitor.java:

And this is the proposed change:

Some highlights:

All administrative monitors defined in Jenkins core have been adapted as part of this proposal.

No changes are really needed, but we do recommend you to adapt your plugins to this proposal so Jenkins users have a better user experience.

Taking into account that you want to keep backward compatibility, you will need some changes.

In your implementation of Administrative Monitor, add this helper method:

In your view (a.k.a. Jelly file or Groovy file):

If you don’t want to keep a strict backward compatibility, the impact is minimal. In fact, you can see an example on GitHub Plugin.

Some helpful references:

Do not hesitate to ping me if you decide to adapt your Administrative Monitors.

The Hackfest will start at 9:30am on Monday with general introductions and gathering of potential topics/projects. Bring suggestions for topics that interest you, or just come and choose from the topics others suggest. There will be plenty of topics from which to choose. All the topic suggestions will all be added to a backlog and we will identify and cluster around popular topics. Then we’ll divide into smaller groups and work on individual topics in timeboxed sessions.

Meals, snacks, and beverages will be provided throughout the day, wrapping up with dinner around 5pm.

Hackfests like this one are a great opportunity for contributors of all levels to get invovled, learn from each other, and work together on interesting and high impact areas of the project.

Some long-time contributors already know what areas they’ll work on and are looking for people interested in joining them. Mark Waite (maintainer of the Jenkins Git and Git Client plugins) and Christian Halstrick (SAP) will be spending the day improving the way Git client plugin uses JGit. R. Tyler Croy (Jenkins community concierge) and Olivier Vernin (Jenkins infrastructure engineer) will work on infrastructure improvements.

Others contributors, such as Jesse Glick and Andrew Bayer (recipients of the "A Small Matter of Programming" award), will arrive without a set plan. They will, of course, have some topics to propose, so you might get a chance to work with them. Or if you have an area you’d like to work on, they and many other experts will be on hand for discussion and code review.

This is also a great opportunity for new contributors to join the project. Baptiste Mathus, long time contributor and all-around nice guy, will host a "New Contributor Hackergarten" covering the basics of contributing to Jenkins and submitting fixes via GitHub Pull requests. Even those with minimal coding experience can contribute by improving documentation and making typo fixes via this same process.

More than anything else, Hackfests like this are great fun. No matter what your level of exerience, there will be plenty to do and great people with whom to do it. Reserve a space byjoining the meetup here. Then bring your own laptop and passion for improving Jenkins.

Meals, snacks, and beverages will be provided. Bring your own computer.

See Information for students for application guidelines.

First step is to join discussions in the mailing lists in order to introduce yourself, establish connections with the community and potential mentors. The application period starts on March 12 and ends on March 27, but don’t let it misguide you! Use time before application to discuss project ideas/proposals with mentors and to process their feedback. To create a better proposal, we also recommend to study Jenkins and to do some contributions in the area of your project proposal.

Not satisfied by the current project ideas? You can propose your own idea in the developer mailing list.

It’s not! If you are passionate about open-source and Jenkins, we invite you to join the mentors team. You can either propose a new project idea or join an existing one. See Call for Mentors and Information for mentors for details.

This year mentorship does NOT require strong expertise in Jenkins development. The objective is to guide students and to get involved into the Jenkins community. GSoC org admins will help to find advisers if special expertise is required.

See the GSoC Timeline for more info. In the Jenkins project we will also organize special events during and after GSoC (e.g. at Jenkins world).

P.S: I am going to create a special GSoC 2018 edition of swags for mentors and students. Do not miss them ;)

Today we’re announcing the first major results of "Project Cheetah", our long-running effort to address these challenges and improve Pipeline scalability. More broadly, Cheetah aims to help in 3 places:

These changes are implemented across many of the Pipeline plugins.

Project Cheetah offers several things, but the most important is Durability Settings for all Pipelines, and especially the Performance-Optimized setting. This setting avoids several potentially unexpected performance "surprises" that may strike users. In the general case, it greatly reduces the disk IO needs for Pipeline. How much? Below is a graph of storage utilization with legacy Pipeline versions (think early 2017) and with the latest version using the Performance-Optimized mode. These are tested on an AWS instance backed by an EBS volume provisioned with 300 IOPs.

Before and After:

As you can see, storage utilization goes down by a lot. While the exact number will vary, across the benchmark testcases this results in Pipeline throughput of 2x to 6x the previous before becoming IO-bound. This also increases stability of Jenkins masters because they will tolerate unexpected load.

This comes with a major drop in CPU IOWait as well:

And of course the rate at which data is written to disk and number of writes/s is also reduced:

For enterprise users, timing stats often show 10-20% of normal builds is serializing the Program and writing the record of steps run ("FlowNodes") - the performance optimized durability setting will cut this to almost nothing (for standard pipelines, 1/100 or less) - so builds will complete faster, especially complex ones.

Please see the Pipeline Scalability documentation for deeper information on the new Durability Settings, how to use them, and which plugin versions are required to gain these features.

Also, users may see a reduction in hung Pipelines because new test utilities made it possible to identify and correct a variety of bugs.

There are 3 ways to configure the durability setting:

That’s probably material for another blog post or Jenkins World talk.

The short answer is: first we built a tool to simulate a full production environment and provide detailed metrics collection at scale. Then we profiled Jenkins to identify bottlenecks and attacked them. Rinse and repeat.

The next big change, which I’m calling Cheetah Part 2 is to address Pipeline’s logging. For every Step run, Pipeline writes one or more small log files. These log files are then copied into the build log content, but are retained to make it possible to easily fetch logs for each step.

This copying process means every log line is written twice, greatly reducing perforance, and writing to many small files is orders of magnitude slower than appending to one big log file.

We’re going to remove this duplication and data fragmentation and use a more efficient mechanism to find per-step logs. This should further improve the ability to run Pipelines on NFS mounts and hard-drive-backed storage, and should significantly improve performance at scale.

Besides this, there’s a variety of different tactical improvements to improve scaling behavior and reduce resource needs.

The Project Cheetah work doesn’t free users to completely ignorePipeline scaling best practices and previous suggestions. Nor does it eliminate the need for efficient GC settings. But this and other enhancements from the last year can significantly improve the storage situation for most users and reduce the penalties for worst-case behaviors. When you add all the pieces together, the result is a faster, leaner, more reliable Pipeline experience.

Let’s now compare our previous results with the same time period from statcounter who argues to collect data from 2million websites. Statcounter allow us to display browsers stats based on 4 different categories, All platform, Desktop, Tablet or Mobile. + For this comparison, I am interested by All platform and of course Desktop as 92.28% of Jenkins.io visitors use a desktop.

Excepted Chrome who still leads the ranking with "only" 54%, all the others actors are totally shuffled. Safari moved to the 2nd place with 14.50% UC Browser appeared in the top 3 with 8.25% where only 0.10% of Jenkins.io visitors were using UC browser. Firefox moved to the 4th places with only 6.15%. It’s interesting how this "All platform" browser market share from statcounter doesn’t reflect Jenkins.io visitors' habits. (Source)

Now at a first glance, results look more similar to the Jenkins.io visitors; excepted for Chrome and Firefox which shed some percentages in favor of Internet Explorer and Edge. This promotes IE to the 3rd place with 8.86% of usage, and downgrade Safari to the 4th place with 6,44%. Compared to Jenkins.io results, Edge is still at the 5th position. It’s very interesting to see how this ranking is so different from the "All platform" one but follows the same pattern coming from Jenkins.io visitors. This highlights how browser choices are strongly influenced by the platform used and contrary to a general trend, Jenkins.io visitors remain desktop users. This absence of mobile users probably explains why some browsers are so under represented within Jenkins visitors. (Source)

These observations should be carefully interpreted as it may be overestimated or underestimated (depending on various factors) and doesn’t take into consideration local specificities.

Jenkins.io visitors are a majority of desktop users. They are aligned with the world trends when we talk about desktop browsers however only a minority of them come from a mobile. This is probably because jenkins.io is not (yet) mobile friendly and obsiously this would be a nice improvement to have.

All contributions are welcomed and especially for mobile user experience.

For many years Jenkins used to specifically blacklist certain classes and packages according to known or suspected exploits. This approach has been proven unsustainable due to the risk of deserialization attacks via unknown classes from 3rd-party components, after theSECURITY-429/CVE-2017-1000353 fix in 2.46.2 it was decided to replace blacklists by more restrictive whitelists. In October 2017 Jesse Glick proposed a Jenkins Enhancement Proposal, which finally got accepted as JEP-200.

The change implies a risk of regressions in plugins serializing non-whitelisted Java-internal and 3rd-party classes, and that’s why it is so important to follow the upgrade guidelines for this release.

JEP-200 was first integrated in Jenkins 2.102 (released in January 2018), and it has got a lot of testing since that. See this blogpost for the original announcement.

Over the last two months we received more than 75 issues from users of Jenkins weekly releases. All these issues have been triaged, and we have released most of the fixes. More than 50 plugins were fixed in total, and many more plugins were updated in order to enable compatibility testing. A significant part of the discovered regressions were caused by real defects which were causing performance and stability issues in plugins. Thanks a lot to all the Jenkins contributors and plugin maintainers who helped deliver timely changes for this effort!

Over last 6 weeks Jenkins weekly releases had positive community ratings, the overall JEP-200 adoption reached ~12% of all Jenkins installations on March 01. All major plugins have been also tested directly or verified in the wild on weekly releases. So we are confident that the change is ready to be released in LTS.

On the other hand, we continue to receive JEP-200 regression reports. They are mostly caused by niche plugins which are not widely used in weekly releases, and unfortunately not all fixes have been released yet (see the Wiki page for up-to-date info). We anticipate more regressions to be reported after the LTS release and broader adoption.

In order to simplify the upgrade to the new LTS baseline, I have prepared some helpful materials together with Liam Newman and Jesse Glick. Below you can find the embedded slide deck and video, or scroll down to see the key information in the text form.

Video:

Upgrading to a core with JEP-200 requires a special update procedure, which is described below.

If you are a plugin developer, please see the original JEP-200 announcement. That blog post provides guidelines for testing and fixing plugin compatibility after the JEP-200 changes. The presentation above also provides some information about what needs to be tested.

The last few years have seen massive changes in the software industry:

All of this adds up to an increased demand for teams to have a solution for cloud native CI/CD with lots of automation!

Jenkins X is a project which rethinks how developers should interact with CI/CD in the cloud with a focus on making development teams productive through automation, tooling and DevOps best practices.

Jenkins X is open source and we invite you to give us feedback and to contribute to the project.

Here’s a demonstration of Jenkins X running on GKE:

You can check out more demos here.

Now lets walk through the features of Jenkins X that we showed in the demo:

Hopefully you now want to give Jenkins X a try. One of the great features of Jenkins is that it’s super easy to get started: install Java, download a war and run via java -jar jenkins.war.

With Jenkins X we’ve tried to follow a similarly simple experience. One complication is that Jenkins X has more moving pieces than a single JVM; it also needs a Kubernetes cluster :)

First you need to download and install the jx command line tool so its on your PATH.

Then you need to run a single command to create a new Kubernetes cluster and install Jenkins X (in this example, on GKE).

Today we support creating Kubernetes clusters and installing Jenkins X on Amazon (AWS), Google (GKE), Microsoft Azure, and even locally using minikube. We plan to support AWS EKS soon.

At the time of this writing the easiest cloud to get started with is Google’s GKE so we recommend you start there unless you already use AWS or Azure. Amazon and Microsoft are working hard to make Kubernetes clusters as easy to create and manage as they are on GKE.

All the public clouds have a free tier so you should be able to spin up a Kubernetes cluster and install Jenkins X for a few hours then tear it down and it should be cheaper than a cup of coffee (probably free!). Just remember to tear down the cluster when you are done!

Here’s a demo of creating a kuberentes cluster and installing Jenkins X:

If you really don’t want to use the public cloud, you can install Jenkins X on an existing kubernetes cluster (if it has RBAC enabled!). Or, if you can install and run minikube, then you should be able to install Jenkins X on it as well.

Jenkins is the core CI/CD engine within Jenkins X. So Jenkins X is built on the massive shoulders of Jenkins and its awesome community.

We are proposing Jenkins X as a sub project within the Jenkins foundation as Jenkins X has a different focus: automating CI/CD for the cloud using Jenkins plus other open source tools like Kubernetes, Helm, Git, Nexus/Artifactory etc.

Over time we are hoping Jenkins X can help drive some changes in Jenkins itself to become more cloud native, which will benefit the wider Jenkins community in addition to Jenkins X.

So I hope the above has given you a feel for the vision of where we are heading with Jenkins X and to show where we are today. The project is still very young, we have lots to do and we are looking for more input on where to go next and what to focus on. We’re also working on high level roadmap.

To make Jenkins X a success we’d love you to get involved, try it out and give us feedback in the community! We love contributions whether its email, chat, issues or even better Pull Requests ;).

If you’re thinking of contributing here’s some ideas:

To help get faster feedback we are using Jenkins X as the CI/CD platform to develop Jenkins X itself. For example Jenkins X creates all the releases and release notes. We’ll talk more about UpdateBot in a future blog post but you can see all the automated pull requests generated in the various Jenkins X pipelines via UpdateBot pushing version changes from upstream dependencies into downstream repositories.

Note that the Jenkins community tends to use IRC for chat and the Kubernetes community uses Slack, so Jenkins X has rooms for both IRC and slack depending on which chat technology you prefer - as the Jenkins X community will be working closely with both the Jenkins community and the various Kubernetes communities (Kubernetes, Helm, Skaffold, Istio et al).

One of the most rewarding things about open source is being able to learn from others in the community. So I’m hoping that even if you are not yet ready to use Kubernetes in your day job or are not yet interested in automating your Continuous Delivery - that you’ll at least consider taking a look at Jenkins X, if for no other reason than to help you learn more about all these new ideas, technologies and approaches!

Thanks for listening and I’m looking forward to seeing you in the community.

A few months ago I preparedthis presentation for theFOSDEM 2018 Jenkins Contributor Summit, which outlines the following "pillars" or Jenkins Essentials, which are also described inJEP-300:

Suffice it to say, Jenkins Essentials is a hugely ambitious project! We have been making steady progress however, as you can see in thejenkins-infra/evergreen repository on GitHub. We have been adamantly following theJenkins Enhancement Proposal process, and have been making sure our designs and implementations are clear as we build them. Thus far we’ve written designs and implemented:

Unfortunately we don’t yet have the first parts of the Automatically Updated Distribution working, which means you cannot download Jenkins Essentials today and get started with it. We’re still building the Jenkins-side and server-side components necessary to make the full feedback loop operate, without which we would not be able to safely deliver new upgrades to Jenkins Essentials installations.

If you’re interested in getting involved, you can check out our Gitter channel or ourJira issues board.

Jenkins Essentials is just one major initiative going on in the Jenkins project this year, so I hope you’re as excited as I am for the future of Jenkins!

This is something we’re really happy about - if you go to the "Pipeline Syntax" link from your Pipeline’s page in Jenkins, you’ll see a couple new links on the left, including "Declarative Directive Generator". The Directive Generator is much like the Snippet Generator that’s been in Pipeline for a couple years now, but where the Snippet Generator is just for filling out a form for a step and generating the Pipeline code that configuration maps to, the Directive Generator is built to help you write your Declarative Pipeline directives, like agent, options, stage, and more!

This is the first release to include the Directive Generator, and it’s definitely going to see more polish going forward, but we think it should be quite helpful for you already. We’ll be putting up another blog post looking at the Directive Generator in more detail in the near future.

We’ve added a number of new when conditions, providing you more control over whether your stages get executed.

In addition, we’ve added a new option to when: beforeAgent. This allows you to specify that the when conditions should be evaluated before entering theagent for the stage, rather than the normal behavior of evaluating when conditions after entering the agent. When beforeAgent true is specified, you will not have access to the agent's workspace, but you can avoid unnecessary SCM checkouts and waiting for a valid agent to be available. This can speed up your Pipeline’s execution in some cases.

The changed condition has always been a bit confusing, and to be honest, it wasn’t our best work. changed will fire any time the current run’s status is different than the previous run’s status - whether the current run is healthier than the previous one, or the other way around. That’s…​not actually very useful. So now we’ve added two new post conditions that should provide you with a lot more value than changed has.

The options directive in Declarative can contain a number of different kinds of configuration: traditional Jenkins job properties, like buildDiscarder, wrapper steps to execute the entire Pipeline within, like timeout, and Declarative-specific options that can switch from some default behaviors of Declarative execution. We’ve added two new Declarative-specific options in the last few releases.

Sometimes, you may only want to disable automatic checkout of your repository, using the skipDefaultCheckout(true) option, for one specific stage in your Pipeline. Or perhaps you want to have a timeout that covers an entirestage, including time spent waiting for a valid agent, post condition execution, or the new input directive for stages (see further down for more details on that!). To make those things possible, we’ve added a new options direction to stage. You can use a subset of the top-level options content in a stage's options - wrapper steps, and Declarative-specific options that are marked as legal in a stage.

You’ve always been able to run the input step inside a stage's steps block, but we’ve found that approach can lose out on some of the value that the input step provides.

To help with that, we’ve added a new input directive to stage, with the same parameters as the input step. When you use thestageinput directive rather than using the step directly, any parameters you’ve specified for the input will be made available in the stage's environment, meaning you can reference parameters from the input in when conditions, or in environment variables.

Also, the input directive is evaluated before you enter any agent specified on this stage, so if you are using a top-level agent none and each stage has its own agent specified, you can avoid consuming an executor while waiting for the input to be submitted.

Lastly, you can use timeout in the stageoptions, as mentioned above, to time-out the input if too much time has passed without a response.

I hope you find these new features and options for Declarative Pipelines helpful, and I look forward to the rest of 2018 as we continue to invest and improve in Jenkins Pipeline!

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?):

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:

If something went wrong in production, you can roll back an app to any version (the version numbers are made for you):

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:

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

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:

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 byDraft “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).

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.

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:

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.

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.

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.

Lots, the jx command line has built in help:

jx open

jx activity

jx get environments

jx get apps

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 theJenkins Enhancement Proposal doc.

We automatically install an Nginx ingress controller running with an external loadbalancer pointing at it’s Kubernetes service. We also generate all the Kubernetes Ingress rules using a golang library called "exposecontroller". This runs as a Kubernetes Job triggered by aHelm hook once any application is installed to the cluster. 

Using "exposecontroller" means we can control all the ingress rules for an environment using a single set of configurations, rather than each application needing to know how to expose the kubernetes service to the outside world. This also means we can easily switch between HTTP and HTTPS plus support intregration with projects likecert-manager for auto generation of signed TLS certificates.

One important point to make is Jenkins X aims to use terminology that developers are familiar with. That’s not to say we are changing Kubernetes fundamentals, it’s more that if you don’t know Kubernetes concepts then we aim to help you still adopt the cloud technology and pull back the curtain as you gain confidence and experience. To that point, a core part of Jenkins X are "environments". An environment can have one or more applications running in it. In Kubernetes term an "environment" maps to the concept of a "namespace" in code.

The installation by default created three environments, this is customisable but by default we have a "dev", a "staging" and a "production environment". To list, select, or switch between these environments run:

In the "dev" environment we have installed a number of core applications we believe are required at a minimum to start folks off with CI/CD on Kubernetes. We can easily add to these core apps using Jenkins X addons but for now lets focus on the core apps. Jenkins X comes with configuration that wires these services together, meaning everything works together straight away. This dramatically reduces the time to get started with Kubernetes as all the passwords, environment variables and config files are all setup up to work with each other.

We learned a lot in our early days with fabric8 on Kubernetes and there were some projects from the ecosystem that either weren’t around or (at the time) didn’t work with OpenShift, therefore we were restricted when making some design decisions. A couple of years on and now with Jenkins X we were able to look at other OSS projects that have been flourishing, so I was very happy to start looking at Helm. Helm is a package manager for Kubernetes and allows easy installation and upgrades of applications.

It was pretty clear that for Jenkins to evolve and include deployments to the cloud we should embrace Helm and provide an opinionated experience that helps teams and developers. The core applications mentioned above means Jenkins X provides an out of the box integrated CI/CD solution for Helm.

We know that helm has limitations but with the work onHelm 3, the focus of the Kubernetes sig-apps group, the Kubernetes community and investment we see from key organisations such as Microsoft, we feel Helm is currently the best way to install and upgrade applications on Kubernetes.

We mentioned earlier that we setup three environments by default. What this means is for the staging and production environments we created:

Having a Jenkins Pipeline Job for each environment means that Pull Requests to the git repo trigger a CI job. For now that job performs basic validation but in the future will include ‘gates’ to ensure a change to that environment has passed expected checks such as QA tasks, gain enough approvals from the correct people, etc - YES CI for environments!!

Once CI checks have passed the new application or version change can be merged. Only users that have karma can merge the Pull Request and therefore we get RBAC plus traceability for our environment deployments.

This means every application manifest, their version and configuration including storage requirements, resource needs and secrets for your environments are stored in Git repositories. Given a disaster recovery scenario this is exactly what you want.

Did I just say secrets in Git? Yes! We will be providing a nicer experience to helps folks get set up but we ourselves encrypt our secrets and store them in Git, then decrypt them when we come to install and upgrade.

Here’s our Git repo https://github.com/jenkins-x/cloud-environments/blob/a1edcc6/env-jx-infra/secrets.yaml.

We do all this with the help of a Helm wrapper called helm secrets. I’m working on a followup blog post with examples, better explanations and how to guides + add better integration with JX in the coming weeks.

We mainly hangout in the jenkins-x Kubernetes slack channels and for tips on being more involved with Jenkins X take a look at our contributing docs

If you’ve not already seen it here’s a video showing the create cluster explained in this blog.

Blue Ocean now includes a user interface update to show the downstream jobs launched with the build step (link: JENKINS-38339)

With Blue Ocean 1.5.0, users can now Reorder Steps in the Blue Ocean Pipeline Editor simply by dragging and dropping steps to reorder them in the list of steps. (JENKINS-38323)

The "Artifacts" tab also now supports pagination, which allows developers to paginate through the Artifacts tab. Previously, this list was cut off at 100 entries. (JENKINS-43588)

We were able to include two performance improvements in 1.5.0 which reduce theDashboard loading time in Blue Ocean:

Support for viewing output for failed runs with no stages is also included in this release. For developers who have no stages/steps defined in their pipelines, they can now see the full log output for failed runs. This update helps with Pipeline debugging in Jenkins. (JENKINS-48074)

Further improving the log output for Pipeline Runs, 1.5.0 also improves viewing of long log output lines with wrapping. Previously, a single, long line of output in the log wouldn’t be fully visible in the log window. (JENKINS-49036)

One notable bug fix we addressed in this release was that input steps inpost directives would not properly prompt for input. By fixingJENKINS-49297 users of Declarative Pipeline with Blue Ocean can include input steps in their post directives.

The full detailed change log can be viewed on theBlue Ocean plugin page

Plugin updates in Jenkins are available in the Plugin Manager Update Center. This page includes instructions for using the UI and CLI to update your plugins: https://jenkins.io/doc/book/managing/plugins/.

If you are using the Blue Ocean UI, click Administration in the page’s header to open Plugin Manager.

Installing the primary Blue Ocean plugin will update its dependencies as well.