index.xml

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Jenkins X - Cloud Native CI/CD Built On Kubernetes – Jenkins X - Cloud Native CI/CD Built On Kubernetes</title>
    <link>https://jenkins-x.io/</link>
    <description>Recent content on Jenkins X - Cloud Native CI/CD Built On Kubernetes</description>
    <generator>Hugo -- gohugo.io</generator>
    
	  <atom:link href="https://jenkins-x.io/index.xml" rel="self" type="application/rss+xml" />
    
    
      
      
    
    
    <item>
      <title>Blog: GSoC 2022 Final Report: Improving Supply Chain Security</title>
      <link>https://jenkins-x.io/blog/2022/11/08/gsoc-2022/</link>
      <pubDate>Tue, 08 Nov 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/11/08/gsoc-2022/</guid>
      <description>
        
        
        &lt;h2 id=&#34;project-description&#34;&gt;Project Description&lt;/h2&gt;
&lt;p&gt;Supply chain security is a rising concern in the current software era.
Securing the software supply chain encompasses vulnerability remediation and the implementation of controls throughout the software development process.
Due to massive increase in attacks on software supply chain and the diversity of its &lt;a href=&#34;https://slsa.dev/spec/v0.1/threats&#34;&gt;types&lt;/a&gt;, Jenkins X has to make efforts to ensure that the build process is secure.
As part of securing Jenkins X installation by default I worked on both securing our own components and enabling our users to use these features in their build and release steps..&lt;/p&gt;
&lt;h2 id=&#34;work-done&#34;&gt;Work Done&lt;/h2&gt;
&lt;p&gt;The work done so far covers these four sections.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Enhancing the &lt;code&gt;jx version&lt;/code&gt; output&lt;/li&gt;
&lt;li&gt;Integrating with Tekton Chains to sign TaskRuns and PipelineRuns&lt;/li&gt;
&lt;li&gt;Software Bill of Materials (SBOM)&lt;/li&gt;
&lt;li&gt;Signing Jenkins X artifacts&lt;/li&gt;
&lt;/ol&gt;
&lt;h3 id=&#34;enhancing-the-jx-version-output&#34;&gt;Enhancing the &lt;code&gt;jx version&lt;/code&gt; output&lt;/h3&gt;
&lt;p&gt;Description:&lt;/p&gt;
&lt;p&gt;A first step towards securing Jenkins X supply chain is to increase the amount of information gained from running &lt;code&gt;jx version&lt;/code&gt; command.&lt;/p&gt;
&lt;p&gt;Implementation&lt;/p&gt;
&lt;p&gt;The issue created for this task is &lt;a href=&#34;https://github.com/jenkins-x/jx/issues/8249&#34;&gt;here&lt;/a&gt;.
The PR to fix it is &lt;a href=&#34;https://github.com/jenkins-x/jx/pull/8291&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;h3 id=&#34;integrating-with-tekton-chains-to-sign-taskruns-and-pipelineruns&#34;&gt;Integrating with Tekton Chains to sign TaskRuns and PipelineRuns&lt;/h3&gt;
&lt;p&gt;Description:&lt;/p&gt;
&lt;p&gt;As Jenkins X uses tekton as its pipeline execution engine,&lt;code&gt; TaskRun&lt;/code&gt; and &lt;code&gt; PipelineRun&lt;/code&gt; are considered the key components of Jenkins X pipeline &lt;code&gt;activities&lt;/code&gt; and &lt;code&gt;steps&lt;/code&gt;
Tekton Chains monitors the execution of all &lt;code&gt;TaskRun&lt;/code&gt; and &lt;code&gt; PipelineRun&lt;/code&gt; inside the cluster and takes a snapshot upon completion of each of them to sign with user-provided cryptographic keys and store them on the backend storage.
The payload and signature cn be verified later using &lt;code&gt;cosign verify-blob&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;Implementation&lt;/p&gt;
&lt;p&gt;I used the helm chart developed by &lt;a href=&#34;https://www.chainguard.dev/&#34;&gt;Chainguard&lt;/a&gt; for integrating Chains with Jenkins X.
To integrate the &lt;a href=&#34;https://github.com/chainguard-dev/tekton-helm-charts/tree/main/charts/tekton-chains&#34;&gt;chart&lt;/a&gt; and added support for it on &lt;a href=&#34;https://github.com/jenkins-x/jx3-versions&#34;&gt;jx3-versions&lt;/a&gt; to make installation of helm chart easy for our users.
The list of PRs for this:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;PR&lt;/th&gt;
&lt;th&gt;Short Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx3-versions/pull/3359&#34;&gt;https://github.com/jenkins-x/jx3-versions/pull/3359&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Supporting Tekton Chains helm chart with jx3-versions&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-docs/pull/3660&#34;&gt;https://github.com/jenkins-x/jx-docs/pull/3660&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Documentation on how to install and integrate Tekton Chains with Jenknins X&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;NOTE: The integration is tested only on k3s cluster and work is in progress to test it on GKE and EKS.&lt;/p&gt;
&lt;h3 id=&#34;software-bill-of-materials-sbom&#34;&gt;Software Bill of Materials (SBOM)&lt;/h3&gt;
&lt;p&gt;Description:&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://en.wikipedia.org/wiki/Software_supply_chain#:~:text=Software%20vendors%20often,could%20harm%20them.&#34;&gt;Software Bill Of Materials&lt;/a&gt; (SBOM) is a complete formally structured list of the materials (components, packages, libraries, SDK) used to build (i.e. compile, link) a given piece of software and the supply chain relationships between all these materials.
It is an inventory of all the components developers used to make this software.
It has many formats and many generating tools but all have the same purpose in the end.&lt;/p&gt;
&lt;p&gt;Implementation:&lt;/p&gt;
&lt;p&gt;I first began with investigating available standards and formats for SBOMs and tools for generating them.
The results of my investigation were written to a blog post &lt;a href=&#34;https://jenkins-x.io/blog/2022/07/24/intro-to-sbom/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I&amp;rsquo;ve settled for using &lt;a href=&#34;https://github.com/anchore/syft&#34;&gt;syft&lt;/a&gt; for SBOM generation and &lt;a href=&#34;https://spdx.dev/&#34;&gt;spdx&lt;/a&gt; as the standard format for SBOMs.
Also, I&amp;rsquo;ve added those installation as pre-defined steps in the Jenkins X pipeline catalog so it will also be available for our users to use in their pipelines and applied those steps to Jenkins X own pipelines.
The list of PRs for this work are:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;PR&lt;/th&gt;
&lt;th&gt;Short Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx/pull/8312&#34;&gt;https://github.com/jenkins-x/jx/pull/8312&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Install syft using github action and generate SBOM with goreleaser&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/pull/1166&#34;&gt;https://github.com/jenkins-x/jx3-pipeline-catalog/pull/1166&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Add Syft Installation to JX3 pipeline Catalog so it can be used to generate SBOMs&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/pull/1173&#34;&gt;https://github.com/jenkins-x/jx3-pipeline-catalog/pull/1173&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Add Oras Steps to support pushing SBOMs as OCI artifacts&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-pipeline/pull/490&#34;&gt;https://github.com/jenkins-x-plugins/jx-pipeline/pull/490&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Use Syft installation step in jx-pipeline from jx3-pipelines-catalog&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-pipeline/pull/491&#34;&gt;https://github.com/jenkins-x-plugins/jx-pipeline/pull/491&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Use Oras bushing SBOMs step from jx3-pipeline-catalog&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-docs/pull/3643&#34;&gt;https://github.com/jenkins-x/jx-docs/pull/3643&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Add documentation for supporting sbom generation and storing for other jx components and our users&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx/pull/8351&#34;&gt;https://github.com/jenkins-x/jx/pull/8351&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Applying SBOM management to JX&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/pull/1190&#34;&gt;https://github.com/jenkins-x/jx3-pipeline-catalog/pull/1190&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Add grype tasks for SBOM vulnerability scanning to jx3-pipeline-catalog&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/cdfoundation/presentations/pull/44&#34;&gt;https://github.com/cdfoundation/presentations/pull/44&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Add materials for my talk with the CDF Supply Chain Securtiy SIG about SBOMs with Jenkins X&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;There is also this issue to apply all steps on our active JX repositories &lt;a href=&#34;https://github.com/jenkins-x/jx/issues/8348&#34;&gt;here&lt;/a&gt; (WIP as there are many repositories to be updated) and the list of PRs are referenced in the issue (except those of JX because they included testing and fixing PRs at the beginning).&lt;/p&gt;
&lt;h3 id=&#34;signing-jenkins-x-artifacts&#34;&gt;Signing Jenkins X artifacts&lt;/h3&gt;
&lt;p&gt;Description:&lt;/p&gt;
&lt;p&gt;Jenkins X is a collection of many components and tools that are used to provide the end-to-end CI/CD solution.
Those components are used by our users and are also used by Jenkins X itself.
It is important to sign those components to ensure the integrity of the components and the supply chain security of Jenkins X.&lt;/p&gt;
&lt;p&gt;Implementation:&lt;/p&gt;
&lt;p&gt;There are a set of tools developed by &lt;a href=&#34;https://sigstore.dev/&#34;&gt;sigstore&lt;/a&gt; to sign and verify artifacts.
The most used tool in my implementation is &lt;a href=&#34;https://github.com/sigstore/cosign&#34;&gt;cosign&lt;/a&gt;.
I first started with signing the Jenkins X CLI with keys stored in github secrets and then moved to signing the Jenkins X docker images.
After that, I switched to use cosign &lt;a href=&#34;https://github.com/sigstore/cosign/blob/main/KEYLESS.md&#34;&gt;keyless signing&lt;/a&gt; (an experimental feature using other Sigstore components (rekor and fulcio) to save end users from the hassles of key (mis)management ) The list of PRs for this work are:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;PR&lt;/th&gt;
&lt;th&gt;Short Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx/pull/8432&#34;&gt;https://github.com/jenkins-x/jx/pull/8432&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Sign goreleaser artifacts with cosign&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx/pull/8441&#34;&gt;https://github.com/jenkins-x/jx/pull/8441&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Sign published images with cosign&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx/pull/8461&#34;&gt;https://github.com/jenkins-x/jx/pull/8461&lt;/a&gt;&lt;/td&gt;
&lt;td&gt;Keyless signing for goreleaser artifacts&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h2 id=&#34;whats-next&#34;&gt;What&amp;rsquo;s next?&lt;/h2&gt;
&lt;p&gt;The work for supply chain security is still in progress and there are many things to be done.
At Jenkins X, we are planning to develop new features and integrate more solutions to provide a better supply chain security for our users.
The list of things to be done are:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Add a cli subcommand in JX to verify sbom/signed binaries against the public keys.&lt;/li&gt;
&lt;li&gt;Add &lt;a href=&#34;https://github.com/ossf/scorecard&#34;&gt;openSSF security scorecard&lt;/a&gt; to Jenkins X repositories.&lt;/li&gt;
&lt;li&gt;Integrate &lt;a href=&#34;https://buildsec.github.io/frsca/&#34;&gt;FRSCA&lt;/a&gt; work with Jenkins X.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;acknowledgements&#34;&gt;Acknowledgements&lt;/h2&gt;
&lt;p&gt;Out of all internships and trainings I&amp;rsquo;ve done, this one was the most challenging, rewarding and educational experience. I would like to specially thank my mentor &lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit Mohapatra&lt;/a&gt; for his constant support and his patience to teach me a lot of his rich knowledge he gained by experience and thank the whole team of Jenkins X for their support and guidance and for welcoming me to the community. This internship was a great experience. I had a great time working on this project and I learned a lot from it. I hope to continue contributing to Jenkins X and the open-source community in the future. Thank you.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Software Bill Of Materials generation tools</title>
      <link>https://jenkins-x.io/blog/2022/07/24/sbom-tools/</link>
      <pubDate>Sun, 24 Jul 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/07/24/sbom-tools/</guid>
      <description>
        
        
        &lt;h2 id=&#34;prerequisite&#34;&gt;Prerequisite&lt;/h2&gt;
&lt;p&gt;Before you read this, you have to understand &lt;a href=&#34;https://jenkins-x.io/blog/2022/07/24/intro-to-sbom&#34;&gt;what are SBOMs&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/blog/2022/07/24/sbom-formats&#34;&gt;what are different formats of SBOMs&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;different-sbom-generation-tools-comparison&#34;&gt;Different SBOM generation tools comparison&lt;/h2&gt;
&lt;p&gt;If you got this far, you already realize the importance of SBOM generation, and also it should meet certain requirements to achieve its purpose. Due to various requirements depending on what standard you&amp;rsquo;re following, there has to be a way to automatically generate different output formats for different standards. Also, it has to be suited for ci/cd solutions to keep up with the increasing number of releases for each organization.&lt;/p&gt;
&lt;p&gt;Note: Here we&amp;rsquo;re only considering open source tools&lt;/p&gt;
&lt;h3 id=&#34;1---anchore-syft&#34;&gt;1 - Anchore Syft&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Introduction:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://anchore.com/&#34;&gt;Anchore&lt;/a&gt;is a platform that implements sbom-powered supply chain security solutions for developers and enterprises. For generating SBOMs, a CLI tool and library named &lt;a href=&#34;https://github.com/anchore/syft&#34;&gt;Syft&lt;/a&gt; was developed by Anchore that could be injected into your ci/cd pipeline to generate SBOMs from container images and filesystems at each step.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Integration and Support:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Syft is supported on Linux, Mac, and Windows and it can run as a docker container which makes it a great suit for CI systems. Other than the 3 SBOM standards, Syft can generate its JSON standard format to be input for other Anchore tools like &lt;a href=&#34;https://github.com/anchore/grype/&#34;&gt;Grype&lt;/a&gt; which is a vulnerability scanner for container images and filesystems. It supports projects based on the following package managers:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Alpine (apk)&lt;/li&gt;
&lt;li&gt;C (conan)&lt;/li&gt;
&lt;li&gt;C++ (conan)&lt;/li&gt;
&lt;li&gt;Dart (pubs)&lt;/li&gt;
&lt;li&gt;Debian (dpkg)&lt;/li&gt;
&lt;li&gt;Dotnet (deps.json)&lt;/li&gt;
&lt;li&gt;Objective-C (cocoapods)&lt;/li&gt;
&lt;li&gt;Go (go.mod, Go binaries)&lt;/li&gt;
&lt;li&gt;Haskell (cabal, stack)&lt;/li&gt;
&lt;li&gt;Java (jar, ear, war, par, sar)&lt;/li&gt;
&lt;li&gt;JavaScript (npm, yarn)&lt;/li&gt;
&lt;li&gt;Jenkins Plugins (jpi, hpi)&lt;/li&gt;
&lt;li&gt;PHP (composer)&lt;/li&gt;
&lt;li&gt;Python (wheel, egg, poetry, requirements.txt)&lt;/li&gt;
&lt;li&gt;Red Hat (rpm)&lt;/li&gt;
&lt;li&gt;Ruby (gem)&lt;/li&gt;
&lt;li&gt;Rust (cargo.lock)&lt;/li&gt;
&lt;li&gt;Swift (cocoapods)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Features and Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Easy to use
&lt;ul&gt;
&lt;li&gt;Syft can generate a simple basic sbom by just running &lt;code&gt;syft &amp;lt;image&amp;gt;&lt;/code&gt; this will only include the softwares included in the image&amp;rsquo;s final layer. Or &lt;code&gt;syft &amp;lt;image&amp;gt; --scope all-layers&lt;/code&gt; for more verbose sbom to include all image layers&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Different formats support the ability to convert between them.
&lt;ul&gt;
&lt;li&gt;Syft JSON&lt;/li&gt;
&lt;li&gt;SPDX 2.2 JSON&lt;/li&gt;
&lt;li&gt;SPDX 2.2 tag-value&lt;/li&gt;
&lt;li&gt;CycloneDX 1.4 JSON&lt;/li&gt;
&lt;li&gt;CycloneDX 1.4 XML&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Cryptographically sign and attest SBOMs
&lt;ul&gt;
&lt;li&gt;Syft uses &lt;a href=&#34;https://github.com/in-toto/attestation&#34;&gt;in-toto attestations&lt;/a&gt; with &lt;code&gt;syft attest&lt;/code&gt; command and the digital signature management is integrated with sigstore cosign. You can view more &lt;a href=&#34;https://anchore.com/sbom/creating-sbom-attestations-using-syft-and-sigstore/&#34;&gt;here&lt;/a&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Support a variety of sources to generate SBOMs from
&lt;ul&gt;
&lt;li&gt;OCI and docker image formats &lt;code&gt;syft &amp;lt;image&amp;gt;&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Container images archives &lt;code&gt;syft path/to/image.tar&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;Filesystems and local directories &lt;code&gt;syft path/to/dir&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;For more resources about Syft capabilities refer to the &lt;a href=&#34;https://github.com/anchore/syft&#34;&gt;source repo&lt;/a&gt; and &lt;a href=&#34;https://anchore.com/sbom/how-to-generate-an-sbom-with-free-open-source-tools/&#34;&gt;official documentation&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&#34;2--opensboms-spdx-sbom-generator&#34;&gt;2- Opensbom&amp;rsquo;s Spdx-Sbom-Generator&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Introduction:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/opensbom-generator&#34;&gt;Opensbom-Generator&lt;/a&gt; is an open source project initiated by the Linux Foundation SPDX workgroup to generate SBOMs using CLI tools. Currently, they support the standard spdx 2.2 formats and JSON with their &lt;a href=&#34;https://github.com/opensbom-generator/spdx-sbom-generator&#34;&gt;spdx-sbom-generator&lt;/a&gt; tool based on golang. It can only be used to generate SBOMs from a repository containing package files (no container images or archives support yet). They aim to provide SBOM generation support in ci/cd solutions.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Integration and Support:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;You can download the binaries and install the tool on your system. The available binaries to install are for Linux, Windows, and macOS and it can also be used as a docker container from this spdx &lt;a href=&#34;https://hub.docker.com/r/spdx/spdx-sbom-generator&#34;&gt;repo&lt;/a&gt;. It can detect which package managers or build systems are being used by the software. It is supporting the following package managers:&lt;/p&gt;
&lt;p&gt;&lt;code&gt;GoMod (go), Cargo (Rust), Composer (PHP), DotNet (.NET), Maven (Java), NPM (Node.js), Yarn (Node.js), PIP (Python), Pipenv (Python), Gems (Ruby), Swift Package Manager (Swift)&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Features and Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;CLI easy to use and simple interface&lt;/li&gt;
&lt;li&gt;Automatic detection of the package manager&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;3--kubernetes-bom&#34;&gt;3- Kubernetes BOM&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Introduction:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/kubernetes-sigs/bom&#34;&gt;BOM&lt;/a&gt; is a general-purpose CLI tool developed by &lt;a href=&#34;https://github.com/kubernetes-sigs&#34;&gt;kubernetes-sigs&lt;/a&gt; (Special Interest Groups) that can generate SBOMs from directories, container images, single files, and other sources. The utility has a built-in license classifier that can check for license compliance of your packages with around 400+ licenses in the &lt;a href=&#34;https://spdx.org/licenses/&#34;&gt;SPDX catalog.&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Integration and Support:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;BOM is supported as a Golang package that can be installed on any system having to go with &lt;code&gt;go install sigs.k8s.io/bom/cmd/bom&lt;/code&gt; this adds the support for Linux, Mac, and Windows. It is compatible with creating SBOMs from files, images, and docker archives (images in tarballs). It also supports pulling images from remote container registries for analysis. BOM is mainly generating SBOMs in SPDX formats.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Features and Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;CLI usage to support CI/CD solutions&lt;/li&gt;
&lt;li&gt;Golang dependency analysis&lt;/li&gt;
&lt;li&gt;Full &lt;code&gt;.gitignore&lt;/code&gt; support when scanning git repositories&lt;/li&gt;
&lt;li&gt;Ability to check for license compliance with SPDX catalog&lt;/li&gt;
&lt;li&gt;Support for different sources to generate sboms&lt;/li&gt;
&lt;li&gt;Other than the command &lt;code&gt;bom generate&lt;/code&gt;, it uses &lt;code&gt;bom document&lt;/code&gt; to work with already present SPDX documents to outline and draw a structure for them&lt;/li&gt;
&lt;li&gt;It doesn&amp;rsquo;t necessarily require a whole project directory but it can specify a single file to analyze with the &lt;code&gt;-f path/to/file&lt;/code&gt; flag and it can have a collection of those files to be analyzed together.&lt;/li&gt;
&lt;li&gt;It also supports the namespacing separation between SBOM documents using the &lt;code&gt;-n &amp;lt;URI&amp;gt;&lt;/code&gt; flag to isolate each document from the other&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;4--microsoft-sbom-tool&#34;&gt;4- Microsoft SBOM tool&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Introduction:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Recently, Microsoft open-sourced their SBOM generation tool which is described as a general purpose, enterprise-proven, build-time SBOM generator. They have been developing the tool internally since 2019 and tuning its feature according to their needs and providing other companies with the solution. What is new is that Microsoft has chosen to merge efforts with the Linux Foundation&amp;rsquo;s work and use &lt;a href=&#34;https://spdx.dev/&#34;&gt;Software Package Data Exchange (SPDX)&lt;/a&gt; for all SBOMs generated, and to do this for all software produced. It has a promising number of features like including other SBOM documents recursively to provide its users with the ability to have a full dependency tree that goes to the origin of every package.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Integration and Support:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Microsoft SBOM is supported on Linux, macOS, and Windows. It can be easily integrated into and auto-detects the following package managers&lt;/p&gt;
&lt;p&gt;&lt;code&gt;NPM, NuGet, PyPI, CocoaPods, Maven, Golang, Rust Crates, RubyGems, Linux packages within containers, Gradle, Ivy, GitHub public repositories&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;and Microsoft is adding more detectors to improve deeper integration with the community. The tool is currently committed to generating the SPDX 2.2.1 format for its users and is still in development to include all optional fields before integrating with other formats.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Features and Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Enterprise ready and highly scalable as already used at scale by Microsoft&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Adding build provenance information to the SBOM&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Auto-detection of the underlying package manager&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Supports namespacing separation between SBOM documents with the &lt;code&gt;-nsb&lt;/code&gt; flag&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Validating SBOMs at release using hashes and digital signatures&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/sbom-guide/microsoft-sbom.png&#34; alt=&#34;img&#34;&gt;&lt;/p&gt;
&lt;p&gt;Fig 1: &lt;a href=&#34;https://devblogs.microsoft.com/engineering-at-microsoft/wp-content/uploads/sites/72/2021/10/adiglio-figure-1.png&#34;&gt;https://devblogs.microsoft.com/engineering-at-microsoft/wp-content/uploads/sites/72/2021/10/adiglio-figure-1.png&lt;/a&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;For more information about the tool visit the GitHub &lt;a href=&#34;https://github.com/microsoft/sbom-tool&#34;&gt;repo&lt;/a&gt;and refer to the documentation &lt;a href=&#34;https://github.com/microsoft/sbom-tool/tree/main/docs&#34;&gt;here&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&#34;5--tern&#34;&gt;5- Tern&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Introduction:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/tern-tools/tern&#34;&gt;Tern&lt;/a&gt; is a VMware-originated open source inspection tool used to generate SBOMs following standard formats. It gathers metadata for the packages installed in container images and Dockerfiles. Tern starts to analyze the contents of a container (through the image itself or the Dockerfile), layer by layer, without requiring the user to have in-depth technical knowledge about how the container was built.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Integration and Support:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Tern itself is available as a &lt;a href=&#34;https://github.com/marketplace/actions/tern-action&#34;&gt;Github Action&lt;/a&gt; but it is mainly supported to be installed as a CLI tool on Linux. With Linux installation, Tern is built with python so it requires python, pip, and jq installed mainly (more about installation &lt;a href=&#34;https://github.com/tern-tools/tern#getting-started&#34;&gt;here&lt;/a&gt;). Some features like analyzing Dockerfiles and the &lt;a href=&#34;https://automatecompliance.org/news/2020/04/23/tern-2-0-0-now-available/&#34;&gt;lock function&lt;/a&gt; require Docker installation in your Linux. Moreover, Tern can run as a docker container which makes it easy to use in ci systems and can be used as a workaround to run on other operating systems like Windows, and macOS. Also, this helps to deploy Tern as a Kubernetes job with a host mount to retrieve generated SBOMs.&lt;/p&gt;
&lt;p&gt;For now, Tern only supports container images built using Docker using &lt;a href=&#34;https://docs.docker.com/registry/spec/manifest-v2-2/&#34;&gt;image manifest version 2, schema 2&lt;/a&gt; and it will support Docker images and it is aimed to support other images that follow the OCI standards in the future.&lt;/p&gt;
&lt;p&gt;For license compliance, Term doesn&amp;rsquo;t have its file-level license analyzer. So, it allows you to extend its analysis using an external CLI tool or Python packages as extensions. An example is &lt;a href=&#34;https://github.com/tern-tools/tern#scancode&#34;&gt;Scancode&lt;/a&gt; which is a CLI tool used for license compliance along with other supported integrations like &lt;a href=&#34;https://github.com/tern-tools/tern#cve-bin-tool&#34;&gt;cve-bin-tool&lt;/a&gt; for vulnerability scanning.&lt;/p&gt;
&lt;p&gt;Tern supports generating reports with multiple formats:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Human Readable Simple format&lt;/li&gt;
&lt;li&gt;JSON format&lt;/li&gt;
&lt;li&gt;HTML format&lt;/li&gt;
&lt;li&gt;YAML format&lt;/li&gt;
&lt;li&gt;SPDX tag-value Format&lt;/li&gt;
&lt;li&gt;SPDX JSON Format&lt;/li&gt;
&lt;li&gt;CycloneDX JSON Format&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Features and Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;CLI is easy to use and can be installed as a docker container which makes it suitable for CI/CD solutions&lt;/li&gt;
&lt;li&gt;Multiple supported output formats which are readable for both humans and machines&lt;/li&gt;
&lt;li&gt;Ability to generate SBOMs following both SPDX and CycloneDX formats&lt;/li&gt;
&lt;li&gt;Support for Dockerfile locking to create more reproducible Docker images which is a unique feature supported by Tern only, view more about it &lt;a href=&#34;https://automatecompliance.org/news/2020/04/23/tern-2-0-0-now-available/&#34;&gt;here&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;The concept of extensions/plugins is only supported by Tern between all the previously mentioned tools. This is a great feature that is proven to extend its capabilities in the coming future and open for creativity from the open source community (this was proven before to increase the functionality and popularity of other tools like Jenkins).&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;For more information about the tool visit the GitHub &lt;a href=&#34;https://github.com/tern-tools/tern&#34;&gt;repo&lt;/a&gt; and refer to the documentation &lt;a href=&#34;https://github.com/tern-tools/tern/tree/main/docs&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Software Bill Of Materials Formats</title>
      <link>https://jenkins-x.io/blog/2022/07/24/sbom-formats/</link>
      <pubDate>Sun, 24 Jul 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/07/24/sbom-formats/</guid>
      <description>
        
        
        &lt;h2 id=&#34;prerequisite&#34;&gt;Prerequisite&lt;/h2&gt;
&lt;p&gt;If you don&amp;rsquo;t understand what is Software Bill of Materials (SBOM), please read this &lt;a href=&#34;https://jenkins-x.io/blog/2022/07/24/intro-to-sbom&#34;&gt;blog post&lt;/a&gt; first.&lt;/p&gt;
&lt;h2 id=&#34;different-sbom-formats-comparison&#34;&gt;Different SBOM formats comparison&lt;/h2&gt;
&lt;p&gt;The National Telecommunications and Information Administration (NTIA) in the U.S. defined &lt;a href=&#34;https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom&#34;&gt;minimum requirements for SBOM formats&lt;/a&gt;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Identifying the supplier of the software component.&lt;/li&gt;
&lt;li&gt;Identifying the details about the version of the component.&lt;/li&gt;
&lt;li&gt;Including unique identifiers for the component like cryptographic hash functions.&lt;/li&gt;
&lt;li&gt;Including the relationships between all dependencies inside the component.&lt;/li&gt;
&lt;li&gt;Including a timestamp of when and by whom the SBOM report was created or last modified&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In this section, we discuss different kinds and formats for SBOM standards and make a brief comparison between them. Three commonly used standards achieved the NTIA minimum requirements for SBOM generation and each one results in a different final SBOM document.&lt;/p&gt;
&lt;h3 id=&#34;1---the-software-package-data-exchange-spdx&#34;&gt;1 - The Software Package Data Exchange (SPDX)&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;History:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;SPDX is an open-source machine-readable format adopted by the Linux Foundation as an industry standard. The specifications are implemented as a file format that identifies the software components within a larger piece of computer software and fulfilling the requirements of NTIA. The SPDX project started in 2010 and was initially dedicated to solving the issues around open source licensing compliance. It evolved over the years to adhere supply chain security challenges and has seen extensive uptake by companies and projects in the software industry. Companies like Hitachi, Fujitsu, and Toshiba contributed to furthering the standard in the &lt;a href=&#34;https://spdx.github.io/spdx-spec/&#34;&gt;SPDX v2.2.2 specification release&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The &lt;a href=&#34;https://spdx.github.io/spdx-spec/&#34;&gt;SPDX specification&lt;/a&gt; describes the necessary sections and fields to produce a valid SPDX document. Note that the only mandatory field in all spdx documents is the &amp;ldquo;Document Creation Information&amp;rdquo; section. The presence of other sections (and subset fields of each section) is dependent on your use case and the information you want to provide.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/sbom-guide/spdx-2.2-document.png&#34; alt=&#34;spdx-specification&#34;&gt;&lt;/p&gt;
&lt;p&gt;Fig 1: &lt;a href=&#34;https://spdx.dev/wp-content/uploads/sites/41/2020/05/spdx-2.2-document.png&#34;&gt;https://spdx.dev/wp-content/uploads/sites/41/2020/05/spdx-2.2-document.png&lt;/a&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Document Creation Information&lt;/strong&gt; – Denotes who created the document, how it was created, and other useful information related to its creation. It provides the necessary information for forward and backward compatibility for processing tools (version numbers, license for data, authors, etc. )&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Package Information&lt;/strong&gt; – This section provides information about the “package”. A package can be one or more files. These files could be one or more files of any type including but not limited to source, documents, binaries, containers, and so forth. The package information contains the originator, where it was sourced from, a download URL, a checksum, and so forth. It also contains summary licensing for the package.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;File Information&lt;/strong&gt; –  This is information about a specific file. It can contain the file copyrights found in the file (if any), the license of the file, a checksum for the file, file contributors, and so forth.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Snippet Information&lt;/strong&gt; – Snippets can optionally be used when a file is known to have some content that has been included from another source. They are useful for denoting when part of a file may have been created under another licenseSnippet information can be used to define licensing for ranges within files.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Other Licensing Information&lt;/strong&gt; – Other licensing information provides a way to describe licenses that are not on the &lt;a href=&#34;https://spdx.org/licenses/&#34;&gt;SPDX License List&lt;/a&gt;. You can create a local (to the SPDX document) identifier for the license and place the license text itself in the document as a well and then reference it for files just like you would a license from the license list.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Relationships&lt;/strong&gt; –  Relationships were introduced in the 2.0 specification and are a very powerful way of expressing how SPDX documents relate to one another. See an example of how the SPDX represents those &lt;a href=&#34;https://spdx.dev/resources/use/#:~:text=Packages%20and%20Relationships&#34;&gt;here&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Annotations&lt;/strong&gt; – Annotations are comments made by people on various entities and elements within the document. For example, someone reviewing the document may make an annotation about a file and its license. Annotations are useful for reviews of SPDX documents and for conveying specific information about the package, file, creation, license, file(s), etc.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In the &lt;a href=&#34;https://spdx.github.io/spdx-spec/&#34;&gt;SPDX specification release 2.2.2&lt;/a&gt;, additional output formats of JSON, YAML, and XML are supported. A diverse set of examples for SPDX are available on this &lt;a href=&#34;https://github.com/spdx/spdx-examples&#34;&gt;github repo&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Further information on the data model and SPDX guide can be found on the &lt;a href=&#34;https://spdx.dev/&#34;&gt;SPDX website&lt;/a&gt;.&lt;/p&gt;
&lt;hr&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Use Cases:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;SBOM for software components&lt;/li&gt;
&lt;li&gt;Tracking of intellectual property (licensing, copyright) of software components&lt;/li&gt;
&lt;li&gt;Listing contents of a software distribution&lt;/li&gt;
&lt;li&gt;Container contents inventory&lt;/li&gt;
&lt;li&gt;Associating CPEs with specific packages&lt;/li&gt;
&lt;li&gt;Identifying provenance of lines of code embedded in files&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Key Features:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Documented artifacts can be checked using the provided hash values&lt;/li&gt;
&lt;li&gt;Rich facilities for intellectual property and licensing information&lt;/li&gt;
&lt;li&gt;Flexible model able to scale from snippets and files up to packages, containers, and even operating system distributions&lt;/li&gt;
&lt;li&gt;Ability to add mappings to other package reference systems&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;2---software-identification-swid-tags&#34;&gt;2 - Software Identification (SWID) Tags&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;History:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;It is a standard implemented by the National Institute of Standards and Technology (NIST) in the U.S. that was published in 2009, then revised in 2015. They were designed to provide a transparent way for organizations to track the software installed on their managed devices. Standard SWID tags are not generated at the end of certain software creation, instead, they define a lifecycle where a new SWID tag is added to an endpoint with the software installation process and is deleted with the uninstall process. When this lifecycle is followed, the presence of a given SWID Tag corresponds directly to the presence of the software product that the Tag describes.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/sbom-guide/swid-tags-lifecycle.png&#34; alt=&#34;swid-tag-lifecycle&#34;&gt;&lt;/p&gt;
&lt;p&gt;Fig 2: &lt;a href=&#34;https://d3i71xaburhd42.cloudfront.net/496312d64dc77b223803a4ee1b717be8e528e86f/16-Figure1-1.png&#34;&gt;https://d3i71xaburhd42.cloudfront.net/496312d64dc77b223803a4ee1b717be8e528e86f/16-Figure1-1.png&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Note that the present SWID tags change depending on the current state of the software.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;The &lt;a href=&#34;https://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf&#34;&gt;NISTIR 8060&lt;/a&gt; Guideline identifies the standards of SWID tags and the components of each tag. We here go over the necessary types mentioned in the figure above. To capture the lifecycle of a software component, the SWID specification defines four types of SWID tags: primary, patch, corpus, and supplemental&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Corpus Tag&lt;/strong&gt; –  A SWID Tag that identifies and describes an installable software product in its pre-installation state. A corpus tag can be used to represent metadata about an
installation package or installer for a software product, a software update, or a patch.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Primary Tag&lt;/strong&gt; –  A SWID Tag that identifies and describes a software product installed
on a computing device.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Supplemental Tag&lt;/strong&gt; – A SWID Tag that allows additional information to be associated with any referenced SWID tag. This helps to ensure that SWID Primary and Patch Tags
provided by a software provider are not modified by software management tools while
allowing these tools to provide their software metadata.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Patch Information&lt;/strong&gt; – A SWID Tag that identifies and describes an installed patch that has made incremental changes to a software product installed on a computing device.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt; that Corpus, primary, and patch tags have similar functions in that they describe the existence and/or presence of different types of software (e.g., software installers, software installations, software patches), and, potentially, different states of software products. In contrast, supplemental tags furnish additional information not contained in the corpus, primary, or patch tags.&lt;/p&gt;
&lt;p&gt;SWID tags are mainly implemented in XML format while JSON format is under development. Some tag examples can be found &lt;a href=&#34;https://www.adelton.com/docs/security/minting-collecting-swid-tags&#34;&gt;here&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Use Cases:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;SBOM for software components&lt;/li&gt;
&lt;li&gt;Continuous monitoring of installed software inventory&lt;/li&gt;
&lt;li&gt;Identifying vulnerable software on endpoints&lt;/li&gt;
&lt;li&gt;Ensuring that installed software is properly patched&lt;/li&gt;
&lt;li&gt;Preventing installation of unauthorized or corrupted software&lt;/li&gt;
&lt;li&gt;Preventing the execution of corrupted software&lt;/li&gt;
&lt;li&gt;Managing software entitlements&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Key Features:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Provides stable software identifiers created at build time&lt;/li&gt;
&lt;li&gt;Standardizes software information that can be exchanged between software providers and consumers as part of the software installation process&lt;/li&gt;
&lt;li&gt;Enables the correlation of information related to software including related patches or updates, configuration settings, security policies, and vulnerability and threat advisories.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;3---cyclonedx&#34;&gt;3 - CycloneDX&lt;/h3&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;History:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;CycloneDX is a lightweight SBOM standard designed for use in application security context and supply chain component analysis as it was originally intended to identify vulnerabilities and supply chain component analysis. It also supports checking for licensing compliance. The CycloneDX project was initiated in 2017 in the &lt;a href=&#34;https://owasp.org/&#34;&gt;OWASP&lt;/a&gt;community, then it became a dedicated open source project and included other working groups from &lt;a href=&#34;https://www.sonatype.com/&#34;&gt;Sonatype&lt;/a&gt;and &lt;a href=&#34;https://www.servicenow.com/&#34;&gt;ServiceNow&lt;/a&gt;. Supported file formats for CycloneDX are (XML, JSON, and protocol buffers)&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Specs:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;CycloneDX provides schemas for both XML and JSON, defining a format for describing simple and complex compositions of software components. It&amp;rsquo;s designed to be flexible, and easily adaptable, with implementations for popular build systems. The specification encourages the use of ecosystem-native naming conventions and supports SPDX license IDs and expressions, pedigree, and external references. It also natively supports the Package URL specification and correlating components to CPEs. The CycloneDX object model is defined in the figure.&lt;/p&gt;
&lt;p align=&#34;center&#34; width=&#34;100%&#34;&gt;
    &lt;img src=&#34;https://jenkins-x.io/images/sbom-guide/cyclonedx-high-level-object-model-small.svg&#34; width=&#34;480&#34; height=&#34;320&#34;&gt;
&lt;/p&gt;
&lt;br/&gt;
&lt;br/&gt;
&lt;p&gt;Fig 3: &lt;a href=&#34;https://cyclonedx.org/theme/assets/images/high-level-object-model-small.svg&#34;&gt;https://cyclonedx.org/theme/assets/images/high-level-object-model-small.svg&lt;/a&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;BOM Metadata Information&lt;/strong&gt; – BOM metadata includes the supplier, manufacturer, and the target component for which the BOM describes. It also includes the tools used to create the BOM, and license information for the BOM document itself.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Components Information&lt;/strong&gt; – Components describe the complete inventory of first-party and third-party components. Component identity can be represented as:
&amp;ndash; Coordinates (group, name, version)
&amp;ndash; Package URL
&amp;ndash; Common Platform Enumerations (CPE)
&amp;ndash; SWID
&amp;ndash; Cryptographic hash functions (SHA-1, SHA-2, SHA-3, BLAKE2b, BLAKE3)&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Services Information&lt;/strong&gt; – Services describe external APIs that the software may call. Services describe endpoint URIs, authentication requirements, and trust boundary traversals. The flow of data between software and services can also be described including the data classifications and the flow direction of each type.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Dependency Relationships&lt;/strong&gt; – CycloneDX provides the ability to describe components and their dependency on other components. The dependency graph is capable of representing both direct and transitive relationships. Components that depend on services can be represented in the dependency graph and services that depend on other services can be represented as well.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Compositions&lt;/strong&gt; – Compositions describe constituent parts (including components, services, and dependency relationships) and their completeness. The aggregate of each composition can be described as complete, incomplete, incomplete first-party only, incomplete third-party only, or unknown.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Vulnerabilities&lt;/strong&gt; –  Known vulnerabilities inherited from the use of third-party and open source software and the exploitability of the vulnerabilities can be communicated with CycloneDX. Previously unknown vulnerabilities affecting both components and services may also be disclosed using CycloneDX, making it ideal for both VEX and security advisory use cases.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Extensions&lt;/strong&gt; – Multiple extension points exist throughout the CycloneDX object model allowing fast prototyping of new capabilities and support for specialized and future use cases. The CycloneDX project maintains extensions that are beneficial to the larger community. The project encourages community participation and the development of extensions that target specialized or industry-specific use cases.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;Use Cases:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Inventory of all software components.&lt;/li&gt;
&lt;li&gt;Identifying known vulnerabilities.&lt;/li&gt;
&lt;li&gt;Integrity verification using the hash functions.&lt;/li&gt;
&lt;li&gt;Authenticity of the software components using a digital signature.&lt;/li&gt;
&lt;li&gt;License compliance&lt;/li&gt;
&lt;li&gt;Provenance&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;generate-sboms-manually-definitely-not&#34;&gt;Generate SBOMs manually? definitely not&lt;/h2&gt;
&lt;p&gt;SBOMs are frequently updated with each release of the software, so we need tools and packages to be integrated with our ci/cd pipeline. We talk about this &lt;a href=&#34;https://jenkins-x.io/blog/2022/07/24/sbom-tools&#34;&gt;here&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Introduction to Software Bill Of Materials</title>
      <link>https://jenkins-x.io/blog/2022/07/24/intro-to-sbom/</link>
      <pubDate>Sun, 24 Jul 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/07/24/intro-to-sbom/</guid>
      <description>
        
        
        &lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Before going through Software Bill Of Materials (SBOMs), we need to set the ground for a rising concern in the software industry which is Software Supply Chain Security.
Like traditional industries, deploying a piece of a software artifact goes through multiple stages composed of collecting source code components, libraries, tools, and processes used in those stages.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/sbom-guide/supply-chain.png&#34; alt=&#34;comparing the different steps in a real world supply chain with software supply chain&#34;&gt;&lt;/p&gt;
&lt;p&gt;Fig. 1 &lt;a href=&#34;https://blog.convisoappsec.com/en/is-your-software-supply-chain-secure/&#34;&gt;https://blog.convisoappsec.com/en/is-your-software-supply-chain-secure/&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;A supply chain attack can occur along the chain from submitting unauthorized malicious code in your source, unauthorized injection of harmful dependencies, and even replacing packages after being built with other compromised artifacts.
A more detailed explanation about those types of attacks is &lt;a href=&#34;https://slsa.dev/spec/v0.1/threats&#34;&gt;here&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Due to its importance and being a critical issue, generating SBOM for your software adds another layer of protection to this threat.&lt;/p&gt;
&lt;h2 id=&#34;definition-what-is-sbom&#34;&gt;Definition: What is SBOM?&lt;/h2&gt;
&lt;p&gt;As far as we know, developers around the world are building web applications using hundreds of third-party open-source libraries and packages. You can confidently tell that 90% of the software products around the world are built over open-source components. With that in mind, we need to keep track of using these dependencies while building our applications. What if there are vulnerabilities in the libraries we use? How to efficiently protect ourselves against it?.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://en.wikipedia.org/wiki/Software_supply_chain#:~:text=Software%20vendors%20often,could%20harm%20them.&#34;&gt;Software Bill Of Materials&lt;/a&gt;&lt;/strong&gt; (SBOM) is a complete formally structured list of the materials (components, packages, libraries, SDK) used to build (i.e. compile, link) a given piece of software and the supply chain relationships between all these materials.&lt;/p&gt;
&lt;p&gt;It is an inventory of all the components developers used to make this software. It has many formats and many generating tools but all have the same purpose in the end.
&lt;em&gt;&lt;strong&gt;Example: a simple formatted SBOM of Ubuntu alpine docker image using &lt;a href=&#34;https://anchore.com/sbom/how-to-generate-an-sbom-with-free-open-source-tools/&#34;&gt;syft&lt;/a&gt;&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;✔ Loaded image  
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt; ✔ Parsed image  
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt; ✔ Cataloged packages      &lt;span style=&#34;color:#f92672&#34;&gt;[&lt;/span&gt;&lt;span style=&#34;color:#ae81ff&#34;&gt;14&lt;/span&gt; packages&lt;span style=&#34;color:#f92672&#34;&gt;]&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;NAME                    VERSION      TYPE 
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;alpine-baselayout       3.2.0-r18    apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;alpine-keys             2.4-r1       apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;apk-tools               2.12.7-r3    apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;busybox                 1.34.1-r3    apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;ca-certificates-bundle  20191127-r7  apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;libc-utils              0.7.2-r3     apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;libcrypto1.1            1.1.1l-r7    apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;libretls                3.3.4-r2     apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;libssl1.1               1.1.1l-r7    apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;musl                    1.2.2-r7     apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;musl-utils              1.2.2-r7     apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;scanelf                 1.3.3-r0     apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;ssl_client              1.34.1-r3    apk   
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;zlib                    1.2.11-r3    apk
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Here it shows only softwares included in the final layer of the container (default choice by syft). If we want to view a detailed SBOM with one detailed format, we can run &lt;code&gt;syft alpine -o spdx-json&lt;/code&gt;. This will view the output as &lt;code&gt;.json&lt;/code&gt; file following the &lt;code&gt;spdx&lt;/code&gt; format (will discuss that later)&lt;/p&gt;
&lt;h2 id=&#34;use-cases-in-supply-chain-security&#34;&gt;Use cases in Supply chain security&lt;/h2&gt;
&lt;p&gt;What makes a supply chain attack susceptible is the lack of transparency and visibility about whether the software gets affected by a recent exploit or not. This greatly affects both producers and customers of the product.&lt;/p&gt;
&lt;p&gt;On the user&amp;rsquo;s side if they know the components of the software and that there is one component affected by certain vulnerabilities, they are better aware and ready to protect against potential attacks. This is crucial in many cases, especially with open-source tools.&lt;/p&gt;
&lt;p&gt;On the software producer&amp;rsquo;s side, it happens a lot that they are not fully aware of all the third parties used inside the project, and in turn, they can not track vulnerabilities in the system that could pose a threat. Cases like the &lt;a href=&#34;https://snyk.io/blog/log4shell-in-a-nutshell/&#34;&gt;Log4Shell&lt;/a&gt; vulnerability are an example of a component (in this case, a logging library) that many producers never bothered to check because it isn&amp;rsquo;t a direct software dependency, but rather a transitive one that is depended upon by other components.&lt;/p&gt;
&lt;p&gt;SBOM can also be useful in licensing and legal issues with some formats. SPDX (Software Package Data Exchange) standard for SBOM identifies the licenses of the used components and can be checked for compliance later.&lt;/p&gt;
&lt;p&gt;Next, we view the different standards and formats for SBOMs and the specifications of each one. See them &lt;a href=&#34;https://jenkins-x.io/blog/2022/07/24/sbom-formats&#34;&gt;here&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Migrate to Google Artifact Registry</title>
      <link>https://jenkins-x.io/blog/2024/05/06/migrating-artifact-registry/</link>
      <pubDate>Mon, 06 May 2024 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2024/05/06/migrating-artifact-registry/</guid>
      <description>
        
        
        &lt;p&gt;Google has announced that &lt;a href=&#34;https://cloud.google.com/artifact-registry/docs/transition/transition-from-gcr&#34;&gt;container registry will be shut down some time after March 18, 2025&lt;/a&gt;. For GKE clusters created with version 1.12.0 or later of &lt;a href=&#34;https://github.com/jenkins-x/terraform-google-jx&#34;&gt;terraform-google-jx&lt;/a&gt; it&amp;rsquo;s unlikely that anything needs to be done, but for older clusters you should upgrade your cluster while considering &lt;a href=&#34;https://github.com/jenkins-x/terraform-google-jx#migration-from-container-to-artifact-registry&#34;&gt;our advice regarding migration from container registry to artifact registry&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;If you are using a Google Service Account to run terraform you need to add the role requirement roles/artifactregistry.admin. See our guide regarding &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/google/svc_acct/&#34;&gt;Google Service Account&lt;/a&gt; for details.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Improve your changelogs</title>
      <link>https://jenkins-x.io/blog/2023/05/24/propagate-changelogs/</link>
      <pubDate>Wed, 24 May 2023 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2023/05/24/propagate-changelogs/</guid>
      <description>
        
        
        &lt;h2 id=&#34;background&#34;&gt;Background&lt;/h2&gt;
&lt;p&gt;A standard part of the Jenkins X pipelines since a long time is the execution of &lt;code&gt;jx changelog create&lt;/code&gt; that takes the
commit messages between the release currently being created and the previous one and creates a change log from these.
The change log is then stored as a release note in GitHub or other git provider.&lt;/p&gt;
&lt;p&gt;During the last year some improvements have landed in various Jenkins X components to improve the changelogs and
their usefulness. So I&amp;rsquo;ll take this opportunity to describe these improvements and also in general give hints to how
to get useful changelogs.&lt;/p&gt;
&lt;h2 id=&#34;overview-of-major-improvements&#34;&gt;Overview of major improvements&lt;/h2&gt;
&lt;p&gt;Changelogs haven&amp;rsquo;t been very informative with regard to upgrades, ie those applied with &lt;code&gt;jx promote&lt;/code&gt; or &lt;code&gt;jx  updatebot&lt;/code&gt;. One example of this is &lt;a href=&#34;https://github.com/jenkins-x/jx/releases&#34;&gt;the release notes of jx&lt;/a&gt; after the
split out of most functionality to plugins. Lately these have improved due to new functionality to propagate
changelogs via pull requests.&lt;/p&gt;
&lt;p&gt;One place where changelogs have been completely lacking is in cluster repositories. But using the functionality for
propagation of changelogs and some changes in jx boot job you can now a get a changelog for every successful
application of changes in a cluster.&lt;/p&gt;
&lt;h2 id=&#34;example&#34;&gt;Example&lt;/h2&gt;
&lt;p&gt;An example of what this functionality achieves can be seen in a release of jx:&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx/releases/tag/v3.10.81&#34;&gt;https://github.com/jenkins-x/jx/releases/tag/v3.10.81&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;If you scroll past the boilerplate installation instructions you first see the changelog of jx itself generated
from commit messages: &lt;a href=&#34;https://github.com/jenkins-x/jx/compare/v3.10.80...v3.10.81&#34;&gt;https://github.com/jenkins-x/jx/compare/v3.10.80...v3.10.81&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Then there is a separator followed by the changelog of jx-gitops. If you look in the commit messages referred to above
you will see a link to the pull request on jx for this upgrade: &lt;a href=&#34;https://github.com/jenkins-x/jx/pull/8564&#34;&gt;https://github.com/jenkins-x/jx/pull/8564&lt;/a&gt;. As you can
see this pull request includes the changelog for version 0.14.8 of jx-gitops as generated by &lt;code&gt;jx changelog create&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;Essentially what happens is that &lt;code&gt;jx changelog create&lt;/code&gt; apart from storing the release information of jx-gitops also stores it
in a file. This file is then put in the pull request on jx by &lt;code&gt;jx updatebot&lt;/code&gt;. Finally &lt;code&gt;jx changelog create&lt;/code&gt; looks
for changelogs in the pull requests referred to in the merge commit.&lt;/p&gt;
&lt;h2 id=&#34;how-to-write-commit-messages&#34;&gt;How to write commit messages&lt;/h2&gt;
&lt;p&gt;To get a good changelog the first requisite is to write good commit messages. &lt;code&gt;jx changelog create&lt;/code&gt; expects commit
messages to adhere to the &lt;a href=&#34;https://www.conventionalcommits.org/&#34;&gt;Conventional commits&lt;/a&gt; standard.
It is the first line of each commit message that is used, with a couple of exceptions I&amp;rsquo;ll describe below.&lt;/p&gt;
&lt;p&gt;When following this standard the first line should adhere to this format:&lt;/p&gt;
&lt;p&gt;&lt;code&gt;&amp;lt;type&amp;gt;[optional scope]: &amp;lt;description&amp;gt;&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;While &lt;code&gt;jx changelog create&lt;/code&gt; can handle any type some will be expanded for a better looking changelog:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;feat&lt;/code&gt;: New Features&lt;/li&gt;
&lt;li&gt;&lt;code&gt;fix&lt;/code&gt;: Bug Fixes&lt;/li&gt;
&lt;li&gt;&lt;code&gt;perf&lt;/code&gt;: Performance Improvements&lt;/li&gt;
&lt;li&gt;&lt;code&gt;refactor&lt;/code&gt;: Code Refactoring&lt;/li&gt;
&lt;li&gt;&lt;code&gt;docs&lt;/code&gt;: Documentation&lt;/li&gt;
&lt;li&gt;&lt;code&gt;test&lt;/code&gt;: Tests&lt;/li&gt;
&lt;li&gt;&lt;code&gt;revert&lt;/code&gt;: Reverts&lt;/li&gt;
&lt;li&gt;&lt;code&gt;style&lt;/code&gt;: Styles&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Since the description is used verbatim in the changelog it should be meaningful to the audience of the changelog. Is
for example &lt;code&gt;fixed typo&lt;/code&gt; meaningful? Maybe it is better to write what you try to achieve. While doing this it is
good to know that duplicate descriptions are ignored by changelog. So if you add the same description again when
doing a fix doesn&amp;rsquo;t mean that you get duplicate lines in the changelog.&lt;/p&gt;
&lt;p&gt;An optional scope is prefixed to the description in the changelog.&lt;/p&gt;
&lt;p&gt;The other common part of the commit message that is reflected in the changelog are references to issues. These can
be put anywhere in the commit message. These issues are then linked to both for the specific commit and in a
separate list of affected issues.&lt;/p&gt;
&lt;p&gt;An example:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;feat: support dependency updates

fixed typo

relates to #1234
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;A less common part of a commit message that affects the changelog regards breaking changes. A footer to a commit
message of the format &lt;code&gt;BREAKING CHANGE: &amp;lt;description&amp;gt;&lt;/code&gt; can be added and this description will be put at the top of
the changelog under the heading BREAKING CHANGES. If you add an exclamation mark before the colon in the first line
without the breaking change footer the ordinary description will be put under this heading.&lt;/p&gt;
&lt;p&gt;A couple of examples regarding braking changes:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;fix: upgraded library foo

BREAKING CHANGE: don&amp;#39;t support http anymore

#98765
&lt;/code&gt;&lt;/pre&gt;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;fix!: removed insecure method fubar

resolves #56789
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Good to know is that &lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-release-version&#34;&gt;&lt;code&gt;jx release version&lt;/code&gt;&lt;/a&gt; also conforms
to Conventional Commits so the commit messages also affects which part of the semantic version is increased for a
release.&lt;/p&gt;
&lt;p&gt;There are of course other uses of good commit messages than to generate changelogs. While code itself together with
comments should be self-explanatory with regard to what is done and how I often resort to commit messages to
understand why a change was made. I typically use the git blame functionality for this. This is another reason to
not use messages only saying something like &lt;code&gt;fixed typo&lt;/code&gt;, since that typically isn&amp;rsquo;t a useful answer to the question
of why for a future developer.&lt;/p&gt;
&lt;p&gt;For more tips regarding writing good commit messages see for example
&lt;a href=&#34;https://www.freecodecamp.org/news/how-to-write-better-git-commit-messages/&#34;&gt;How to Write Better Git Commit Messages&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&#34;manually-edit-changelog&#34;&gt;Manually edit changelog&lt;/h2&gt;
&lt;p&gt;Note that since changelogs for dependencies are propagated through pull requests you can edit the changelog for an
application manually in the pull request before it is merged.&lt;/p&gt;
&lt;h2 id=&#34;configuration&#34;&gt;Configuration&lt;/h2&gt;
&lt;p&gt;Some of the features described above work out-of-the-box while others require some tweaking.&lt;/p&gt;
&lt;h3 id=&#34;changelog-for-cluster-repository&#34;&gt;Changelog for cluster repository&lt;/h3&gt;
&lt;p&gt;Apart from the other advantages of switching from &lt;code&gt;kubectl apply&lt;/code&gt; to &lt;code&gt;kpt live apply&lt;/code&gt; for reconciliation of cluster
repository with the cluster you also get a changelog generated for each successful reconciliation.&lt;/p&gt;
&lt;p&gt;This changelog also includes a list of upgraded / added / deleted releases and the associated versions.&lt;/p&gt;
&lt;p&gt;See a &lt;a href=&#34;https://jenkins-x.io/blog/2023/03/09/kpt-live-apply/&#34;&gt;previous blogpost&lt;/a&gt; for more information.&lt;/p&gt;
&lt;h3 id=&#34;reuse-pull-requests&#34;&gt;Reuse pull requests&lt;/h3&gt;
&lt;p&gt;With the default settings one pitfall with the propagating the changelog via pull requests is if not all pull
requests are merged. Let&amp;rsquo;s say version 1.0.0 of an application is released and pull request with a big changelog is
created for the production namespace. But before it is merged an error is detected and version 1.0.1 is
released and a PR for the version is created which only includes the changelog for the bug fix. When that PR is
merged only the changelog for the bug fix ends up in the changelog for the cluster.&lt;/p&gt;
&lt;p&gt;To mitigate this you can enable reuse of pull requests. This means that if a PR for upgrading a dependency already
exists when executing &lt;code&gt;jx promote&lt;/code&gt; or &lt;code&gt;jx updatebot&lt;/code&gt; the commits for that PR are replaced with one for the new
upgrade. The existing changelog in the PR is kept though and the changelog for the new version is appended. This way
no changelog is missed.&lt;/p&gt;
&lt;p&gt;Enabling reuse of pull requests for &lt;code&gt;jx promote&lt;/code&gt; is done in &lt;code&gt;jx-requirements.yaml&lt;/code&gt; by setting &lt;code&gt;reusePullRequest&lt;/code&gt; to
&lt;code&gt;true&lt;/code&gt; for an environment. It can also be done in the same way when configuring environments others ways. See
&lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/config/&#34;&gt;https://jenkins-x.io/v3/develop/environments/config/&lt;/a&gt; for more details about configuring environments.&lt;/p&gt;
&lt;p&gt;More information about reuse of pull requests in a future blog post.&lt;/p&gt;
&lt;h3 id=&#34;custom-pipelines&#34;&gt;Custom pipelines&lt;/h3&gt;
&lt;p&gt;In the pipelines defined in &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/&#34;&gt;https://github.com/jenkins-x/jx3-pipeline-catalog/&lt;/a&gt; the necessary incantations of &lt;code&gt;jx  changelog&lt;/code&gt;, &lt;code&gt;jx promote&lt;/code&gt; and &lt;code&gt;jx updatebot&lt;/code&gt; are made for promoting changelogs. But if you have a custom release
pipeline you might need to do some modifications. In particular &lt;code&gt;jx changelog create&lt;/code&gt; need to save the changelog to a file.
This is done by adding an argument like &lt;code&gt;--output-markdown=../changelog.md&lt;/code&gt;. To have this changelog added to the PR
the option &lt;code&gt;--add-changelog=../changelog.md&lt;/code&gt; needs to be added to &lt;code&gt;jx promote&lt;/code&gt; (or &lt;code&gt;jx updatebot&lt;/code&gt; if applicable).&lt;/p&gt;
&lt;h3 id=&#34;jira-as-issue-tracker&#34;&gt;Jira as issue tracker&lt;/h3&gt;
&lt;p&gt;In the examples of commit messages above the references to issues are to the git provider. This is the default, so
if you for example are using GitHub as your git provider and also use the issue tracker in GitHub no extra
configuration is needed.&lt;/p&gt;
&lt;p&gt;But there also is support for Jira as issue tracker. If you enable this support you can refer to issues both at the git
provider and in Jira.&lt;/p&gt;
&lt;p&gt;You enable Jira support and configure it in the jx-requirements.yaml of the cluster repository. The
&lt;code&gt;issueProvider&lt;/code&gt; field is added under &lt;code&gt;spec.cluster&lt;/code&gt;:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-diff&#34; data-lang=&#34;diff&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;@@ -13,5 +13,9 @@ spec:
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;&lt;/span&gt;     gitKind: github
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;     gitName: github
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;     gitServer: https://github.com
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#a6e22e&#34;&gt;+    issueProvider:
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#a6e22e&#34;&gt;+      jira:
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#a6e22e&#34;&gt;+        serverUrl: https://myjira.atlassian.net
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#a6e22e&#34;&gt;+        userName: jirauser@example.com
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#a6e22e&#34;&gt;&lt;/span&gt;     project: &amp;#34;123456789&amp;#34;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;     provider: eks
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;For security reasons the credentials for the user that will fetch data from Jira is not put there. Instead &lt;code&gt;jx  changelog&lt;/code&gt; expects it in the environment variable &lt;code&gt;JIRA_API_TOKEN&lt;/code&gt;. The easiest way to supply this environment
variable is by adding it to the secret &lt;code&gt;jx-boot-job-env-vars&lt;/code&gt; in namespace &lt;code&gt;jx&lt;/code&gt; since the content av this secret are
exposed as environment variables to all standard build pipelines. If the secret doesn&amp;rsquo;t exist you can create it
yourself like this:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;# lets make sure we are in the jx-git-operator namespace&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx ns jx-git-operator
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl create secret generic jx-boot-job-env-vars --from-literal&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;JIRA_API_TOKEN&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;S!B*d$zDsb&amp;#39;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;The &lt;a href=&#34;https://github.com/jenkins-x/terraform-aws-eks-jx&#34;&gt;Terraform module for Jenkins X in EKS&lt;/a&gt; also have support for
adding variables to &lt;code&gt;jx-boot-job-env-vars&lt;/code&gt;.&lt;/p&gt;
&lt;h3 id=&#34;more-customizations&#34;&gt;More customizations&lt;/h3&gt;
&lt;p&gt;In the &lt;a href=&#34;https://jenkins-x.io/v3/develop/reference/jx/changelog/create/&#34;&gt;documentations&lt;/a&gt; for &lt;code&gt;jx changelog create&lt;/code&gt; information about more customisations can be found.&lt;/p&gt;
&lt;h2 id=&#34;references&#34;&gt;References&lt;/h2&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/jenkins-x/enhancements/tree/master/proposals/propagate-changelogs&#34;&gt;The enhancement proposal for propagation of changelogs&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Reconcile with kpt live apply</title>
      <link>https://jenkins-x.io/blog/2023/03/09/kpt-live-apply/</link>
      <pubDate>Thu, 09 Mar 2023 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2023/03/09/kpt-live-apply/</guid>
      <description>
        
        
        &lt;p&gt;Since the dawn of Jenkins X 3 the default last step of reconciling the state of the files in your cluster repository to
your cluster has been to execute &lt;code&gt;kubectl apply&lt;/code&gt;. You can find more details about this
&lt;a href=&#34;https://jenkins-x.io/v3/about/how-it-works/#boot-job&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;There are some drawbacks with &lt;code&gt;kubectl apply&lt;/code&gt; though. The one that made me start looking for alternatives was that if
you remove a resource from your cluster repository it may not be removed from your cluster. The way deletion works with
&lt;code&gt;kubectl apply&lt;/code&gt; is that it is handed the option &lt;code&gt;--prune&lt;/code&gt; which will remove resources that are not in the manifests.
Except that it doesn&amp;rsquo;t always work as expected. It will only remove certain kinds of resources
&lt;a href=&#34;https://github.com/kubernetes/kubernetes/blob/4e800983fb8da4a5960a58ad9b380484770647d1/staging/src/k8s.io/kubectl/pkg/util/prune/prune.go#L28-L44&#34;&gt;defined in kubectl&lt;/a&gt;.
In my case I removed an HorizontalPodAutoscaler from my cluster repository, but it wasn&amp;rsquo;t removed from my cluster.&lt;/p&gt;
&lt;p&gt;When trying to find a solution to this I first tried to override this default list in kubectl of things to prune, but
this turned out to be difficult in the general case. I also tried the already existing alternative of using &lt;code&gt;kapp&lt;/code&gt; to
apply the manifests, but I couldn&amp;rsquo;t get that to work. Looking for other options I settled for &lt;code&gt;kpt live apply&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id=&#34;configuration&#34;&gt;Configuration&lt;/h2&gt;


&lt;div class=&#34;alert alert-warning&#34; role=&#34;alert&#34;&gt;


    For all the functionality described here to work you need to have a cluster that is
&lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/cluster/&#34;&gt;upgraded&lt;/a&gt; later than January 24th 2023.

&lt;/div&gt;

&lt;p&gt;You enable the use of &lt;code&gt;kpt live apply&lt;/code&gt; by adding&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-make&#34; data-lang=&#34;make&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;KUBEAPPLY &lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt; kpt-apply
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;to the &lt;code&gt;Makefile&lt;/code&gt; of your cluster repository anywhere before &lt;code&gt;include versionStream/src/Makefile.mk&lt;/code&gt;. This works both
in a dev cluster and in a &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/multi-cluster/multi-cluster/&#34;&gt;remote cluster&lt;/a&gt;.
(With the caveat that all bets are off if you have done changes yourself to &lt;code&gt;versionStream/src/Makefile.mk&lt;/code&gt;.)&lt;/p&gt;
&lt;p&gt;After you have pushed this you can watch the log of the boot job using &lt;code&gt;jx admin log&lt;/code&gt; as usual. When &lt;code&gt;kpt live  apply&lt;/code&gt; has been executed the first time you can optionally add let &lt;code&gt;kpt live apply --dry-run&lt;/code&gt; be executed for
pull requests, giving a better assurance that the content of a pull request will apply nicely. But this only work
properly for pull requests to the dev cluster, since it&amp;rsquo;s in the dev cluster the pull request pipeline will execute.
So in a remote clusters this should not be enabled. That said this functionality can be enabled by adding&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-make&#34; data-lang=&#34;make&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;PR_LINT &lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt; kpt-apply-dry-run
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;to the &lt;code&gt;Makefile&lt;/code&gt; of your cluster repository.&lt;/p&gt;
&lt;h2 id=&#34;waiting-for-resources-to-be-reconciled&#34;&gt;Waiting for resources to be reconciled&lt;/h2&gt;
&lt;p&gt;While the fact that I can be sure that removed resource actually are gone is the killer feature of &lt;code&gt;kpt live apply&lt;/code&gt;
for me the opposite is true as well. With this I mean that &lt;code&gt;kpt live apply&lt;/code&gt;(and as a consequence) the boot job won&amp;rsquo;t
succeed unless all resources are verified to have been applied. This includes for example that the rollout of new
applications versions with deployments have succeeded.&lt;/p&gt;
&lt;p&gt;This can be seen as  a problem though: the default is that &lt;code&gt;kpt live apply&lt;/code&gt; tries for 15 minutes before timing out
with an error. But since the boot job is normal k8s job the job controller will create new pods on failure up to
the backoff limit, that is set to &lt;strong&gt;4&lt;/strong&gt;. This can block the application of subsequent changes to the cluster repo.&lt;/p&gt;
&lt;h2 id=&#34;tagging-and-release-notes&#34;&gt;Tagging and release notes&lt;/h2&gt;
&lt;p&gt;When activating &lt;code&gt;kpt live apply&lt;/code&gt; you will also see that tags are added to the cluster repository upon successful
application of changes. These tags can have 3 prefixes:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;crd&lt;/code&gt; for custom resource definitions&lt;/li&gt;
&lt;li&gt;&lt;code&gt;cluster&lt;/code&gt; for cluster wide resources&lt;/li&gt;
&lt;li&gt;&lt;code&gt;ns&lt;/code&gt; for namespaced resources (the most common)&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;For &lt;code&gt;ns&lt;/code&gt; tags release notes will also be generated and added to the git provider (for example GitHub). This means
that you can see what has changed in your cluster by looking at the releases of the cluster repository.&lt;/p&gt;
&lt;p&gt;One handy use of this is that you can get a notification from GitHub when changes has been successfully deployed by
going to the &lt;strong&gt;Watch&lt;/strong&gt; menu for the repo, select &lt;strong&gt;Custom&lt;/strong&gt; and check &lt;strong&gt;Releases&lt;/strong&gt;. If you get the notification by email or on the
GitHub site depends on the notification settings for your GitHub account.&lt;/p&gt;
&lt;p&gt;This functionality can be further customized by adding scripts to the &lt;code&gt;extensions&lt;/code&gt; directory of your cluster repository.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;code&gt;crd-reconciled&lt;/code&gt; will be executed after a &lt;code&gt;crd&lt;/code&gt; tag has been added&lt;/li&gt;
&lt;li&gt;&lt;code&gt;cluster-reconciled&lt;/code&gt; will be executed after a &lt;code&gt;cluster&lt;/code&gt; tag has been added&lt;/li&gt;
&lt;li&gt;&lt;code&gt;ns-reconciled&lt;/code&gt; will be executed after a &lt;code&gt;ns&lt;/code&gt; tag has been added&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The default behaviour is equivalent to adding the following script as &lt;code&gt;ns-reconciled&lt;/code&gt;:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;#!/bin/sh
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx changelog create --tag-prefix ns-
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Here is a somewhat hacky variety that sends out a mail with the release notes similarly to what you can
subscribe to for yourself:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;#!/bin/sh
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;&lt;/span&gt;set -xe
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx changelog create --tag-prefix ns-
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;token&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#66d9ef&#34;&gt;$(&lt;/span&gt;kubectl get secret jx-boot -o jsonpath&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;{.data[&amp;#39;password&amp;#39;]}&amp;#34;&lt;/span&gt; | base64 -d&lt;span style=&#34;color:#66d9ef&#34;&gt;)&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;repourl&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#66d9ef&#34;&gt;$(&lt;/span&gt;kubectl get secret jx-boot -o jsonpath&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;{.data[&amp;#39;url&amp;#39;]}&amp;#34;&lt;/span&gt;    | base64 -d&lt;span style=&#34;color:#66d9ef&#34;&gt;)&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;owner&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&lt;/span&gt;&lt;span style=&#34;color:#66d9ef&#34;&gt;$(&lt;/span&gt;echo $repourl | cut -d/ -f4&lt;span style=&#34;color:#66d9ef&#34;&gt;)&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;repo&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&lt;/span&gt;&lt;span style=&#34;color:#66d9ef&#34;&gt;$(&lt;/span&gt;echo $repourl | cut -d/ -f5 | cut -d. -f1&lt;span style=&#34;color:#66d9ef&#34;&gt;)&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;(&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;cat &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;lt;&amp;lt;EOF
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;to: changelog@example.com
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;From: dev@example.com
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;MIME-Version: 1.0
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;Return-Path: &amp;lt;&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;Precedence: Bulk
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;Content-Type: text/html; charset=utf-8
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;Subject: Deploy to kubernetes cluster
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;lt;html&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;lt;body&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;lt;h1&amp;gt;Deploy to kubernetes cluster&amp;lt;/h1&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;EOF&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;curl -s  -H &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;Authorization: Bearer &lt;/span&gt;$token&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&lt;/span&gt; https://api.github.com/graphql -X POST -d &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;{&amp;#34;query&amp;#34;:&amp;#34;query { repository(owner:\&amp;#34;&amp;#39;&lt;/span&gt;$owner&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;\&amp;#34;, name:\&amp;#34;&amp;#39;&lt;/span&gt;$repo&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;\&amp;#34;) { release(tagName: \&amp;#34;ns-&amp;#39;&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;${&lt;/span&gt;TS&lt;span style=&#34;color:#e6db74&#34;&gt;}&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;\&amp;#34;) { descriptionHTML }}}&amp;#34;}&amp;#39;&lt;/span&gt; | yq .data.repository.release.descriptionHTML
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;echo &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&amp;lt;/body&amp;gt;&amp;lt;/html&amp;gt;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;)&lt;/span&gt; | sendmail -t -S smtp.example.com
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;To adapt for your own use, the minimal changes would be to find and replace the smtp server and mail addresses now
added for the domain &lt;strong&gt;example.com&lt;/strong&gt;. Don&amp;rsquo;t forget to make the script executable with &lt;code&gt;chmod +x ns-reconciled&lt;/code&gt;.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Foreign aliases</title>
      <link>https://jenkins-x.io/blog/2023/02/09/foreign-aliases/</link>
      <pubDate>Thu, 09 Feb 2023 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2023/02/09/foreign-aliases/</guid>
      <description>
        
        
        &lt;h2 id=&#34;background&#34;&gt;Background&lt;/h2&gt;
&lt;p&gt;In an organisation with many repositories and developers that are frequently shifting the maintenance of OWNERS and
OWNERS_ALIASES files can be tedious. In the passing year a couple of functionalities has been added to help
with this.&lt;/p&gt;
&lt;h2 id=&#34;foreign-aliases&#34;&gt;Foreign aliases&lt;/h2&gt;
&lt;p&gt;To avoid maintaining the OWNERS_ALIASES file in many repositories you can now refer to the OWNERS_ALIASES file in
another repository. In the Jenkins X project we have the main OWNERS_ALIASES file in the
&lt;a href=&#34;https://github.com/jenkins-x/jx-community&#34;&gt;jx-community&lt;/a&gt; repository. So in the &lt;a href=&#34;http://github.com/jenkins-x/jx&#34;&gt;jx&lt;/a&gt; repository
the OWNERS_ALIASES file only looks like this:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;foreignAliases&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;jx-community&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;The organisation defaults to be the same as for the repository, but can specify as well. So in the
&lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-project&#34;&gt;jx-project&lt;/a&gt; repository the OWNERS_ALIASES file looks like this:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;foreignAliases&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;jx-community&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;org&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;jenkins-x&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Using the filed &lt;code&gt;ref&lt;/code&gt; you can also specify a branch or tag to use instead of the default one of the repository.&lt;/p&gt;
&lt;h2 id=&#34;owners-and-owners_aliases-in-new-repositories&#34;&gt;OWNERS and OWNERS_ALIASES in new repositories&lt;/h2&gt;
&lt;p&gt;When creating or importing a repository using &lt;code&gt;jx project&lt;/code&gt; the default content of OWNERS and OWNERS_ALIASES isn&amp;rsquo;t
that useful since only the current user are put in the files.&lt;/p&gt;
&lt;p&gt;If you &lt;a href=&#34;https://jenkins-x.io/v3/about/extending/#quickstarts&#34;&gt;create your own quickstarts&lt;/a&gt; you place the OWNERS and
/ or OWNERS_ALIASES files with the content of your liking in those.&lt;/p&gt;
&lt;p&gt;A recent new functionality is that you can put OWNERS and / or OWNERS_ALIASES files in the &lt;code&gt;extensions&lt;/code&gt; directory of
your cluster repository. These files will then be used as the default content of the files in new repositories.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Project ideas for Google Summer of Code 2023 ☀️</title>
      <link>https://jenkins-x.io/blog/2023/02/06/gsoc2023-ideas/</link>
      <pubDate>Mon, 06 Feb 2023 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2023/02/06/gsoc2023-ideas/</guid>
      <description>
        
        
        &lt;p&gt;We have put together some project ideas as part of our application to participate in the Google Summer of Code 2023 program.&lt;/p&gt;
&lt;h3 id=&#34;1-cd-events-integration-with-jenkins-x&#34;&gt;1. CD events integration with Jenkins X&lt;/h3&gt;
&lt;h5 id=&#34;description&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;The cdEvents project standardises the way systems talk to each other, which enables Interoperability between systems so they speak a common language through the cdEvents spec in the event. Creating a capability in Jenkins X that can receive and sent a cdEvent would benefit the project and the DevOps ecosystem in general, by stopping glue code used to integrate systems and power innovation by letting end users swap out tools with no effort.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Ability to receive cdEvents&lt;/li&gt;
&lt;li&gt;Ability to parse cdEvents so Jenkins X understands them&lt;/li&gt;
&lt;li&gt;Ability to send cdEvents&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Jenkins X, Kubernetes, golang, cdEvents&lt;/p&gt;
&lt;h5 id=&#34;mentors&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/bradmccoydev&#34;&gt;Brad McCoy&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://cloudevents.io/&#34;&gt;https://cloudevents.io/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://www.youtube.com/watch?v=yg7RuDWHwV8&#34;&gt;https://www.youtube.com/watch?v=yg7RuDWHwV8&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://www.jenkins.io/projects/gsoc/2021/projects/cloudevents-plugin/&#34;&gt;https://www.jenkins.io/projects/gsoc/2021/projects/cloudevents-plugin/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://cdevents.dev/&#34;&gt;https://cdevents.dev/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/lighthouse&#34;&gt;https://github.com/jenkins-x/lighthouse&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Hard&lt;/p&gt;
&lt;h3 id=&#34;2-implement-drift-detection-gitops&#34;&gt;2. Implement drift detection (gitops)&lt;/h3&gt;
&lt;h5 id=&#34;description-1&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;Jenkins X only applies changes to cluster when contents of the gitops repository changes as part of a git pull request or git commit. This does not satisfy one of the requirements of the gitops model where we need continuous reconciliation. It would be nice to detect drift between the current state (kubernetes) and the desired state (git) and apply only those changes. This has the side effect of making the boot job faster.&lt;/p&gt;
&lt;p&gt;Also, our bootjob is made up of a makefile which calls cli commands written in golang, instead it would be desirable to move to a controller based approach similar to other tools in the kubernetes ecosystem.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-1&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Drift detection in Jenkins X&lt;/li&gt;
&lt;li&gt;Configurable interval when Jenkins X will do a drift detection and apply the changes&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-1&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Kubernetes, golang, Jenkins X, kubebuiler, basic understanding of gitops.&lt;/p&gt;
&lt;h5 id=&#34;mentors-1&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/rajatgupta24&#34;&gt;Rajat Gupta&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources-1&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://opengitops.dev/&#34;&gt;https://opengitops.dev/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://book.kubebuilder.io/&#34;&gt;https://book.kubebuilder.io/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-1&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-1&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Hard&lt;/p&gt;
&lt;h3 id=&#34;3-rbac-role-based-access-control-in-jenkins-x-ui&#34;&gt;3. RBAC (Role Based Access Control) in Jenkins X UI&lt;/h3&gt;
&lt;h5 id=&#34;description-2&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;In the last GSoC project, we created a modern UI which has more functionalities than the older viewer UI.
However, as we added the ability to start/stop pipelines from the new UI, this opened up an issue around access.
Users of Jenkins X would like to restrict who can start/stop pipelines from the UI.&lt;/p&gt;
&lt;p&gt;As we add more features to the UI involving repositories, this would also require ability to restrict access using RBAC (Role Based Access Control).
In addition, an audit trail would also help the users keep track of activities in the UI.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-2&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Fully functional Jenkins X Dashboard running in the kubernetes cluster&lt;/li&gt;
&lt;li&gt;Drop in replacement for existing read only UI&lt;/li&gt;
&lt;li&gt;Ability to restrict access in the UI&lt;/li&gt;
&lt;li&gt;Audit trail of who took what action in the UI&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-2&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;golang, basic understanding of sveltejs and sveltekit (or any modern js framework like react, vue. angular or solid) and kubernetes&lt;/p&gt;
&lt;h5 id=&#34;mentors-2&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/rajatgupta24&#34;&gt;Rajat Gupta&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources-2&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://youtu.be/AdNJ3fydeao&#34;&gt;https://youtu.be/AdNJ3fydeao&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://svelte.dev/&#34;&gt;https://svelte.dev/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://kit.svelte.dev/&#34;&gt;https://kit.svelte.dev/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://tailwindcss.com/&#34;&gt;https://tailwindcss.com/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://go.dev/tour/welcome/1&#34;&gt;https://go.dev/tour/welcome/1&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://casbin.org/&#34;&gt;https://casbin.org/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-2&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-2&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Medium&lt;/p&gt;
&lt;h3 id=&#34;4-simplifying-jenkins-x-pipeline-syntax&#34;&gt;4. Simplifying Jenkins X pipeline syntax&lt;/h3&gt;
&lt;h5 id=&#34;description-3&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;Jenkins X uses the raw tekton pipeline syntax for pipelines.
The issue with this syntax is that it&amp;rsquo;s too verbose.
The verbosity makes sense for low level pipeline building libraries like tektoncd, but for an user facing tool like Jenkins X, it makes the
pipeline files too big for no apparent reason.
We want to investigate a new syntax which will set the boilerplate so that the syntax is recognized by tekon, but is still user friendly like gitlab/github CI.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-3&#34;&gt;Expected outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Simpler and easier to understand pipeline syntax (for developers)&lt;/li&gt;
&lt;li&gt;More verbose pipeline syntax for power users (if there is a need)&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-3&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Golang, kubernetes, tekton, cue&lt;/p&gt;
&lt;h5 id=&#34;resources-3&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/cue-lang/cue&#34;&gt;https://github.com/cue-lang/cue&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;mentors-3&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/rajatgupta24&#34;&gt;Rajat Gupta&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-3&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-3&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Medium&lt;/p&gt;
&lt;h3 id=&#34;5-multi-tenancy-in-jenkins-x&#34;&gt;5. Multi-tenancy in Jenkins X&lt;/h3&gt;
&lt;h5 id=&#34;description-4&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;Installing multiple versions of Jenkins X in a single kubernetes cluster is not supported. There are both architectural and scalability issues around it. This would be beneficial for small teams within organizations who want to own their entire CI/CD platform instead of relying on a central release management team which can lead to more productive teams.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-4&#34;&gt;Expected outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;A multi-tenant enabled Jenkins X install (jenkins X in different namespaces or a central jx install controlling pipelines running for different tenants)&lt;/li&gt;
&lt;li&gt;Better scaling and security model for Jenkins X&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-4&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Golang, kubernetes, event driven architecture&lt;/p&gt;
&lt;h5 id=&#34;resources-4&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/enhancements/pull/46&#34;&gt;https://github.com/jenkins-x/enhancements/pull/46&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;mentors-4&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/rajatgupta24&#34;&gt;Rajat Gupta&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-4&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-4&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Hard&lt;/p&gt;
&lt;h3 id=&#34;next-steps&#34;&gt;Next Steps&lt;/h3&gt;
&lt;p&gt;If Jenkins X gets selected, we will create a followup blog with additional details.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: GSoC 2022 Final Report: Building Jenkins X UI</title>
      <link>https://jenkins-x.io/blog/2022/11/13/gsoc-2022-work-report/</link>
      <pubDate>Sun, 13 Nov 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/11/13/gsoc-2022-work-report/</guid>
      <description>
        
        
        &lt;h2 id=&#34;jenkins-x-new-ui&#34;&gt;Jenkins X New UI&lt;/h2&gt;
&lt;p&gt;It is a web application built with &lt;a href=&#34;https://go.dev/&#34;&gt;Golang&lt;/a&gt; for the backend and &lt;a href=&#34;https://kit.svelte.dev/&#34;&gt;Sveltekit&lt;/a&gt; for the frontend, both of which are built together and used in the same container.
To function properly, it must be installed as a helm chart with Jenkins X CRDs.&lt;/p&gt;
&lt;p&gt;🌟 It has light and dark themes.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/gsoc-work-report-22/homepage.png&#34; alt=&#34;homepage.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/gsoc-work-report-22/pipelinesPage.png&#34; alt=&#34;pipelinesPage.png&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;why-need-a-new-ui&#34;&gt;Why need a new UI?&lt;/h2&gt;
&lt;p&gt;A good UI is essential for a CI/CD tool, as not everyone is familiar with the CLI.
The current UI (jx-pipeline-visualizer) is a read-only UI, the user can view the logs of PipelineActivity but neither can start nor stop the pipeline.&lt;/p&gt;
&lt;p&gt;Features that the UI will provide:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Start and Stop a PipelineActivity.&lt;/li&gt;
&lt;li&gt;Have an audit trail.&lt;/li&gt;
&lt;li&gt;A graphical representation of PipelineActivity.&lt;/li&gt;
&lt;li&gt;RBAC to limit access to certain functionalities.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;New Jenkins X UI focus on Simplicity, Security and a Superb User Experience.&lt;/p&gt;
&lt;p&gt;This is NOT GA (General Availability) yet. Visit the project repo &lt;a href=&#34;https://github.com/jenkins-x/jx-ui&#34;&gt;here&lt;/a&gt; to try it.&lt;/p&gt;
&lt;h2 id=&#34;how-to-use-it&#34;&gt;How to use it?&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Go to the &lt;code&gt;helmfiles/jx/helmfile.yaml&lt;/code&gt; in your cluster repo.&lt;/li&gt;
&lt;li&gt;Replace &lt;strong&gt;jx-pipelines-visualizer&lt;/strong&gt; chart with the &lt;strong&gt;jx-ui&lt;/strong&gt; chart.
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- chart: jxgh/jx-ui
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  version: &amp;lt;latest-version&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  name: jx-ui
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  values:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  - ../../versionStream/charts/jxgh/jx-ui/values.yaml.gotmpl
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  - jx-values.yaml
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/li&gt;
&lt;li&gt;Do &lt;code&gt;git push&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;Add the code snippet to &lt;strong&gt;~/.config/ngrok/ngrok.yml&lt;/strong&gt; under &lt;code&gt;tunnels:&lt;/code&gt;.
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;ui:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;proto: http
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;addr: &lt;span style=&#34;color:#ae81ff&#34;&gt;9200&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;schemes:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  - http
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/li&gt;
&lt;li&gt;Add that domain to the ingress file, Run the following command and replace &lt;strong&gt;dashboard.jx.change.me&lt;/strong&gt; with ngrok link.
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl edit ing jx-ui
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;/li&gt;
&lt;li&gt;And boom, visit localhost:9200 and it works, you should see the homepage screen.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;work-done&#34;&gt;Work Done&lt;/h2&gt;
&lt;h3 id=&#34;stop-a-running-or-pending-pipelineactivity-from-ui&#34;&gt;Stop a running or pending PipelineActivity from UI&lt;/h3&gt;
&lt;p&gt;We have added a button in pipelines page and pipelineDetails page, it asks for confirmation and on selecting &lt;strong&gt;Yes&lt;/strong&gt; it will stop the PipelineActivity.&lt;/p&gt;
&lt;p&gt;We can stop the PipelineActivity from the pipelines tables.
&lt;img src=&#34;https://jenkins-x.io/images/gsoc-work-report-22/pipelinesPageStopBtn.png&#34; alt=&#34;pipelinesPageStopBtn.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;We can also stop the PipelineActivity from the pipelines details page.
&lt;img src=&#34;https://jenkins-x.io/images/gsoc-work-report-22/pipelineDetailsPageStopBtn.png&#34; alt=&#34;pipelineDetailsPageStopBtn.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Issue:&lt;/strong&gt; &lt;a href=&#34;https://github.com/jenkins-x/jx-ui/issues/28&#34;&gt;https://github.com/jenkins-x/jx-ui/issues/28&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;PRs:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-ui/pull/50&#34;&gt;https://github.com/jenkins-x/jx-ui/pull/50&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-ui/pull/51&#34;&gt;https://github.com/jenkins-x/jx-ui/pull/51&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-ui/pull/59&#34;&gt;https://github.com/jenkins-x/jx-ui/pull/59&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-ui/pull/75&#34;&gt;https://github.com/jenkins-x/jx-ui/pull/75&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;show-message-with-status-of-the-pipelineactivity&#34;&gt;Show message with status of the PipelineActivity&lt;/h3&gt;
&lt;p&gt;When a pipeline is cancelled or it has timedout, we update the status of the pipeline to cancelled or timed out.
However, we do not show the reason why a job was timed out.
That information should be displayed on the pipeline details page (along with the step which has timed out).
&lt;strong&gt;Issue:&lt;/strong&gt; &lt;a href=&#34;https://github.com/jenkins-x/jx-ui/issues/23&#34;&gt;https://github.com/jenkins-x/jx-ui/issues/23&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;PRs:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-api/pull/171&#34;&gt;https://github.com/jenkins-x/jx-api/pull/171&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-pipeline/pull/481&#34;&gt;https://github.com/jenkins-x-plugins/jx-pipeline/pull/481&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;implement-a-dag-for-pipelineactivity&#34;&gt;Implement a DAG for PipelineActivity&lt;/h3&gt;
&lt;p&gt;To make the UI more user friendly and to explain the sequence of the steps in a PipelineActivity, we have added a &lt;a href=&#34;https://en.wikipedia.org/wiki/Directed_acyclic_graph&#34;&gt;DAG&lt;/a&gt; (Directed Acyclic Graph) chart to graphically visualize the PipelineActivity.&lt;/p&gt;
&lt;p&gt;We used &lt;a href=&#34;https://d3js.org/&#34;&gt;D3.js&lt;/a&gt; library to create a custom component which create a DAG chart of PipelineActivity for us.
&lt;a href=&#34;https://github.com/d3/d3-hierarchy&#34;&gt;D3-hierarchy&lt;/a&gt; is an important part of our component.
We&amp;rsquo;re unit testing the component using &lt;a href=&#34;https://vitest.dev/&#34;&gt;vitest&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/gsoc-work-report-22/pipelineDetailsPage.png&#34; alt=&#34;pipelineDetailsPage.png&#34;&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Issue:&lt;/strong&gt; &lt;a href=&#34;https://github.com/jenkins-x/jx-ui/issues/48&#34;&gt;https://github.com/jenkins-x/jx-ui/issues/48&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;PRs:&lt;/strong&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-ui/pull/57/files&#34;&gt;https://github.com/jenkins-x/jx-ui/pull/57/files&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-ui/pull/65/files&#34;&gt;https://github.com/jenkins-x/jx-ui/pull/65/files&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;whats-next&#34;&gt;What&amp;rsquo;s next?&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;The UI project is just started, we have also start a seperate &lt;strong&gt;UI-sig&lt;/strong&gt; which you can join from &lt;a href=&#34;https://jenkins-x.io/community/#office-hours&#34;&gt;calendar&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;There are some amazing features that we are planning to add to the new UI:
&lt;ul&gt;
&lt;li&gt;Dynamically update the list of pipelines&lt;/li&gt;
&lt;li&gt;Upgrade version stream from the UI&lt;/li&gt;
&lt;li&gt;Import repositories using the UI&lt;/li&gt;
&lt;li&gt;Break down pipeline logs into individual steps&lt;/li&gt;
&lt;li&gt;Mask secrets in the logs&lt;/li&gt;
&lt;li&gt;Display logs for cancelled and timed out pipelines&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;To read more read the issues created &lt;a href=&#34;https://github.com/jenkins-x/jx-ui/issues&#34;&gt;here&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;acknowledgements&#34;&gt;Acknowledgements&lt;/h2&gt;
&lt;p&gt;I never imagined I would be this sad after finishing an internship.
Just as Osama noted in his &lt;a href=&#34;https://jenkins-x.io/blog/2022/11/08/gsoc-2022/&#34;&gt;work report&lt;/a&gt;, this was the most difficult experience we have had thus far, but the encouragement of the jx community and the direction of our mentor made it the best educational experience I have ever had.&lt;/p&gt;
&lt;p&gt;I learned a lot here, but there are still many things I need to learn (I haven&amp;rsquo;t finished my 30-day plan yet). I knew I could learn a lot from open source, but I didn&amp;rsquo;t expect this much.
In addition, I think the CD Foundation is very special, and the community and the ways in which we can collaborate with other projects are also very valuable.&lt;/p&gt;
&lt;p&gt;I started my intern by attending conferences like kubecon and CD Summit, we started &lt;strong&gt;UI-SIG&lt;/strong&gt;, and in the last 2 months we&amp;rsquo;ve given 3 talks about Jenkins X.
As I mentioned above there are still thing to do in the UI project and since we all loved the GSoC program, I&amp;rsquo;d love to became a part of it in future with Jenkins X.&lt;/p&gt;
&lt;p&gt;Again &lt;strong&gt;Big Thanks&lt;/strong&gt; to all my mentor &lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit&lt;/a&gt;, &lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christoffer&lt;/a&gt;, &lt;a href=&#34;https://github.com/msvticket&#34;&gt;Marten&lt;/a&gt;, &lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom&lt;/a&gt; and gsoc fellow &lt;a href=&#34;https://github.com/osamamagdy&#34;&gt;Osama&lt;/a&gt; and JX community for such a great opportunity.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Hacktoberfest 2022</title>
      <link>https://jenkins-x.io/blog/2022/10/03/hacktoberfest2022/</link>
      <pubDate>Mon, 03 Oct 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/10/03/hacktoberfest2022/</guid>
      <description>
        
        
        &lt;p&gt;We are excited to announce that Jenkins X will be participating in Hacktoberfest again this year!
Hacktoberfest is a month-long global celebration of open source software.&lt;/p&gt;
&lt;p&gt;All backgrounds and skill levels are encouraged to participate in Hacktoberfest and join a global community of open source contributors.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Learn more about Hacktoberfest and sign up &lt;a href=&#34;https://hacktoberfest.digitalocean.com/&#34;&gt;here&lt;/a&gt;.&lt;/strong&gt;&lt;/p&gt;
&lt;h3 id=&#34;contribute-to-jenkins-x&#34;&gt;Contribute to Jenkins X&lt;/h3&gt;
&lt;p&gt;We welcome your contributions to the &lt;a href=&#34;https://github.com/jenkins-x/jx&#34;&gt;Jenkins X project&lt;/a&gt;!&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx/issues?q=is%3Aissue+label%3Ahacktoberfest+is%3Aopen&#34;&gt;Issues labelled &amp;ldquo;hacktoberfest&amp;rdquo;&lt;/a&gt; generally indicate good first issues.
However, all pull requests will count towards your Hacktoberfest challenge.&lt;/p&gt;
&lt;p&gt;Refer to the contribution guides for making &lt;a href=&#34;https://jenkins-x.io/community/code/&#34;&gt;code&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/community/documentation/&#34;&gt;documentation&lt;/a&gt; changes.&lt;/p&gt;
&lt;p&gt;Refer to &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/source/&#34;&gt;this document&lt;/a&gt; to get an idea about the location of the different Jenkins X source code repositories.
Normally the labels assigned to the ticket will help you in deciding which part of the Jenkins X codebase to look at.
The maintainers will also try to link the relevant repository for hacktoberfest issues in the issue comment.&lt;/p&gt;
&lt;p&gt;Once you are done with the contribution, request a review from the maintainers by adding the comment in your pull request.&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;/cc @ankitm123 @babadofar @msvticket @osamamagdy @rajatgupta24 @tomhobson
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h3 id=&#34;ask-us-questions&#34;&gt;Ask us questions&lt;/h3&gt;
&lt;p&gt;We&amp;rsquo;re happy to help if you have any questions. Talk to us on our slack channels, which are part of the Kubernetes slack. Join Kubernetes slack &lt;a href=&#34;http://slack.k8s.io/&#34;&gt;here&lt;/a&gt; and find us on our channels:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;#jenkins-x-dev for developers of Jenkins X&lt;/li&gt;
&lt;li&gt;#jenkins-x-user for users of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Find out more about becoming involved in the Jenkins X community &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;We look forward to seeing you in open source, fixing all the things!&lt;/em&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: GSoC 2022 Community Bonding Period with Jenkins X</title>
      <link>https://jenkins-x.io/blog/2022/07/12/gsoc2022-community-bonding-period/</link>
      <pubDate>Tue, 12 Jul 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/07/12/gsoc2022-community-bonding-period/</guid>
      <description>
        
        
        &lt;h2 id=&#34;introduction&#34;&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Hello everyone, I am Rajat Gupta, pursuing my bachelor&amp;rsquo;s in Information Technology.
In 2022, I have been selected as a student developer in Google Summer of Code under Jenkins X.
We will be building a new UI for Jenkins X. I got this news on May 20th, as I received an email from google.&lt;/p&gt;
&lt;h2 id=&#34;how-i-started&#34;&gt;How I started&lt;/h2&gt;
&lt;p&gt;The technologies needed were &lt;strong&gt;Golang&lt;/strong&gt;, &lt;strong&gt;Kubernetes&lt;/strong&gt;, and &lt;strong&gt;GitOps&lt;/strong&gt;.
I used golang only once before, while linting Jenkins X codebase, I only used Kubernetes once before while setting up a k3s cluster to run Jenkins X pipelines. These tasks were necessary to do for all GSoC participants. Apart from that, I was a total beginner.&lt;/p&gt;
&lt;h2 id=&#34;what-i-learned-during-community-bonding-period&#34;&gt;What I learned during Community Bonding Period&lt;/h2&gt;
&lt;p&gt;So, when I got selected, I had a lot to learn, my mentors gave me a &lt;strong&gt;30 Day plan&lt;/strong&gt;.
They also suggested some resources and conference talks which made it simple for me to start.&lt;/p&gt;
&lt;p&gt;30 Day plan was:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Learn &lt;strong&gt;golang&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Getting started with &lt;strong&gt;Kubernetes&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Learn what is a &lt;strong&gt;CRD&lt;/strong&gt; and how they are used?&lt;/li&gt;
&lt;li&gt;Complete a tutorial on &lt;strong&gt;Kubebuilder&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Getting started with &lt;strong&gt;Tekton&lt;/strong&gt; pipelines&lt;/li&gt;
&lt;li&gt;Learn &lt;strong&gt;Jenkins X&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We also had some amazing pair programming sessions, where I used to share my screen and my mentor guided me through, which is not common because mentors have a very busy schedule.
But my mentors helped me a lot.
These sessions helped me in working with the massive Jenkins X codebase and learning its complex workflows.&lt;/p&gt;
&lt;p&gt;I also learned that testing and documentation are very important as they make it easier for developers to understand these workflows.
Hence testing also became an important part of my learning period.&lt;/p&gt;
&lt;p&gt;We also started the &lt;strong&gt;UI-sig&lt;/strong&gt; a week or two after my selection where we work on Jenkins X UI.
The learning I did in this community bonding period was just amazing, I learned more in 3 weeks than that what I learned in the past 3 months.&lt;/p&gt;
&lt;h2 id=&#34;highlights&#34;&gt;Highlights&lt;/h2&gt;
&lt;p&gt;I also attended the &lt;strong&gt;kubeCon&lt;/strong&gt;, &lt;strong&gt;cdCon&lt;/strong&gt;, and &lt;strong&gt;Jenkins X Contributor Summit 2022&lt;/strong&gt; during this period.
When I meet other contributors of Jenkins X, people from CD Foundation were very excited about our plans for the future.
I also gave a small introduction to my project.&lt;/p&gt;
&lt;p&gt;If you are looking for a project where you can learn about CI/CD, DevOps, Cloud, Golang, Jenkins X is the best place for you.&lt;/p&gt;
&lt;p&gt;Thanks to all my mentors &lt;a href=&#34;https://github.com/ankitm123&#34;&gt;@ankitm123&lt;/a&gt;, &lt;a href=&#34;https://github.com/babadofar&#34;&gt;@babadofar&lt;/a&gt;, &lt;a href=&#34;https://github.com/msvticket&#34;&gt;@msvticket&lt;/a&gt;, and &lt;a href=&#34;https://github.com/tomhobson&#34;&gt;@tomhobson&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Kubernetes 1.22 - Breaking change!</title>
      <link>https://jenkins-x.io/blog/2022/04/22/kubernetes-1.22-tekton/</link>
      <pubDate>Fri, 22 Apr 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/04/22/kubernetes-1.22-tekton/</guid>
      <description>
        
        
        &lt;p&gt;To allow Jenkins X to support Kubernetes 1.22, we had to update our version of Tekton. This updated version of Tekton contains breaking changes that has consequences if you made your own custom Jenkins X pipelines.&lt;/p&gt;
&lt;p&gt;To make sure that your custom pipelines continue to work after this upgrade, you must edit the resource settings in your pipelines. Otherwise your pipelines will most likely not be able to start at all, or if they do, consume a lot of resources.&lt;/p&gt;
&lt;h4 id=&#34;changes-in-tekton-version-28&#34;&gt;Changes in Tekton version 28&lt;/h4&gt;
&lt;p&gt;Tekton made changes in how to calculate the resources needed to run a pipeline, in order to support the concept of &lt;a href=&#34;https://kubernetes.io/docs/concepts/policy/limit-range/&#34;&gt;LimitRange&lt;/a&gt; in Kubernetes (introduced in Kubernetes version 1.10). Previously, Tekton simply used the maximum requested cpu and memory of any single step, and set that as limits for the all steps in the pipeline.&lt;/p&gt;
&lt;p&gt;For more details, please read the
&lt;a href=&#34;https://tekton.dev/vault/pipelines-v0.30.x/limitrange/&#34;&gt;Tekton documentation on LimitRange&lt;/a&gt;.&lt;/p&gt;
&lt;h4 id=&#34;how-to-prepare-for-upgrade&#34;&gt;How to prepare for upgrade&lt;/h4&gt;
&lt;p&gt;In the Tekton pipeline files, the StepTemplate needs to be changed to not specify resource &lt;code&gt;requests&lt;/code&gt;, but only setting an empty resource &lt;code&gt;limits&lt;/code&gt;:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;stepTemplate&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:jenkins-x/jx3-pipeline-catalog/tasks/go/release.yaml@a5ab19ebc5a074e0402c5016b11bc11b32cc5c83&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;resources&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#75715e&#34;&gt;# override limits for all containers here&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;limits&lt;/span&gt;: {}
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;The resource &lt;code&gt;requests&lt;/code&gt; should be set on only one individual step:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;steps&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  - &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:Mentor-Medier/jx3-pipeline-catalog/tasks/git-clone/git-clone-pr.yaml@versionStream&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;resources&lt;/span&gt;: {}
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;jx-variables&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;resources&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      &lt;span style=&#34;color:#f92672&#34;&gt;requests&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;cpu&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;400m&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;memory&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;512Mi&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;To see examples of what changes you need to apply to your custom pipelines you may investigate &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/pull/984/files&#34;&gt;this PR&lt;/a&gt; on The Jenkins X pipeline catalog. The PR will be merged and released simultaneous with the upgrade of Tekton.&lt;/p&gt;
&lt;p&gt;In the current version of Tekton used by Jenkins X, the resource &lt;code&gt;requests&lt;/code&gt; are set on the stepTemplate. Running the old pipelines in the new version will lead to resource &lt;code&gt;requests&lt;/code&gt; being multiplied by the number of steps.&lt;/p&gt;
&lt;p&gt;To prepare for upgrade, you should create a PR applying the changes described above. We done some tests on applying the changes to the current version of Jenkins X/Tekton, and it seemed to work. But - that does not mean it will work on your machines or even pipelines!&lt;/p&gt;
&lt;p&gt;So, please prepare for upgrade now! We want people to have a safe upgrade experience. If you have questions, you can find us on &lt;a href=&#34;https://kubernetes.slack.com/messages/C9MBGQJRH&#34;&gt;Slack&lt;/a&gt;.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Google Summer of Code 2022 project proposal template ☀️</title>
      <link>https://jenkins-x.io/blog/2022/04/05/gsoc2022-proposal-template/</link>
      <pubDate>Tue, 05 Apr 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/04/05/gsoc2022-proposal-template/</guid>
      <description>
        
        
        &lt;h3 id=&#34;proposal-template&#34;&gt;Proposal template&lt;/h3&gt;
&lt;h4 id=&#34;1-contact-details&#34;&gt;1. Contact details&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;Full name:&lt;/li&gt;
&lt;li&gt;Country:&lt;/li&gt;
&lt;li&gt;Time zone:&lt;/li&gt;
&lt;li&gt;Email:&lt;/li&gt;
&lt;li&gt;Github ID:&lt;/li&gt;
&lt;li&gt;Personal blog (optional):&lt;/li&gt;
&lt;li&gt;Twitter/LinkedIn/others:&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;2-gsoc-information&#34;&gt;2. GSOC information&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;Have you participated in the Google Summer of Code previously? Please describe your experience.&lt;/li&gt;
&lt;li&gt;Are you applying to any other organizations this year? If so, please list them.&lt;/li&gt;
&lt;li&gt;How many hours will you devote to your GSoC project each week? Do you have any other commitments during the summer?&lt;/li&gt;
&lt;li&gt;Have you ever contributed code to Jenkins X? If you have, post the Pull Request (PR) links (It&amp;rsquo;s ok if they have not been merged/approved yet)&lt;/li&gt;
&lt;li&gt;Do you plan on contributing to the Jenkins X project after GSoC is finished?&lt;/li&gt;
&lt;li&gt;Were you able to install Jenkins X locally on your laptop?
&lt;ul&gt;
&lt;li&gt;If no, please explain why (Unsupported architecture, missing documentation, time constraints etc)?&lt;/li&gt;
&lt;li&gt;If yes, how was the installation experience (missing documentation, complexity etc)?&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Have you used kubernetes in the past? Please provide a brief description and if possible links to the work.&lt;/li&gt;
&lt;li&gt;Have you used golang in the past? Please provide a brief description and if possible some code samples.&lt;/li&gt;
&lt;li&gt;(If you are interested in the UI project) Have you worked with a frontend framework/library in the past? Please provide a brief description and if possible some code samples.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;3-project-idea&#34;&gt;3. Project idea&lt;/h4&gt;
&lt;p&gt;Repeat this section for as many project ideas as you want (Go in the order most likely to least likely).&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Title of the idea that you are interested in&lt;/li&gt;
&lt;li&gt;Brief description of the idea.&lt;/li&gt;
&lt;li&gt;Have you worked on a similar project in the past? If yes, please provide a brief description (with links if possible)&lt;/li&gt;
&lt;li&gt;How will the project benefit Jenkins X and the community
&lt;ul&gt;
&lt;li&gt;Will it help in driving adoption of Jenkins X? If yes, then how/why?&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Deliverables
&lt;ul&gt;
&lt;li&gt;Include any milestones and deadlines&lt;/li&gt;
&lt;li&gt;Include time for investigation, coding and documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Project proposal for Google Season of Docs 2022 📄</title>
      <link>https://jenkins-x.io/blog/2022/03/23/gsod2022-proposal/</link>
      <pubDate>Wed, 23 Mar 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/03/23/gsod2022-proposal/</guid>
      <description>
        
        
        &lt;p&gt;We have put together a project proposal as part of our application to participate in the Google Season of Docs 2022 program.&lt;/p&gt;
&lt;h3 id=&#34;project-proposal&#34;&gt;Project proposal&lt;/h3&gt;
&lt;h4 id=&#34;better-documentation-for-real-world-use-cases---jenkins-x&#34;&gt;Better documentation for real world use cases - Jenkins X&lt;/h4&gt;
&lt;h5 id=&#34;about-us&#34;&gt;About us&lt;/h5&gt;
&lt;p&gt;Jenkins X provides automated CI/CD for Kubernetes with Preview Environments on Pull Requests using Cloud Native pipelines from Tekton.&lt;/p&gt;
&lt;h5 id=&#34;problem&#34;&gt;Problem&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;End users of Jenkins X are unable to find information on how to use Jenkins X for real world use cases which includes:
&lt;ul&gt;
&lt;li&gt;Production best practices&lt;/li&gt;
&lt;li&gt;Scanning images in Jenkins X pipelines&lt;/li&gt;
&lt;li&gt;How to make your app use different configuration/secrets for each environment&lt;/li&gt;
&lt;li&gt;Observability for your apps, logging, metrics, tracing&lt;/li&gt;
&lt;li&gt;Tests (Integration, e2e)&lt;/li&gt;
&lt;li&gt;Artifact management&lt;/li&gt;
&lt;li&gt;Multi cluster&lt;/li&gt;
&lt;li&gt;Integration with other tools in the cloud native sector&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;project-scope&#34;&gt;Project scope&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Audit the current Jenkins X documentation and create a friction log&lt;/li&gt;
&lt;li&gt;Use the friction log as a guide for understanding the gaps in the documentation&lt;/li&gt;
&lt;li&gt;Interact with the Jenkins X community to create a list of top use cases
&lt;ul&gt;
&lt;li&gt;Create a survey&lt;/li&gt;
&lt;li&gt;Look at the github issues and slack messages&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Work with the volunteers to incorporate those changes into the documentation&lt;/li&gt;
&lt;li&gt;Establish a feedback loop (the target customers are the end users of Jenkins X) to improve the documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;measuring-project-success&#34;&gt;Measuring project success&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Decrease in the number of github issues raised by end users on documentation related to common real world use cases&lt;/li&gt;
&lt;li&gt;Short 1-2 minute videos on common tasks that end users of Jenkins X would like to perform.&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Must have:
&lt;ul&gt;
&lt;li&gt;Experience with github&lt;/li&gt;
&lt;li&gt;Communication skills to work with the Jenkins X community&lt;/li&gt;
&lt;li&gt;Creating online surveys&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Nice to have:
&lt;ul&gt;
&lt;li&gt;Basic experience with docker compose (local development scripts use compose)&lt;/li&gt;
&lt;li&gt;Good video editing skills.&lt;/li&gt;
&lt;li&gt;Some knowledge working with the documentation of other tools in the kubernetes ecosystem&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;mentorsvolunteers&#34;&gt;Mentors/Volunteers&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christoffer Vig&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/msvticket&#34;&gt;Mårten Svantesson&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom Hobson&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;timeline&#34;&gt;Timeline&lt;/h3&gt;
&lt;p&gt;The project will take roughly 6 months to complete.
Once the technical writer is selected, we will do an orientation to bring him up to speed.
This is the timeline we have in mind, but we are flexible.&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Dates&lt;/th&gt;
&lt;th style=&#34;text-align:center&#34;&gt;Action Item&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;April 14 - May 16, 2022&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;Hire technical writer&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;April 14 - May 31, 2022&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;Orientation after hiring technical writer&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;June 1 - July 31&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;Review documentation, create actions items, get familiar with Jenkins X&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;August 1 - October 31&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;Work on the project&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;November&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;Project completion&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h3 id=&#34;budget&#34;&gt;Budget&lt;/h3&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Budget item&lt;/th&gt;
&lt;th style=&#34;text-align:center&#34;&gt;Amount&lt;/th&gt;
&lt;th style=&#34;text-align:right&#34;&gt;Running Total&lt;/th&gt;
&lt;th&gt;Notes&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Technical writer stipend&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;6000&lt;/td&gt;
&lt;td style=&#34;text-align:right&#34;&gt;6000&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Volunteer stipend&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;2000&lt;/td&gt;
&lt;td style=&#34;text-align:right&#34;&gt;8000&lt;/td&gt;
&lt;td&gt;4 volunteer stipend (500 each) X 4&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Jenkins X t-shirts&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;300&lt;/td&gt;
&lt;td style=&#34;text-align:right&#34;&gt;8300&lt;/td&gt;
&lt;td&gt;20 t-shirts X 15&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Shipping for t-shirts&lt;/td&gt;
&lt;td style=&#34;text-align:center&#34;&gt;300&lt;/td&gt;
&lt;td style=&#34;text-align:right&#34;&gt;8600&lt;/td&gt;
&lt;td&gt;15 dollars to ship, shipping rates can vary&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h4 id=&#34;notes-about-budget&#34;&gt;Notes about budget&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;The cost of the t-shirt was taken from &lt;a href=&#34;https://store.cd.foundation/collections/jenkinsx&#34;&gt;here&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;The t-shirts are for the technical writer, volunteers and any member of the jenkins X community (not officially listed as a volunteer) who helps out by answering the technical writer&amp;rsquo;s questions.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;additional-information&#34;&gt;Additional information&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;Previous participation in Season of Docs, Google Summer of Code or others
&lt;ul&gt;
&lt;li&gt;Jenkins X participated in the 2020 Season of &lt;a href=&#34;https://jenkins-x.io/blog/2020/04/28/season-of-docs-2020/&#34;&gt;docs&lt;/a&gt;. The maturity level matrix created by the technical writer is still used by the community to evaluate if Jenkins X will work for their use case, as well as used by the Jenkins X maintainers to plan the roadmap for improving Jenkins X.&lt;/li&gt;
&lt;li&gt;Jenkins X is also participating in the &lt;a href=&#34;https://jenkins-x.io/blog/2022/03/12/gsoc2022-followup/&#34;&gt;google summer of code 2022&lt;/a&gt;. We are seeing a lot of interest from new contributors. We are confident it will lead to some amazing improvements in the Jenkins X ecosystem and make it a sustainable open source project. We expect the technical writer will help the contributors create better documentation for their work.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;other-ideas&#34;&gt;Other ideas&lt;/h3&gt;
&lt;h4 id=&#34;2-reorganize-documentation-to-make-it-more-user-friendly-and-easy-to-search&#34;&gt;2. Reorganize documentation to make it more user friendly and easy to search&lt;/h4&gt;
&lt;h5 id=&#34;problem-1&#34;&gt;Problem&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;The documentation does not feel coherent, it does not read like a book from start to finish
&lt;ul&gt;
&lt;li&gt;There&amp;rsquo;s no clear flow about how people should read documentation and no &amp;ldquo;next step&amp;rdquo; once they&amp;rsquo;ve finished reading a page.&lt;/li&gt;
&lt;li&gt;There&amp;rsquo;s also a lot of missing &lt;em&gt;assumed&lt;/em&gt; knowledge in the documentation which makes it hard for new users to form a mental picture of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Results from older documentation sometimes shows up higher than newer results creating confusion for users&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;how-would-we-measure-success&#34;&gt;How would we measure success?&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;The number of repeated searches decrease (adding / removing terms)&lt;/li&gt;
&lt;li&gt;Decrease in the number of github issues raised by users on documentation related to missing information&lt;/li&gt;
&lt;li&gt;Decrease in slack messages from users not finding relevant information in the documentation.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;3-improve-contributordeveloper-documentation-on-how-to-extend-jenkins-x&#34;&gt;3. Improve contributor/developer documentation on how to extend Jenkins X&lt;/h4&gt;
&lt;h5 id=&#34;problem-2&#34;&gt;Problem&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;It is not clear from our documentation how to
&lt;ul&gt;
&lt;li&gt;add support for a new cloud provider&lt;/li&gt;
&lt;li&gt;add support for a new git/scm provider&lt;/li&gt;
&lt;li&gt;add a new quick start&lt;/li&gt;
&lt;li&gt;add new language packs&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;how-would-we-measure-success-1&#34;&gt;How would we measure success?&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Increase in number of contributions to add support for more cloud providers&lt;/li&gt;
&lt;li&gt;Increase in number of contributions to add add or extend quickstart guides&lt;/li&gt;
&lt;li&gt;Decrease in slack messages from users not finding relevant information in the documentation.&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Google Summer of Code 2022 ☀️</title>
      <link>https://jenkins-x.io/blog/2022/03/12/gsoc2022-followup/</link>
      <pubDate>Sat, 12 Mar 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/03/12/gsoc2022-followup/</guid>
      <description>
        
        
        

&lt;div class=&#34;alert alert-primary&#34; role=&#34;alert&#34;&gt;


    Project proposal template can be found &lt;a href=&#34;https://jenkins-x.io/blog/2022/04/05/gsoc2022-proposal-template/&#34;&gt;here&lt;/a&gt;.

&lt;/div&gt;

&lt;p&gt;We are very happy to announce that Jenkins X has been selected to participate in the Google Summer of Code (GSoC) 2022!&lt;/p&gt;
&lt;p&gt;If you are new to GSoC and want to learn more about it, check out their new &lt;a href=&#34;https://summerofcode.withgoogle.com/&#34;&gt;site&lt;/a&gt;.
You can find the list of project ideas from Jenkins X &lt;a href=&#34;https://jenkins-x.io/blog/2022/02/20/gsoc2022-ideas/&#34;&gt;here&lt;/a&gt;.
If you are interested in applying to Jenkins X, please check the &lt;a href=&#34;https://developers.google.com/open-source/gsoc/timeline&#34;&gt;timeline&lt;/a&gt;.
Apply as early as possible.&lt;/p&gt;
&lt;p&gt;This post aims to give GSoC contributors insight into the selection process and how to get started.&lt;/p&gt;
&lt;h3 id=&#34;how-many-contributors-are-we-looking-for&#34;&gt;How many contributors are we looking for?&lt;/h3&gt;
&lt;p&gt;We have 3 mentors signed up at the moment and are looking to select a maximum of 2 applicants.&lt;/p&gt;
&lt;p&gt;We want you to have a great experience contributing to Jenkins X and learn lots of new things!&lt;/p&gt;
&lt;h3 id=&#34;what-are-we-looking-for-in-an-ideal-jenkins-x-contributor&#34;&gt;What are we looking for in an ideal Jenkins X contributor?&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;Willingness to learn Jenkins X and engage with the community&lt;/li&gt;
&lt;li&gt;Independence and a drive to investigate and propose solutions to complex issues that might occur during implementation&lt;/li&gt;
&lt;li&gt;(Optional) Eventually become a Jenkins X maintainer (and some day mentor new GSoC contributors)!&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;what-can-prospective-contributors-do-march-7---april-19&#34;&gt;What can prospective contributors do? (March 7 - April 19)&lt;/h3&gt;
&lt;p&gt;You do not have to complete all of these tasks.
This is presented here so that you have some clarity around where to start and which resources to follow.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Recommended: Join the jenkins X community &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;slack channels&lt;/a&gt; and say hello :)
&lt;ul&gt;
&lt;li&gt;We prefer you post messages in the jenkins-x-dev channel&lt;/li&gt;
&lt;li&gt;Attend the &lt;a href=&#34;https://jenkins-x.io/community/#office-hours&#34;&gt;office hours&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;Recommended: Interact with potential mentors to understand/review the requirements of the projects.&lt;/li&gt;
&lt;li&gt;Recommended: Start working on your proposal early on.&lt;/li&gt;
&lt;li&gt;Optional: Learn about &lt;a href=&#34;https://youtu.be/3c-iBn73dDE&#34;&gt;docker&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Optional: Learn about &lt;a href=&#34;https://youtu.be/X48VuDVv0do&#34;&gt;kubernetes&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Optional: Learn the basics of &lt;a href=&#34;https://go.dev/tour/list&#34;&gt;golang&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Optional: Understand Jenkins X concepts and fundamentals by going over the &lt;a href=&#34;https://jenkins-x.io/&#34;&gt;documentation&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Optional: Set up Jenkins X locally and give it a go (Please don&amp;rsquo;t spend money running Jenkins X in the cloud).
&lt;ul&gt;
&lt;li&gt;We prefer you use &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/k3s/&#34;&gt;k3s&lt;/a&gt; for this, as it&amp;rsquo;s less resource intensive and can be installed locally on your workstation (linux). Mac users need to install something like multipass to first install k3s.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;interview-process-and-selection-criteria-april-19-and-may-12&#34;&gt;Interview process and selection criteria (April 19 and May 12)&lt;/h3&gt;
&lt;p&gt;We will start interviewing candidates between April 19 and May 12.
We want to talk to you individually, and get to know you better.&lt;/p&gt;
&lt;p&gt;Contributors will be scored based on the following criteria:&lt;/p&gt;
&lt;p&gt;Important:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Independent thinker and willingness to learn&lt;/li&gt;
&lt;li&gt;Project proposal demonstrating good understanding of the project they are interested to work on&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Nice to have:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Technical expertise (basic knowledge goes a long way):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Past experience with container technology&lt;/li&gt;
&lt;li&gt;Past experience with kubernetes&lt;/li&gt;
&lt;li&gt;Past experience with golang&lt;/li&gt;
&lt;li&gt;Past experience with a Frontend UI library (if interested to contribute to the UI project)&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Past open source contribution experience&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Any level of familiarity with Jenkins X (or other CI/CD tools)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Complete one of the three tasks listed below (If you have any questions on these tasks, please ask in our slack channel and we&amp;rsquo;ll be happy to answer your questions):&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;If you have already contributed to Jenkins X, then share the GitHub links to your pull requests. Your mentor will be happy to discuss them with you and will want to know more about what you did and why you did it.&lt;/li&gt;
&lt;li&gt;Walk us through a local Jenkins X set up (Please don&amp;rsquo;t spend money running Jenkins X in the cloud)&lt;/li&gt;
&lt;li&gt;Refactor a single function within the Jenkins X organization to improve the code quality. Clone the library, make refactoring changes, describe your changes and zip up and submit to a mentor via slack. Explain your refactoring changes and why you did them.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Previous GSoC experience (first time contributors are more than welcome)&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We will make an effort to talk individually to all the Jenkins X GSoC contributor applicants.&lt;/p&gt;
&lt;p&gt;We look forward to reviewing your application and working with you.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Project ideas for Google Summer of Code 2022 ☀️</title>
      <link>https://jenkins-x.io/blog/2022/02/20/gsoc2022-ideas/</link>
      <pubDate>Sun, 20 Feb 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/02/20/gsoc2022-ideas/</guid>
      <description>
        
        
        

&lt;div class=&#34;alert alert-primary&#34; role=&#34;alert&#34;&gt;


    &lt;p&gt;Jenkins X has been accepted into the Google Summer of Code 2022 program, take a look at the &lt;a href=&#34;https://jenkins-x.io/blog/2022/03/12/gsoc2022-followup/&#34;&gt;follow up blog&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Project proposal template can be found &lt;a href=&#34;https://jenkins-x.io/blog/2022/04/05/gsoc2022-proposal-template/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;


&lt;/div&gt;

&lt;p&gt;We have put together some project ideas as part of our application to participate in the Google Summer of Code 2022 program.&lt;/p&gt;
&lt;h3 id=&#34;1-cloud-events-integration-with-jenkins-x&#34;&gt;1. Cloud events integration with Jenkins X&lt;/h3&gt;
&lt;h5 id=&#34;description&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;The only way to trigger jobs/workflows in Jenkins X at the moment is by listening to events from Source Control Management (SCM) providers like github, gitlab, bitbucket, however it would be nice to listen to other event sources and trigger jobs/pipelines in Jenkins X.
One interesting application would be to trigger some Jenkins X job in response to some alerting event (pagerduty, opsgenie).
As a start we should focus on (emitting and listening to) cloudevents which define a common format for events produced from different sources.
This will also help make Jenkins X compatible with other platforms.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Jenkins X should be able to emit cloud events&lt;/li&gt;
&lt;li&gt;Jenkins X should be able to listen to cloud events, and run pipelines&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Golang, kubernetes, cloudevents, familiarity with lighthouse would be great, but not required&lt;/p&gt;
&lt;h5 id=&#34;mentors&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christopher Vig&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom Hobson&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://cloudevents.io/&#34;&gt;https://cloudevents.io/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://www.youtube.com/watch?v=yg7RuDWHwV8&#34;&gt;https://www.youtube.com/watch?v=yg7RuDWHwV8&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://www.jenkins.io/projects/gsoc/2021/projects/cloudevents-plugin/&#34;&gt;https://www.jenkins.io/projects/gsoc/2021/projects/cloudevents-plugin/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://cdevents.dev/&#34;&gt;https://cdevents.dev/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/lighthouse&#34;&gt;https://github.com/jenkins-x/lighthouse&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Hard&lt;/p&gt;
&lt;h3 id=&#34;2-supply-chain-security-improve-integration-with-sigstore-and-look-at-tekton-chains&#34;&gt;2. Supply chain security: Improve integration with sigstore and look at tekton chains&lt;/h3&gt;
&lt;h5 id=&#34;description-1&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;With all the software breach that has happened recently, it has become necessary to add tooling to solve the issue around supply chain security.
There are some good open source tools which can help with that (sigstore tools).
As a CI/CD platform, Jenkins X needs to be integrated with them so that the end users can get this feature out of the box.
Jenkins X leverages tekton as it&amp;rsquo;s pipeline execution engine.
However, we dont integrate with tekton chain yet.
Also similar to tekton chains, we should have a jenkins X operator that can take a snapshot of the jx pipeline activities or lighthouse jobs, sign them and store them in a cloud store eventually.
Catalog should be updated to include trivy tasks, so that users can start using them with no to minimal effort.
As a start, we should start signing the various artifacts produced by Jenkins X (binaries, docker images, helm charts).&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-1&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Jenkins X artifacts (helm charts, docker images, binaries) are all cryptographically signed.&lt;/li&gt;
&lt;li&gt;Integration with tekton chains&lt;/li&gt;
&lt;li&gt;An operator which can take snapshot of the jx pipeline activities, sign them and store them in the cloud storage.&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-1&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;golang, kubernetes, (basic) understanding of security&lt;/p&gt;
&lt;h5 id=&#34;mentors-1&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christopher Vig&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom Hobson&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources-1&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://youtu.be/SqgkbCKp8kE&#34;&gt;https://youtu.be/SqgkbCKp8kE&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/sigstore&#34;&gt;https://github.com/sigstore&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://itnext.io/sigstore-a-solution-to-software-supply-chain-security-35bc96bddad5&#34;&gt;https://itnext.io/sigstore-a-solution-to-software-supply-chain-security-35bc96bddad5&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://tekton.dev/docs/chains/&#34;&gt;https://tekton.dev/docs/chains/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-1&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-1&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Medium&lt;/p&gt;
&lt;h3 id=&#34;3-new-jenkins-x-ui&#34;&gt;3. New Jenkins X UI&lt;/h3&gt;
&lt;h5 id=&#34;description-2&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;Currently, the way to manage (CRUD) Jenkins X resources(pipelines) is by using the cli.
While the CLI is very powerful and user friendly, it should be used by power users (release team who installs and manages jenkins x clusters).
We should not expect developers who are concerned with only the pipelines to install the cli (This does not scale when you have 100+ developers in the company)
We do have a UI/dashboard, but it is read only, so users cannot use it to trigger release pipelines or stop running pipelines.
In addition, we do not have an audit trail of who did what.
So, we propose a new UI/dashboard which has feature parity with the CLI (including SSO and RBAC)
The UI should make the JX cli redundant, and add more value to the user with easily available status and logs of the entire cluster&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-2&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Fully functional Jenkins X Dashboard running in the kubernetes cluster&lt;/li&gt;
&lt;li&gt;Drop in replacement for existing read only UI&lt;/li&gt;
&lt;li&gt;Audit trail of who took what action in the UI&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-2&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;golang, basic understanding of sveltejs (or any js framework), css, kubernetes&lt;/p&gt;
&lt;h5 id=&#34;mentors-2&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christopher Vig&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom Hobson&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources-2&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://youtu.be/AdNJ3fydeao&#34;&gt;https://youtu.be/AdNJ3fydeao&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://svelte.dev/&#34;&gt;https://svelte.dev/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://kit.svelte.dev/&#34;&gt;https://kit.svelte.dev/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://tailwindcss.com/&#34;&gt;https://tailwindcss.com/&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://go.dev/tour/welcome/1&#34;&gt;https://go.dev/tour/welcome/1&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-2&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-2&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Hard&lt;/p&gt;
&lt;h3 id=&#34;4-quickstart-improvements&#34;&gt;4. Quickstart Improvements&lt;/h3&gt;
&lt;h5 id=&#34;description-3&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;Create new quickstarts that showcase interesting features and kubernetes deployment best practices.
This includes prometheus integrations, database integrations for preview demos, documentation and a better interface for creating quickstarts, rootless containers.
The current quickstarts were created three years ago and are not up to date. It would be good to have them updated, and also add quick starts for newer languages and frameworks.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-3&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Updated quickstarts&lt;/li&gt;
&lt;li&gt;Quickstarts for new languages and frameworks&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-3&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Some knowledge on various programming languages and some deeper knowledge of Kubernetes deployment and operations.&lt;/p&gt;
&lt;h5 id=&#34;mentors-3&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christopher Vig&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom Hobson&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources-3&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x-quickstarts&#34;&gt;https://github.com/jenkins-x-quickstarts&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog&#34;&gt;https://github.com/jenkins-x/jx3-pipeline-catalog&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-3&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;175 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-3&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Easy&lt;/p&gt;
&lt;h3 id=&#34;5-implement-drift-detection-gitops&#34;&gt;5. Implement drift detection (gitops)&lt;/h3&gt;
&lt;h5 id=&#34;description-4&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;Jenkins X only applies changes to cluster when contents of the gitops repository changes. This does not satisfy one of the requirements of the gitops model. It would be nice to detect drift between the current state (kubernetes) and the desired state (git) and apply only those changes. This has the side effect of making the boot job faster.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-4&#34;&gt;Expected Outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;Drift detection in Jenkins X&lt;/li&gt;
&lt;li&gt;Configurable interval when Jenkins X will do a drift detection and apply the changes&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-4&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Kubernetes, golang, Jenkins X, basic understanding of gitops.&lt;/p&gt;
&lt;h5 id=&#34;mentors-4&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christopher Vig&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom Hobson&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;resources-4&#34;&gt;Resources&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://opengitops.dev/&#34;&gt;https://opengitops.dev/&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-4&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;175 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-4&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Medium&lt;/p&gt;
&lt;h3 id=&#34;6-multi-tenancy-in-jenkins-x&#34;&gt;6. Multi-tenancy in Jenkins X&lt;/h3&gt;
&lt;h5 id=&#34;description-5&#34;&gt;Description&lt;/h5&gt;
&lt;p&gt;Installing multiple versions of Jenkins X in a single kubernetes cluster is not supported. There are both architectural and scalability issues around it. This would be beneficial for small teams within organizations who want to own their entire CI/CD platform instead of relying on a central release management team which can lead to more productive teams.&lt;/p&gt;
&lt;h5 id=&#34;expected-outcomes-5&#34;&gt;Expected outcomes&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;A multi-tenant enabled Jenkins X install (jenkins X in different namespaces or a central jx install controlling pipelines running for different tenants)&lt;/li&gt;
&lt;li&gt;Better scaling and security model for Jenkins X&lt;/li&gt;
&lt;li&gt;Updated documentation&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;recommended-skills-5&#34;&gt;Recommended skills&lt;/h5&gt;
&lt;p&gt;Golang, kubernetes, event driven architecture&lt;/p&gt;
&lt;h5 id=&#34;mentors-5&#34;&gt;Mentors&lt;/h5&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/ankitm123&#34;&gt;Ankit D Mohapatra&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/babadofar&#34;&gt;Christopher Vig&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/tomhobson&#34;&gt;Tom Hobson&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h5 id=&#34;expected-size-of-project-5&#34;&gt;Expected Size of project&lt;/h5&gt;
&lt;p&gt;350 hours&lt;/p&gt;
&lt;h5 id=&#34;difficulty-rating-5&#34;&gt;Difficulty rating&lt;/h5&gt;
&lt;p&gt;Hard&lt;/p&gt;
&lt;h3 id=&#34;next-steps&#34;&gt;Next Steps&lt;/h3&gt;
&lt;p&gt;If Jenkins X gets selected, we will create a followup blog with additional details.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X Survey Result Details</title>
      <link>https://jenkins-x.io/blog/2022/02/15/survey-1-result-details-2022/</link>
      <pubDate>Tue, 15 Feb 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/02/15/survey-1-result-details-2022/</guid>
      <description>
        
        
        &lt;p&gt;For more information on the Jenkins X survey see &lt;a href=&#34;https://jenkins-x.io/blog/2022/02/15/survey-1-results-2022/&#34;&gt;Survey results&lt;/a&gt;
Some highlights from the free text answers.&lt;/p&gt;
&lt;h3 id=&#34;what-do-you-enjoy-the-most-with-jenkins-x&#34;&gt;What do you enjoy the most with Jenkins X?&lt;/h3&gt;
&lt;h4 id=&#34;kubernetes&#34;&gt;KUBERNETES&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;Cloud-native feel, &amp;ldquo;you know Kubernetes, you know how to use JX&amp;rdquo;, plugins-based architecture&lt;/li&gt;
&lt;li&gt;Complete CI/CD platform in a k8s cluster&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;gitchatopsconfigurability&#34;&gt;GIT/CHAT/OPS/CONFIGURABILITY&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;Configuration as code, auto generation of k8s files, flexibility&lt;/li&gt;
&lt;li&gt;easy to create preview/dev/staging/prod environments.&lt;/li&gt;
&lt;li&gt;modularity and ease to extend/change&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;easy&#34;&gt;EASY&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;Everything works out of the box.&lt;/li&gt;
&lt;li&gt;Very intuitive&lt;/li&gt;
&lt;li&gt;Lightweight and easy to manage.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;community&#34;&gt;COMMUNITY&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;The community is incredible. I really like how everything works together.&lt;/li&gt;
&lt;li&gt;love the community.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;various&#34;&gt;VARIOUS&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;scalability and how fast it is!&lt;/li&gt;
&lt;li&gt;Integration with different secret backends is easy. Also love the community.&lt;/li&gt;
&lt;li&gt;It&amp;rsquo;s opinionated&lt;/li&gt;
&lt;li&gt;No vendor lock in&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;what-do-you-believe-should-be-improved-with-jenkins-x&#34;&gt;What do you believe should be improved with Jenkins X?&lt;/h3&gt;
&lt;h4 id=&#34;on-premise&#34;&gt;ON PREMISE&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;run it against a local running cluster to test changes to Jenkins-X before updated in GitHub.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Integration with on-premise (Gitlab) as a lot of organizations are not using public cloud due to security policies,&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Proper guide on installing into existing cluster without using terraform. Give us back something like &lt;code&gt;jx compliance&lt;/code&gt;, &lt;code&gt;jx boot&lt;/code&gt;.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Would be nice to not be tied to terraform to boot jenkins-x. Just like kubernetes, it would be great to have a jenkins-x the hard way where everything needs to be installed manually.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;docs&#34;&gt;DOCS&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;it&amp;rsquo;s very difficult to just dive in without previous knowledge of the system&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;extreme lack of quality documentation.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Many conversations take place in slack and users cannot find information that somebody had the same problem beforehand and how it was solved&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;More documentation and guides, making sure quickstart guides work without hassle&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Making it easier to get started&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Very hard to find any information on how people solve a similar problem before&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;I very much enjoy your documentation, but it is very hard to find anything on google that is a huge disadvantage.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Documents need to be clear about what works, and what does not work (kubernetes versions for example, bitbucket etc ..)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Could also be nice with an arcitecture illustration or video that could compare jenkins with jenkins X&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;I find that when I&amp;rsquo;m looking for information I get a lot of mixed results (v3 vs v2).&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;debugging&#34;&gt;DEBUGGING&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;Debugging the integration&lt;/li&gt;
&lt;li&gt;Error handing and reporting&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;multi&#34;&gt;MULTI&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;HA, multi-tenant&lt;/li&gt;
&lt;li&gt;multi cluster setup&lt;/li&gt;
&lt;li&gt;Remote clusters&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;governance&#34;&gt;GOVERNANCE&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;Needs focus on following up on K8s versions.&lt;/li&gt;
&lt;li&gt;Needs a larger body of people governing it&lt;/li&gt;
&lt;li&gt;PRs are being ignored for months at a time. The first PRs I&amp;rsquo;ve opened have been ignored to this day. I started getting some response after connecting with some devs in Slack.&lt;/li&gt;
&lt;li&gt;A public Roadmap and prioritizing tasks by community demand would be the way to go.&lt;/li&gt;
&lt;li&gt;who will be providing development leadership and direction.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;security&#34;&gt;SECURITY&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;permission management within Terraform repos (default settings are too wide for orgs)&lt;/li&gt;
&lt;li&gt;separate JX permissions from per-project permissions - current pipelines gives a cluster admin scope to everyone as development teams can override steps and execute with any service account&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;ui&#34;&gt;UI&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;pipelines dashboard needs Re-Run button.&lt;/li&gt;
&lt;li&gt;A fully functional UI would be nice.&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;various-1&#34;&gt;VARIOUS&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;The install process&lt;/li&gt;
&lt;li&gt;deploy speed&lt;/li&gt;
&lt;li&gt;The parallel PR building causes issues.&lt;/li&gt;
&lt;li&gt;Support for Bitbucket Server&lt;/li&gt;
&lt;li&gt;providing the capabilities to match CircleCI. lots of missing features or very difficult  to set up&lt;/li&gt;
&lt;li&gt;Performance&lt;/li&gt;
&lt;/ul&gt;
&lt;h4 id=&#34;various-feedback&#34;&gt;VARIOUS FEEDBACK&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Integration with vault is confused. Why install vault in docker in k3s environment?&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;I strongly believe in this project!&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;I use Jenkins X as a learning tool.  It gives me the ability to build K8S clusters using different cloud providers and helps me to understand the mechanics of GitOps, helm charts, etc.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Better error handling when pipelines fail would be good (tekton pipeline fail, but jx pipelines dont update their status).&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;I&amp;rsquo;m excited to see how the product has grown in the short time I&amp;rsquo;ve used it.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X Survey Results</title>
      <link>https://jenkins-x.io/blog/2022/02/15/survey-1-results-2022/</link>
      <pubDate>Tue, 15 Feb 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/02/15/survey-1-results-2022/</guid>
      <description>
        
        
        &lt;p&gt;The Jenkins X survey was active for four weeks and closed on February 11 2022. We received lots of valuable insights into how people are using Jenkins X. We need more contributors in the Jenkins X community, so if you feel strongly about how Jenkins X should evolve, your best bet is to dive in and get your hands dirty:) Some highlights of the free text responses we got are collected &lt;a href=&#34;https://jenkins-x.io/blog/2022/02/15/survey-1-result-details-2022/&#34;&gt;here&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;According to the survey, a typical Jenkinx X user works with Devops and Software Engineering&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/area-of-work.png&#34; alt=&#34;Area of Work&#34;&gt;&lt;/p&gt;
&lt;p&gt;This person is using Jenkins X version 3 &lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/jx-versions.png/&#34; alt=&#34;Jenkins X versions&#34;&gt;&lt;/p&gt;
&lt;p&gt;on Amazon
&lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/cloud-provider.png&#34; alt=&#34;Cloud Providers&#34;&gt;&lt;/p&gt;
&lt;p&gt;working in a company of 1-50 people. &lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/people-in-company.png&#34; alt=&#34;Company size&#34;&gt;&lt;/p&gt;
&lt;p&gt;She finds it somewhat difficult to find documentation, average 2.9 out of 5 &lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/hard-to-find-information.png&#34; alt=&#34;Find documentation&#34;&gt;&lt;/p&gt;
&lt;p&gt;The Jenkins X user tries to find information mainly on the main web site, sometimes on slack and less often on github. &lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/where-information.png&#34; alt=&#34;Information sources&#34;&gt;
What he enjoys most about  Jenkins X is that it is an easy way to learn, play around and work with Kubernetes. The git(ops(ish)) style of configuration, the preview environments, and the staging /production environments. &lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/enjoy-most.png&#34; alt=&#34;Enjoy the most&#34;&gt;&lt;/p&gt;
&lt;p&gt;But one thing is sure, documentation is confusing and shold be improved. &lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/improving.png&#34; alt=&#34;Should be improved&#34;&gt;&lt;/p&gt;
&lt;p&gt;The typical Jenkins X user would like to run Jenkins X offline, either to run on a laptop, or behind a (corporate) firewall. Proper support for multi-tenancy would be nice, and who can ignore security in these times.  A clear governance of Jenkins X needs to be established,&lt;/p&gt;
&lt;p&gt;The typical person who answers surveys on Jenkins X &lt;em&gt;is&lt;/em&gt; planning to attend Jenkins X Office hours, which is great!
&lt;img src=&#34;https://jenkins-x.io/images/survey-2022-1/office-hours.png&#34; alt=&#34;Office hours&#34;&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://jenkins-x.io/community/#office-hours&#34;&gt;See you there next week then!&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: January 2022 updates from the JX community</title>
      <link>https://jenkins-x.io/blog/2022/02/02/january2022updates/</link>
      <pubDate>Wed, 02 Feb 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/02/02/january2022updates/</guid>
      <description>
        
        
        &lt;p&gt;Happy new year 2022!&lt;/p&gt;
&lt;p&gt;This monthly blog post series is an attempt to showcase all the incredible work being done by the Jenkins X community to the wider audience.&lt;/p&gt;
&lt;p&gt;Lot of exciting features, bug fixes and documentation improvements were made.&lt;/p&gt;
&lt;h3 id=&#34;community-effort&#34;&gt;Community effort&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;We restarted the office hours this month (&lt;a href=&#34;https://jenkins-x.io/community/#office-hours)&#34;&gt;https://jenkins-x.io/community/#office-hours)&lt;/a&gt;. Drop by to say hello, we are a friendly group!&lt;/li&gt;
&lt;li&gt;First Jenkins X survey was also created this month (&lt;a href=&#34;https://jenkins-x.io/blog/2022/01/21/survey-1-2022/)&#34;&gt;https://jenkins-x.io/blog/2022/01/21/survey-1-2022/)&lt;/a&gt;. We have extended the deadline by 2 weeks (Feb 11, 2022 midnight UTC), so fill it out if you have not yet. We will use this for the roadmap moving forward.&lt;/li&gt;
&lt;li&gt;Monthly blog post update series to keep up with all the amazing progress.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;features&#34;&gt;Features&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;jx-plugins/jx-gitops:
&lt;ul&gt;
&lt;li&gt;Cron job to delete old boot jobs&lt;/li&gt;
&lt;li&gt;Option to Keep n boot jobs older than default age&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x/lighthouse:
&lt;ul&gt;
&lt;li&gt;Support for using gitlab nested repositories&lt;/li&gt;
&lt;li&gt;Allow running lighthouse with cluster scoped permissions&lt;/li&gt;
&lt;li&gt;Add a flag to keep polling releases until commit status is successful&lt;/li&gt;
&lt;li&gt;Do not include tekton roles when tekton engine is disabled&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jx-plugins/jx-pipeline:
&lt;ul&gt;
&lt;li&gt;Use pager to aid in visualizing long pipeline logs&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x-terraform/terraform-jx-azure
&lt;ul&gt;
&lt;li&gt;Support provisioning spot instances in the azure terraform jx module&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jx-plugins/jx-verify:
&lt;ul&gt;
&lt;li&gt;Support specifying label for jx verify install&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x-plugins/jx-registry:
&lt;ul&gt;
&lt;li&gt;Support adding ECR registry policy using jx-registry&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x-charts/jxboot-helmfile-resources:
&lt;ul&gt;
&lt;li&gt;Make all storage locations available as envrironment variables&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;bug-fixes&#34;&gt;Bug fixes&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;GoogleContainerTools/kaniko (upstream fix - outside jx codebase):
&lt;ul&gt;
&lt;li&gt;Kaniko in jx pipelines can now push to ACR (Azure Container Registry)&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x/terraform-aws-eks-jx:
&lt;ul&gt;
&lt;li&gt;Remove deprecated jx v2 keys from requirements configmap&lt;/li&gt;
&lt;li&gt;Fix issue with on-demand billing mode of dynamodb&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x-plugins/jx-promote:
&lt;ul&gt;
&lt;li&gt;Fix local chart check when using cloud buckets to store helm charts&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x-plugins/jx-project:
&lt;ul&gt;
&lt;li&gt;Fix jx project rendering invalid chart.yaml files on import for custom packs in catalog&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;documentation-improvement&#34;&gt;Documentation improvement&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;Guides on configuring Azure service principle and GCP service account for terraform users (&lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/azure/svc_principal/&#34;&gt;https://jenkins-x.io/v3/admin/platforms/azure/svc_principal/&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/google/svc_acct/&#34;&gt;https://jenkins-x.io/v3/admin/platforms/google/svc_acct/&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;New section showing current Jenkins X users (&lt;a href=&#34;https://jenkins-x.io/#users&#34;&gt;https://jenkins-x.io/#users&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;New section on learning resources for Jenkins X v3 (&lt;a href=&#34;https://jenkins-x.io/v3/learning-resources/&#34;&gt;https://jenkins-x.io/v3/learning-resources/&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;Improved documentation on setting up Jenkins X v3 on AWS EKS (&lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/eks/&#34;&gt;https://jenkins-x.io/v3/admin/platforms/eks/&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;Improved guide on installing and configuring Jenkins X on k3s (&lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/k3s/&#34;&gt;https://jenkins-x.io/v3/admin/platforms/k3s/&lt;/a&gt;)&lt;/li&gt;
&lt;li&gt;Fixed content getting clipped in mobile view&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;plumbingquality-improvements&#34;&gt;Plumbing/Quality improvements&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;jenkins-x/jx:
&lt;ul&gt;
&lt;li&gt;Disable running github actions on forks&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x/jx-docs:
&lt;ul&gt;
&lt;li&gt;Upgrade docsy submodules&lt;/li&gt;
&lt;li&gt;Upgrade hugo docker image&lt;/li&gt;
&lt;li&gt;Migrate jx-docs to new pipeline format&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;jenkins-x/jx-gitops:
&lt;ul&gt;
&lt;li&gt;upgrade kubectl version for kpt&lt;/li&gt;
&lt;li&gt;upgrade helm and helmfile version&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Huge thanks to all the contributors for their hardwork!&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;ankitm123&lt;/li&gt;
&lt;li&gt;babadofar&lt;/li&gt;
&lt;li&gt;dippynark&lt;/li&gt;
&lt;li&gt;ia-mfriegang&lt;/li&gt;
&lt;li&gt;jalonsoa&lt;/li&gt;
&lt;li&gt;msvticket&lt;/li&gt;
&lt;li&gt;rajatgupta24&lt;/li&gt;
&lt;li&gt;rawlingsj&lt;/li&gt;
&lt;li&gt;sergiogiuffrida&lt;/li&gt;
&lt;li&gt;slimm609&lt;/li&gt;
&lt;li&gt;TedGelpi&lt;/li&gt;
&lt;li&gt;tomhobson&lt;/li&gt;
&lt;li&gt;yelhouti&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X Survey</title>
      <link>https://jenkins-x.io/blog/2022/01/21/survey-1-2022/</link>
      <pubDate>Fri, 21 Jan 2022 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2022/01/21/survey-1-2022/</guid>
      <description>
        
        
        &lt;p&gt;We have made a short survey where we try to gain insight into how people experience Jenkins X. This is meant to be used as guidelines going forward so we can be more focused on what areas to improve.&lt;/p&gt;
&lt;p&gt;All contributions are welcome, if you are just browsing or have used it for years, we want to know you all!&lt;/p&gt;
&lt;p&gt;We have extended the survey period and it will now be open untill Tuesday February 11 2022 midnight UTC. All submissions are anonymous and the results will be published. So don&amp;rsquo;t hesitate, fill in the &lt;a href=&#34;https://forms.office.com/r/mWD6Ruzu8C&#34;&gt;Jenkins X survey&lt;/a&gt; today&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Incident: Kaniko and ACR</title>
      <link>https://jenkins-x.io/blog/2021/12/28/kanikoacrandjenkinsx/</link>
      <pubDate>Tue, 28 Dec 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/12/28/kanikoacrandjenkinsx/</guid>
      <description>
        
        
        &lt;p&gt;We&amp;rsquo;ve recently had an issue with one of our packages come to light. We wanted to talk through the resolution steps we&amp;rsquo;re going to put into place.&lt;/p&gt;
&lt;h2 id=&#34;so-what-happened&#34;&gt;So what happened?&lt;/h2&gt;
&lt;p&gt;Azure users started reporting seeing the following error within the build step:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for &amp;#34;xyz.azurecr.io/myorg/myrepo:0.0.1&amp;#34;: resolving authorization for xyz.azurecr.io failed: error getting credentials - err: exec: &amp;#34;docker-credential-acr-env&amp;#34;: executable file not found in $PATH
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;This seemed to be indicating to an authorization issues with the terraform module. Other users were seemingly unaffected by this issue.&lt;/p&gt;
&lt;p&gt;Upon further analysis, &lt;a href=&#34;https://github.com/GoogleContainerTools/kaniko.git&#34;&gt;kaniko&lt;/a&gt; seems to have issues with the latest version and grabbing credentials for acr. The latest working version that we are aware of is &lt;a href=&#34;https://github.com/GoogleContainerTools/kaniko/releases/tag/v1.3.0&#34;&gt;1.3&lt;/a&gt;. There wasn&amp;rsquo;t a massive influx of people seeing this issue due to it only occuring once versionstream had been updated with &lt;code&gt;jx gitops upgrade&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id=&#34;so-what-are-you-going-to-do-about-it&#34;&gt;So what are you going to do about it?&lt;/h2&gt;
&lt;p&gt;For starters, most users are probably using the latest kaniko features, so we&amp;rsquo;re unable to just roll this back for everyone.&lt;/p&gt;
&lt;p&gt;We&amp;rsquo;re getting started by creating a PR to kaniko to resolve the issue. However, due to release schedules etc, this will mean that getting started with azure will be broken for quite a while.&lt;/p&gt;
&lt;h2 id=&#34;how-can-i-fix-it-in-the-meantime&#34;&gt;How can I fix it in the meantime?&lt;/h2&gt;
&lt;p&gt;If you&amp;rsquo;re on azure, the resolution is quite simple, here&amp;rsquo;s a step by step guide:&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;1.  Find which &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog&#34;&gt;buildpack&lt;/a&gt; you are using and navigate to the &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/blob/master/tasks/csharp/release.yaml#L55&#34;&gt;build-container-build step&lt;/a&gt;:&lt;/strong&gt;&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;directory: csharp/ date: 12/28/21  git: main 
› cat .lighthouse/jenkins-x/release.yaml | grep &amp;#34;  image: &amp;#34;
          image: uses:jenkins-x/jx3-pipeline-catalog/tasks/csharp/release.yaml@versionStream
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;strong&gt;2. Replace the build-container-build step to use the suggested kaniko image: &lt;code&gt;gcr.io/kaniko-project/executor:v1.3.0-debug&lt;/code&gt;&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Before&lt;/strong&gt;&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  creationTimestamp: null
  name: release
spec:
  pipelineSpec:
    tasks:
    - name: from-build-pack
      resources: {}
      taskSpec:
        metadata: {}
        stepTemplate:
          image: uses:jenkins-x/jx3-pipeline-catalog/tasks/csharp/release.yaml@versionStream
          name: &amp;#34;&amp;#34;
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
          workingDir: /workspace/source
        steps:
        - image: uses:jenkins-x/jx3-pipeline-catalog/tasks/git-clone/git-clone.yaml@versionStream
          name: &amp;#34;&amp;#34;
          resources: {}
        - name: next-version
          resources: {}
        - name: jx-variables
          resources: {}
        - name: check-registry
          resources: {}
        - name: build-container-build
          resources: {}
        - name: promote-changelog
          resources: {}
        - name: promote-helm-release
          resources: {}
        - name: promote-jx-promote
          resources: {}
  podTemplate: {}
  serviceAccountName: tekton-bot
  timeout: 12h0m0s
status: {}
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;strong&gt;After&lt;/strong&gt;&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  creationTimestamp: null
  name: release
spec:
  pipelineSpec:
    tasks:
    - name: from-build-pack
      resources: {}
      taskSpec:
        metadata: {}
        stepTemplate:
          image: uses:jenkins-x/jx3-pipeline-catalog/tasks/csharp/release.yaml@versionStream
          name: &amp;#34;&amp;#34;
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
          workingDir: /workspace/source
        steps:
        - image: uses:jenkins-x/jx3-pipeline-catalog/tasks/git-clone/git-clone.yaml@versionStream
          name: &amp;#34;&amp;#34;
          resources: {}
        - name: next-version
          resources: {}
        - name: jx-variables
          resources: {}
        - name: check-registry
          resources: {}
        - image: gcr.io/kaniko-project/executor:v1.3.0-debug
          name: build-container-build
          resources: {}
          script: |
            #!/busybox/sh
            source .jx/variables.sh
            cp /tekton/creds-secrets/tekton-container-registry-auth/.dockerconfigjson /kaniko/.docker/config.json
            /kaniko/executor $KANIKO_FLAGS --context=/workspace/source --dockerfile=${DOCKERFILE_PATH:-Dockerfile} --destination=$PUSH_CONTAINER_REGISTRY/$DOCKER_REGISTRY_ORG/$APP_NAME:$VERSION
        - name: promote-changelog
          resources: {}
        - name: promote-helm-release
          resources: {}
        - name: promote-jx-promote
          resources: {}
  podTemplate: {}
  serviceAccountName: tekton-bot
  timeout: 12h0m0s
status: {}
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;&lt;strong&gt;3. Do this again for your &lt;code&gt;.lighthouse/jenkins-x/pullrequest.yaml&lt;/code&gt; file&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;4. Commit and push it to your repository.&lt;/strong&gt;&lt;/p&gt;
&lt;h3 id=&#34;were-hoping-to-make-this-simpler&#34;&gt;We&amp;rsquo;re hoping to make this simpler&lt;/h3&gt;
&lt;p&gt;We&amp;rsquo;re working on:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Fixing it upstream (the proper fix, but could take a while to be merged)&lt;/li&gt;
&lt;li&gt;Making a temporary azure pipeline step for azure users&lt;/li&gt;
&lt;li&gt;Making a script so that azure users don&amp;rsquo;t have to go through this manual process each time&lt;/li&gt;
&lt;li&gt;Allowing overriding images without having to specify a script within lighthouse&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;help-us-find-and-fix-things-like-this-in-future&#34;&gt;Help us find and fix things like this in future&lt;/h3&gt;
&lt;p&gt;Talk to us on our slack channels, which are part of the Kubernetes slack. Join  Kubernetes slack &lt;a href=&#34;http://slack.k8s.io/&#34;&gt;here&lt;/a&gt; and find us on our channels:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;#jenkins-x-dev for developers of Jenkins X&lt;/li&gt;
&lt;li&gt;#jenkins-x-user for users of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Find out more about becoming involved in the Jenkins X community &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Hacktoberfest conclusion 2021</title>
      <link>https://jenkins-x.io/blog/2021/11/22/hacktoberfestconclusion2021/</link>
      <pubDate>Mon, 22 Nov 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/11/22/hacktoberfestconclusion2021/</guid>
      <description>
        
        
        &lt;p&gt;&lt;a href=&#34;https://hacktoberfest.digitalocean.com/&#34;&gt;Hacktoberfest 2021&lt;/a&gt; is over, and we got quite a few contributions from the open source community.&lt;/p&gt;
&lt;p&gt;Contributions included various document improvements, adding jira as an issue tracker for generating changelogs and adding initial support for external vault!&lt;/p&gt;
&lt;p&gt;The top contributors to Jenkins X in hacktoberfest 2021 were:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Marten Svantesson&lt;/li&gt;
&lt;li&gt;Christopher vig&lt;/li&gt;
&lt;li&gt;James Rawlings&lt;/li&gt;
&lt;li&gt;Hays Clark&lt;/li&gt;
&lt;li&gt;Anatoli Babenia&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We would also like to thank all the contributors who participated and made it a success.
The strength of Jenkins X lies in it&amp;rsquo;s vast community, and we hope to see many more major contributions from them in the near and far future.&lt;/p&gt;
&lt;h3 id=&#34;ask-us-questions&#34;&gt;Ask us questions&lt;/h3&gt;
&lt;p&gt;Missed this year&amp;rsquo;s hacktoberfest?
No worries, you can always contribute to Jenkins X.
We&amp;rsquo;re happy to help if you have any questions.
Talk to us on our slack channels, which are part of the Kubernetes slack. Join Kubernetes slack &lt;a href=&#34;http://slack.k8s.io/&#34;&gt;here&lt;/a&gt; and find us on our channels:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;#jenkins-x-dev for developers of Jenkins X&lt;/li&gt;
&lt;li&gt;#jenkins-x-user for users of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;em&gt;We look forward to participating in the next hacktoberfest!&lt;/em&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Hacktoberfest 2021</title>
      <link>https://jenkins-x.io/blog/2021/10/06/hacktoberfest2021/</link>
      <pubDate>Wed, 06 Oct 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/10/06/hacktoberfest2021/</guid>
      <description>
        
        
        &lt;p&gt;We are excited to announce that Jenkins X will be participating in Hacktoberfest again this year! Hacktoberfest is a month-long global celebration of open source software.&lt;/p&gt;
&lt;p&gt;All backgrounds and skill levels are encouraged to participate in Hacktoberfest and join a global community of open source contributors.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Learn more about Hacktoberfest and sign up &lt;a href=&#34;https://hacktoberfest.digitalocean.com/&#34;&gt;here&lt;/a&gt;.&lt;/strong&gt;&lt;/p&gt;
&lt;h3 id=&#34;contribute-to-jenkins-x-docs&#34;&gt;Contribute to Jenkins X docs&lt;/h3&gt;
&lt;p&gt;We welcome your contributions to the &lt;a href=&#34;https://github.com/jenkins-x/jx-docs&#34;&gt;Jenkins X documentation project&lt;/a&gt;!&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-docs/issues?q=is%3Aissue+is%3Aopen+label%3Ahacktoberfest&#34;&gt;Issues labelled &amp;ldquo;hacktoberfest&amp;rdquo;&lt;/a&gt; generally indicate good first issues. However, all pull requests will count towards your Hacktoberfest challenge.&lt;/p&gt;
&lt;h3 id=&#34;ask-us-questions&#34;&gt;Ask us questions&lt;/h3&gt;
&lt;p&gt;We&amp;rsquo;re happy to help if you have any questions. Talk to us on our slack channels, which are part of the Kubernetes slack. Join  Kubernetes slack &lt;a href=&#34;http://slack.k8s.io/&#34;&gt;here&lt;/a&gt; and find us on our channels:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;#jenkins-x-dev for developers of Jenkins X&lt;/li&gt;
&lt;li&gt;#jenkins-x-user for users of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Find out more about becoming involved in the Jenkins X community &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;We look forward to seeing you in open source, fixing all the things!&lt;/em&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Moving Jenkins X v2 artifacts</title>
      <link>https://jenkins-x.io/blog/2021/08/26/moving-v2-artifacts/</link>
      <pubDate>Thu, 26 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/08/26/moving-v2-artifacts/</guid>
      <description>
        
        
        &lt;h1 id=&#34;__action-required__&#34;&gt;&lt;strong&gt;ACTION REQUIRED&lt;/strong&gt;&lt;/h1&gt;
&lt;p&gt;TL;DR - Jenkins X specific helm repositories and container registries hosted on GCP have been moved to GitHub.  This will mainly affect jx v2 users but there is expected to be a small impact on v3 users too.  Below describes the steps we believe are needed to keep Jenkins X installations working as normal but there will be some action needed.&lt;/p&gt;
&lt;h2 id=&#34;why-the-disruption&#34;&gt;Why the disruption?&lt;/h2&gt;
&lt;p&gt;When Jenkins X first started we made heavy use of GCP&amp;rsquo;s services for hosting the cloud infrastructure needed by users to install and run Jenkins X.  This was great as we could use the same IAM to push and maintain content from our own hosted build infrastructure and ensure we were validating the same experience of using cloud provider hosted services wherever possible.  As Jenkins X grew in popularity the cloud costs began to increase with the &lt;a href=&#34;https://cloud.google.com/container-registry/pricing&#34;&gt;pricing model from GCP&lt;/a&gt;, specifically the networking costs of cross continent egress.&lt;/p&gt;
&lt;p&gt;Given this, for jx3 we decided to see if switching to &lt;a href=&#34;https://github.com/orgs/jenkins-x/packages&#34;&gt;GitHub packages for container images&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x-charts.github.io/repo/&#34;&gt;GitHub pages&lt;/a&gt; for helm repositories would be better, the result was it is better.  In fact we have made it super easy for users to switch to using GitHub pages for releasing &lt;a href=&#34;https://jenkins-x.io/v3/develop/faq/config/registries/#how-do-i-switch-to-github-pages-for-charts&#34;&gt;helm charts&lt;/a&gt; and using GitHub packages.&lt;/p&gt;
&lt;p&gt;Now that we have validated GitHub is more cost effective for hosting public images and helm charts for the Jenkins X project, we want to switch to using GitHub for all v2 plus v3 users, then shutdown the GCP services which are causing unnecessary cost.&lt;/p&gt;
&lt;p&gt;It is expected that v3 users will need a small change and v2 slightly more.  Details for both will be described below but it is worth noting that there hasn&amp;rsquo;t been a v2 release in 9 months and v3 was &lt;a href=&#34;https://jenkins-x.io/blog/2021/04/15/jx-v3-ga/&#34;&gt;GA in April&lt;/a&gt; earlier this year, so we aren&amp;rsquo;t expecting too many folks on v2.  We are aiming to limit any disruption and help provide easy steps to handle the move.&lt;/p&gt;
&lt;p&gt;We apologise for any extra work caused however, this is required to preserve the long running hosting of Jenkins X artifacts both past and present.  If you experience issues that are not covered by the steps below please reach out to the &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;community slack channel&lt;/a&gt; and we can help address and update this blog with details.&lt;/p&gt;
&lt;h2 id=&#34;what-is-changing&#34;&gt;What is changing?&lt;/h2&gt;
&lt;p&gt;We will be shutting down a number of GCP projects that contain old helm charts plus container images and moving them to be hosted by GitHub packages and pages.&lt;/p&gt;
&lt;h4 id=&#34;helm&#34;&gt;Helm&lt;/h4&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;https://chartmuseum.build.cd.jenkins-x.io
http://chartmuseum.jenkins-x.io
https://storage.googleapis.com/chartmuseum.jenkins-x.io
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;have been moved to&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;https://jenkins-x-charts.github.io/v2
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;AND&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;https://storage.googleapis.com/jenkinsxio/charts
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;has been moved to&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;https://jenkins-x-charts.github.io/repo
&lt;/code&gt;&lt;/pre&gt;&lt;h4 id=&#34;images&#34;&gt;Images&lt;/h4&gt;
&lt;p&gt;The most recently versioned images from &lt;a href=&#34;https://console.cloud.google.com/gcr/images/jenkinsxio/GLOBAL&#34;&gt;gcr.io/jenkinsxio&lt;/a&gt; have been moved to &lt;a href=&#34;https://github.com/orgs/jenkins-x/packages&#34;&gt;ghcr.io/jenkins-x&lt;/a&gt;&lt;/p&gt;
&lt;h4 id=&#34;labs&#34;&gt;Labs&lt;/h4&gt;
&lt;p&gt;There are some old labs images and helm charts which should not be in use as they are either deprecated or replaced with GA versions in the v3 &lt;a href=&#34;https://jenkins-x-charts.github.io/repo/&#34;&gt;helm repo&lt;/a&gt; or &lt;a href=&#34;https://github.com/orgs/jenkins-x/packages&#34;&gt;container registry&lt;/a&gt;.&lt;/p&gt;
&lt;h3 id=&#34;v2-users&#34;&gt;v2 users&lt;/h3&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;The Jenkins X own v2 build infrastructure was retired at the start of the year as no more releases were planned and to reduce costs.  With that we are unable to perform a new release that automatically switches references to images from &lt;code&gt;gcr.io/jenkinsxio&lt;/code&gt; to &lt;code&gt;ghcr.io/jenkins-x&lt;/code&gt;.  If you are still using v2 then please update your references to this container registry.  An alternative &lt;strong&gt;which has not yet been verified&lt;/strong&gt; is to use a &lt;a href=&#34;https://github.com/phenixblue/imageswap-webhook&#34;&gt;image swap Kubernetes mutating admission controller&lt;/a&gt; which takes configuration to switch the registry on the fly.  &lt;a href=&#34;https://github.com/phenixblue/imageswap-webhook&#34;&gt;We have asked on slack&lt;/a&gt; for help validating the approach so if you do try it please share feedback and config used to help others in the channel, we can then update docs.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your boot git repository, run a search for references of &lt;code&gt;http://chartmuseum.jenkins-x.io&lt;/code&gt; and &lt;code&gt;https://storage.googleapis.com/chartmuseum.jenkins-x.io&lt;/code&gt; replace with &lt;code&gt;https://jenkins-x-charts.github.io/v2&lt;/code&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Change the &lt;code&gt;lighthouse-jx-controller&lt;/code&gt; deployment to use an environment variable&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;JX_DEFAULT_IMAGE=ghcr.io/jenkins-x/builder-maven:2.1.155-778-patch3
&lt;/code&gt;&lt;/pre&gt;&lt;ol start=&#34;4&#34;&gt;
&lt;li&gt;
&lt;p&gt;Environment controller (can be skipped if not using)&lt;/p&gt;
&lt;p&gt;i) change the environment controller image to be &lt;code&gt;ghcr.io/jenkins-x/builder-maven:2.1.155-778-patch3&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;ii) change the image used in the pipeline, needs to be changed in the jenkins-x.yaml of the enviromnet repo:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;agent:
 container: ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;iii) add this environment variable in the deployment of the environment-controller&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt; - name: BUILDER_JX_IMAGE
   value: ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3
&lt;/code&gt;&lt;/pre&gt;&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your boot git repository, set the following values for  &lt;code&gt;env/jenkins-x-platform&lt;/code&gt; deployment:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Value&lt;/th&gt;
&lt;th&gt;&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;expose.Image&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/exposecontroller&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;expose.ImageTag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.3.118&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;cleanup.Image&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/exposecontroller&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;cleanup.ImageTag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.3.118&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;controllerbuild.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;controllerbuild.image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;controllerbuild.env.BUILDER_JX_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;postinstalljob.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;postinstalljob.image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;postinstalljob.env.BUILDER_JX_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;controllerrole.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;controllerrole.image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;controllerrole.env.BUILDER_JX_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcpreviews.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcpreviews.image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcpreviews.env.BUILDER_JX_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcactivities.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcactivities.image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcactivities.env.BUILDER_JX_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcpods.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcpods.image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;gcpods.env.BUILDER_JX_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-jx:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your boot git repository, set the following values for  &lt;code&gt;env/lighthouse-jx&lt;/code&gt; deployment:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Value&lt;/th&gt;
&lt;th&gt;&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;image.parentRepository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;0.0.164&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;jxcontroller.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/lighthouse-jx-controller&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;jxcontroller.image.tag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;0.0.164&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;env.JX_DEFAULT_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-maven:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your boot git repository, set the following values for  &lt;code&gt;env/lighthouse&lt;/code&gt; deployment:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Value&lt;/th&gt;
&lt;th&gt;&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;image.parentRepository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/lighthouse&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;env.JX_DEFAULT_IMAGE&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/builder-maven:2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your boot git repository, update the &lt;code&gt;jenkins-x.yml&lt;/code&gt; replacing any reference to &lt;code&gt;image: gcr.io/jenkinsxio/builder-go:2.1.155-778&lt;/code&gt; with &lt;code&gt;image: ghcr.io/jenkins-x/builder-go:2.1.155-778-patch3&lt;/code&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your boot git repository, update the &lt;code&gt;jenkins-x-release.yml&lt;/code&gt; replacing any reference to &lt;code&gt;image: gcr.io/jenkinsxio/builder-go:2.1.155-778&lt;/code&gt; with &lt;code&gt;image: ghcr.io/jenkins-x/builder-go:2.1.155-778-patch3&lt;/code&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your boot git repository, update the &lt;code&gt;systems/jxing/values.tmpl.yaml&lt;/code&gt; setting&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Value&lt;/th&gt;
&lt;th&gt;&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;nginx-ingress.controller.image.repository&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/nginx-ingress-controller&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;ol start=&#34;11&#34;&gt;
&lt;li&gt;In any environment managed repository (e.g. environment-*-staging | production) update &lt;code&gt;env/values.yaml&lt;/code&gt;:&lt;/li&gt;
&lt;/ol&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Value&lt;/th&gt;
&lt;th&gt;&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;expose.Image&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/exposecontroller&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;expose.ImageTag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.3.118&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;cleanup.Image&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;ghcr.io/jenkins-x/exposecontroller&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;cleanup.ImageTag&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.3.118&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;ol start=&#34;12&#34;&gt;
&lt;li&gt;In any environment managed repository (e.g. environment-*-staging | production) update &lt;code&gt;env/requirements.yaml&lt;/code&gt; replacing any exposecontroller repository url with &lt;code&gt;https://jenkins-x-charts.github.io/v2&lt;/code&gt;&lt;/li&gt;
&lt;/ol&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;- alias: expose
  name: exposecontroller
  repository: https://jenkins-x-charts.github.io/v2
  version: 2.3.118
- alias: cleanup
  name: exposecontroller
  repository: https://jenkins-x-charts.github.io/v2
  version: 2.3.118
&lt;/code&gt;&lt;/pre&gt;&lt;ol start=&#34;13&#34;&gt;
&lt;li&gt;In any applications repositories who has already import into jx, update the &lt;code&gt;./jenkins-x.yaml&lt;/code&gt; add or replace :
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;pipelineConfig:
  agent:
    image: `ghcr.io/jenkins-x/BUILDER_YOU_NEED:2.1.155-778-patch3`
&lt;/code&gt;&lt;/pre&gt;Here is the list of the principal images who has migrated to new ghcr:&lt;/li&gt;
&lt;/ol&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Value&lt;/th&gt;
&lt;th&gt;Version&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-jx&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-nodejs&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-nodejs12&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-nodejs14&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-maven-java11&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-php5x&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-php7x&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-python37&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;strong&gt;builder-dotnet&lt;/strong&gt;&lt;/td&gt;
&lt;td&gt;2.1.155-778-patch3&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;Have we missed anything? Please contribute to this blog or feedback on the slack channel.&lt;/p&gt;
&lt;h3 id=&#34;v3-users&#34;&gt;v3 users&lt;/h3&gt;
&lt;p&gt;There is not expected to be significant disruption to v3 users but if there is anything needed beyond the steps below then we are asking users to reach out asap and we can update this blog.&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;Run &lt;code&gt;jx gitops upgrade&lt;/code&gt; to ensure you upgrade to the latest version stream with the old helm repository removed. If you are tracking the LTS version stream please delay until Wednesday 1st September to run this.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your cluster git repository, run a search for references of &lt;code&gt;https://storage.googleapis.com/jenkinsxio/charts&lt;/code&gt; replace with &lt;code&gt;https://jenkins-x-charts.github.io/repo&lt;/code&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In your cluster git repository, run a search for references of &lt;code&gt;http://chartmuseum.jenkins-x.io&lt;/code&gt; and &lt;code&gt;https://storage.googleapis.com/chartmuseum.jenkins-x.io&lt;/code&gt; replace with &lt;code&gt;https://jenkins-x-charts.github.io/v2&lt;/code&gt;&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Switch &lt;code&gt;jx-verify&lt;/code&gt; helm chart repository for any application you have which is built by Jenkins X 3.  This is under your applications git repository &lt;code&gt;./charts/preview/helmfile.yaml&lt;/code&gt; change &lt;code&gt;https://storage.googleapis.com/jenkinsxio/charts&lt;/code&gt; to &lt;code&gt;https://jenkins-x-charts.github.io/repo&lt;/code&gt; .  &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/commit/ed01d636b94b2ea51b878d9b5331bc4c88f6e8b1&#34;&gt;Here&lt;/a&gt; is an example that changes the main pipeline catalog packs which are used when first creating or importing applications.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Switch any &lt;code&gt;gcr.io/jenkinsxio&lt;/code&gt; images to &lt;code&gt;ghcr.io/jenkins-x&lt;/code&gt; in your application git repo &lt;code&gt;.lighthouse/*.yaml&lt;/code&gt; files if you have references there&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Have we missed anything?  Please contribute to this blog or feedback on the slack channel.&lt;/p&gt;
&lt;h2 id=&#34;when-will-all-this-take-place&#34;&gt;When will all this take place?&lt;/h2&gt;
&lt;ol&gt;
&lt;li&gt;
&lt;p&gt;This blog is the initial notice which we will socialise, please help to raise awareness.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Friday 27th August - the labs project will be scheduled to shutdown, short notice because we believe no services should be used, if they are it is an easy switch to upgrade to GA versions.  Labs efforts are never intended to be production grade and are used at risk.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Monday 6th September - make the GCP container registry and helm repository bucket private, during which time any image versions that have not been transferred to GitHub can be requested via the community slack channel.  All helm versions have been moved to &lt;a href=&#34;https://jenkins-x-charts.github.io/v2&#34;&gt;https://jenkins-x-charts.github.io/v2&lt;/a&gt; as described above.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Monday 13th September - schedule for shutdown the two GCP projects hosting the container registry and helm repository.&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id=&#34;why-are-only-the-most-recent-versions-v2-images-copied-to-github-packages-and-not-all-versions&#34;&gt;Why are only the most recent versions v2 images copied to GitHub packages and not all versions?&lt;/h2&gt;
&lt;p&gt;There are 14 Terabytes of data that make up the jenkinsxio container registry on GCP, it would be costly and wasteful to transfer all this to GitHub so we picked the last known version of each image that was released last year.  If there are specific images that you wish to use either pull / push them yourself to a container registry of your own or reach out and on a case by case effort, we can look to move them to GitHub while the read permissions are made private and before the project is shut down.&lt;/p&gt;
&lt;h2 id=&#34;im-on-v2-and-use-a-builder-image-which-is-not-available-on-github-container-registry-how-do-i-build-my-own-version-to-work-with-the-new-helm-and-image-repositories&#34;&gt;I&amp;rsquo;m on v2 and use a builder image which is not available on GitHub container registry, how do I build my own version to work with the new helm and image repositories?&lt;/h2&gt;
&lt;p&gt;The old v2 jx code &lt;a href=&#34;https://github.com/jenkins-x/jx/tree/v2&#34;&gt;lives on a branch&lt;/a&gt; you will need to:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;fork this branch&lt;/li&gt;
&lt;li&gt;apply search and replace changes for
i) gcr.io/jenkinsxio to ghcr.io/jenkins-x &lt;a href=&#34;https://github.com/jenkins-x/jx/commit/9d5f1aa6421a22e311d12482893586a45b485ac8&#34;&gt;example&lt;/a&gt;
ii) &lt;a href=&#34;https://storage.googleapis.com/chartmuseum.jenkins-x.io&#34;&gt;https://storage.googleapis.com/chartmuseum.jenkins-x.io&lt;/a&gt; to &lt;a href=&#34;https://jenkins-x-charts.github.io/v2&#34;&gt;https://jenkins-x-charts.github.io/v2&lt;/a&gt; &lt;a href=&#34;https://github.com/jenkins-x/jx/commit/88965b1696c81349f4e330aeb98ec5e26116341c&#34;&gt;example&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;run &lt;code&gt;make linux&lt;/code&gt; to build the updated jx binary&lt;/li&gt;
&lt;li&gt;build and push the images you require, for example&lt;/li&gt;
&lt;/ul&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;docker build -f Dockerfile.builder-maven -t ghcr.io/jenkins-x/builder-maven:2.1.149-768-patch3 .
docker push ghcr.io/jenkins-x/builder-maven:2.1.149-768-patch3
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;once the builder-jx/go/maven/etc.. are pushed, you will need to configure the charts:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;if a chart allows the image to be overridden using a value you can add that to your env/values.tmpl.yaml, replacing current gcr.io/jenkinsxio images with ghcr.io/jenkins-x
e.g.&lt;/li&gt;
&lt;/ul&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;jenkins-x-platform:
  gcpreviews:
    image:
      repository: ghcr.io/jenkins-x/builder-jx
      tag: [your custom tag]
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;if you cannot override the image using a helm value you may need to:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;download each needed chart/subchart needed to make jx work, exemple for jenkins-x-platform/, jxboot-resources/releases&lt;/li&gt;
&lt;li&gt;for each charts/subcharts replace current gcr.io/jenkinsxio images with ghcr.io/jenkins-x if it exists or rebuild and host them on a private registry if not&lt;/li&gt;
&lt;li&gt;host updated charts on a private chartmuseum&lt;/li&gt;
&lt;li&gt;switch boot git repo to use custom charts&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;im-getting-a-missing-arg---provider-values-dir-and-helm-repository-httpsjenkins-x-chartsgithubiov2-does-not-have-an-associated-prefix-in-in-the-chartsrepositoriesyml-error&#34;&gt;I&amp;rsquo;m getting a missing arg &lt;code&gt;--provider-values-dir&lt;/code&gt; and helm repository &lt;a href=&#34;https://jenkins-x-charts.github.io/v2&#34;&gt;https://jenkins-x-charts.github.io/v2&lt;/a&gt; does not have an associated prefix in in the &amp;lsquo;charts/repositories.yml&amp;rsquo; error&lt;/h2&gt;
&lt;p&gt;A few users have been hitting this error, it is related to the jx version used.  This thread with the help of Francesco Capozzo contains both image tags and versions to use instead:&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://kubernetes.slack.com/archives/C9MBGQJRH/p1631112970450800&#34;&gt;https://kubernetes.slack.com/archives/C9MBGQJRH/p1631112970450800&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Images:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;ghcr.io/jenkins-x/builder-jx:2.1.142-761-patch3
ghcr.io/jenkins-x/builder-maven:2.1.142-761-patch3
ghcr.io/jenkins-x/builder-go:2.1.142-761-patch3
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;Chart versions to use rather than relying on the version stream:&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;dependencies:
* name: jxboot-resources
  repository: https://jenkins-x-charts.github.io/v2
  version: 0.0.43
* alias: tekton
  name: tekton
  repository: https://jenkins-x-charts.github.io/v2
  version: 0.0.63
* alias: prow
  condition: prow.enabled
  name: prow
  repository: https://jenkins-x-charts.github.io/v2
  version: 0.0.1773
* alias: lighthouse
  condition: lighthouse.enabled
  name: lighthouse
  repository: https://jenkins-x-charts.github.io/v2
  version: 0.0.843
* alias: lighthouse-jx
  condition: lighthouse.enabled
  name: lighthouse-jx
  repository: https://jenkins-x-charts.github.io/v2
  version: 0.0.121
* alias: bucketrepo
  condition: bucketrepo.enabled
  name: bucketrepo
  repository: https://jenkins-x-charts.github.io/v2
  version: 0.1.42
* name: jenkins-x-platform
  repository: https://jenkins-x-charts.github.io/v2
  version: 2.0.2411
* name: jx-pipelines-visualizer
  repository: https://jenkins-x-charts.github.io/repo
  version: 1.7.3
&lt;/code&gt;&lt;/pre&gt;
      </description>
    </item>
    
    <item>
      <title>Blog: How to debug your Tekton pipelines</title>
      <link>https://jenkins-x.io/blog/2021/08/18/debug-tekton/</link>
      <pubDate>Wed, 18 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/08/18/debug-tekton/</guid>
      <description>
        
        
        

&lt;div class=&#34;alert alert-warning&#34; role=&#34;alert&#34;&gt;


    &lt;code&gt;TaskRun&lt;/code&gt; breakpoint functionality is no longer supported since Tekton 0.29.0 upgrades in &lt;code&gt;3.2.298&lt;/code&gt;. For more info see &lt;a href=&#34;https://jenkins-x.io/blog/2022/04/22/kubernetes-1.22-tekton/&#34;&gt;Kubernetes 1.22 - Breaking change!&lt;/a&gt;.

&lt;/div&gt;

&lt;p&gt;Tekton recently introduced a &lt;a href=&#34;https://github.com/tektoncd/pipeline/blob/main/docs/debug.md#debug&#34;&gt;debug feature&lt;/a&gt; when you create &lt;code&gt;TaskRun&lt;/code&gt; resources so that steps can be paused at a breakpoint until told to move forwards so that you can diagnose why pipeline steps fail.&lt;/p&gt;
&lt;p&gt;The latest Tekton release only supports breakpoints on &lt;code&gt;TaskRun&lt;/code&gt; resources but there is a &lt;a href=&#34;https://github.com/tektoncd/pipeline/pull/4145&#34;&gt;Pull Request #4145&lt;/a&gt; to add support also to debugging &lt;code&gt;PipelineRun&lt;/code&gt; resources as well. If you are reading this please add your thumbs up emoji feedback to the &lt;a href=&#34;https://github.com/tektoncd/pipeline/pull/4145&#34;&gt;PR #4145&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;We&amp;rsquo;ve switched Jenkins X to use a preview image of Tekton with &lt;a href=&#34;https://github.com/tektoncd/pipeline/pull/4145&#34;&gt;PR #4145&lt;/a&gt; included so that Jenkins X developers can easily debug their pipelines (which typically are &lt;code&gt;PipelineRun&lt;/code&gt; resources).&lt;/p&gt;
&lt;h2 id=&#34;how-to-debug-tekton-pipelines&#34;&gt;How to debug Tekton Pipelines&lt;/h2&gt;
&lt;p&gt;Here is a demo which shows how to debug pipelines:&lt;/p&gt;
&lt;iframe width=&#34;850&#34; height=&#34;500&#34; src=&#34;https://www.youtube.com/embed/QqTaclB6-oI&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h3 id=&#34;prerequisites&#34;&gt;Prerequisites&lt;/h3&gt;
&lt;p&gt;Make sure &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/cluster/&#34;&gt;your cluster is upgraded to the latest version stream&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;If you intend to use the &lt;code&gt;jx&lt;/code&gt; in the below examples make sure you &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/cli/&#34;&gt;upgrade the CLI too&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&#34;enable-a-breakpoint&#34;&gt;Enable a breakpoint&lt;/h3&gt;
&lt;p&gt;To enable a breakpoint you can:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;use the &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/lens/&#34;&gt;Lens UI&lt;/a&gt; as shown in the above video by:
&lt;ul&gt;
&lt;li&gt;right click on a &lt;code&gt;Pipeline&lt;/code&gt; action menu&lt;/li&gt;
&lt;li&gt;select &lt;code&gt;Breakpoint -&amp;gt; Add&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;you can use the &lt;a href=&#34;https://jenkins-x.io/v3/develop/reference/jx/pipeline/debug/&#34;&gt;jx pipeline debug&lt;/a&gt; command then select the pipeline to add/remove a breakpoint.&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;viewing-breakpoints&#34;&gt;Viewing breakpoints&lt;/h3&gt;
&lt;p&gt;You can view breakpoints in the &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/lens/&#34;&gt;Lens UI&lt;/a&gt; in the &lt;code&gt;Breakpoints&lt;/code&gt; tab or via:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get lighthousebreakpoints
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;# you can use the short name:&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get lhbp
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h3 id=&#34;using-a-breakpoint&#34;&gt;Using a breakpoint&lt;/h3&gt;
&lt;p&gt;Once you have set a breakpoint defined for a particular Pipeline you need to trigger the pipeline. e.g. perform a git commit on the git branch to trigger a new pipeline to execute.&lt;/p&gt;
&lt;p&gt;The pipeline will execute as normal; you&amp;rsquo;ll be able to view it execute via:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/lens/&#34;&gt;Lens UI&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;run &lt;a href=&#34;https://jenkins-x.io/v3/develop/reference/jx/pipeline/grid/&#34;&gt;jx pipeline grid&lt;/a&gt; to watch pipelines run and select the one you wish to view the log&lt;/li&gt;
&lt;li&gt;run &lt;a href=&#34;https://jenkins-x.io/v3/develop/reference/jx/pipeline/log/&#34;&gt;jx pipeline log&lt;/a&gt; to watch the log of a specific pipeline&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;opening-a-shell&#34;&gt;Opening a shell&lt;/h3&gt;
&lt;p&gt;Once your breakpoint is reached the pipeline pod will pause, waiting to continue.&lt;/p&gt;
&lt;p&gt;At this point you can then open a shell inside the container.&lt;/p&gt;
&lt;p&gt;The easiest way to do this is via the &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/lens/&#34;&gt;Lens UI&lt;/a&gt;, click on the Pipeline action menu then &lt;code&gt;Shell&lt;/code&gt; -&amp;gt; &lt;code&gt;latest step&lt;/code&gt; and a shell will open.&lt;/p&gt;
&lt;p&gt;Otherwise you can use:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl exec -it -c $name-of-container $name-of-pod &lt;span style=&#34;color:#f92672&#34;&gt;(&lt;/span&gt;sh | bash | ash&lt;span style=&#34;color:#f92672&#34;&gt;)&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h3 id=&#34;continuing-after-the-breakpoint&#34;&gt;Continuing after the breakpoint&lt;/h3&gt;
&lt;p&gt;If you wish to continue the execution of a pipeline there are &lt;a href=&#34;https://github.com/tektoncd/pipeline/blob/main/docs/debug.md#debug-scripts&#34;&gt;multiple scripts you can run inside the shell&lt;/a&gt; you can run inside the shell in the pipeline to tell the pipeline to continue:&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;Script&lt;/th&gt;
&lt;th&gt;Description&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;/tekton/debug/scripts/debug-continue&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Mark the step as completed with success by writing to &lt;code&gt;/tekton/tools&lt;/code&gt; so that the pipeline continues executing&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;code&gt;/tekton/debug/scripts/debug-fail-continue&lt;/code&gt;&lt;/td&gt;
&lt;td&gt;Mark the step as completed with failure by writing to &lt;code&gt;/tekton/tools&lt;/code&gt; which can lead to the pipeline terminating&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;h3 id=&#34;removing-breakpoints&#34;&gt;Removing breakpoints&lt;/h3&gt;
&lt;p&gt;There are a few ways to delete breakpoints.&lt;/p&gt;
&lt;p&gt;You can run &lt;a href=&#34;https://jenkins-x.io/v3/develop/reference/jx/pipeline/debug/&#34;&gt;jx pipeline debug&lt;/a&gt; and toggle off any existing breakpoints.&lt;/p&gt;
&lt;p&gt;You can use the &lt;code&gt;Breakpoints&lt;/code&gt; tab in &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/lens/&#34;&gt;Lens UI&lt;/a&gt; then click the breakpoints action menu then &lt;code&gt;Remove&lt;/code&gt;&lt;/p&gt;
&lt;p&gt;Or find the one you want via:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get lhbp
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl delete lhbp whatever-the-name-is
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h2 id=&#34;conclusion&#34;&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;So there you have it; nice and easy debugging of pipelines so you can diagnose why pipelines fail and try incrementally fix things up from inside the pipeline pods! Pretty cool eh!&lt;/p&gt;
&lt;p&gt;Let us know via &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;slack&lt;/a&gt; or the &lt;a href=&#34;https://github.com/jenkins-x/jx/issues&#34;&gt;issue tracker&lt;/a&gt; if you can think of any ways we can make this even easier to use! Also check out the &lt;a href=&#34;https://github.com/tektoncd/community/blob/main/teps/0042-taskrun-breakpoint-on-failure.md&#34;&gt;Tekton enhancement proposal 42&lt;/a&gt; that covers this capability in the underlying tekton controller and pods.&lt;/p&gt;
&lt;p&gt;Finally please add your thumbs up emoji to the &lt;a href=&#34;https://github.com/tektoncd/pipeline/pull/4145&#34;&gt;tekton PR #4145&lt;/a&gt; :)&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: How to use GitOps and Kubernetes External Secrets for better audit and security</title>
      <link>https://jenkins-x.io/blog/2021/08/17/gitops-secrets/</link>
      <pubDate>Tue, 17 Aug 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/08/17/gitops-secrets/</guid>
      <description>
        
        
        &lt;p&gt;So &lt;strong&gt;GitOps&lt;/strong&gt; is a cool approach to managing kubernetes resources in a cluster, by checking in the source code for:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;the kubernetes YAMLs&lt;/li&gt;
&lt;li&gt;details of the helm charts you want to install along with any configuration&lt;/li&gt;
&lt;li&gt;kustomize scripts.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Then everything is versioned and audited; you know who changed what, when and why. If a change breaks things, just revert via git like any other source code change.&lt;/p&gt;
&lt;p&gt;You can then add pipelines to &lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-kube-test#readme&#34;&gt;verify&lt;/a&gt; changes in the Pull Requests result in valid kubernetes YAML etc.&lt;/p&gt;
&lt;p&gt;Then if you merge changes to git then an operator detect the change and do the &lt;code&gt;kubectl apply&lt;/code&gt; (or &lt;code&gt;helm install&lt;/code&gt; or whatever).&lt;/p&gt;
&lt;p&gt;There are a number of tools out there for doing this. e.g. &lt;a href=&#34;https://cloud.google.com/anthos/config-management&#34;&gt;Anthos Config Management&lt;/a&gt;, &lt;a href=&#34;https://argoproj.github.io/argo-cd/&#34;&gt;argo cd&lt;/a&gt;, &lt;a href=&#34;https://rancher.com/docs/rancher/v2.x/en/deploy-across-clusters/fleet/&#34;&gt;fleet&lt;/a&gt;, &lt;a href=&#34;https://fluxcd.io/&#34;&gt;flux cd&lt;/a&gt; and &lt;a href=&#34;https://github.com/vmware-tanzu/carvel-kapp-controller&#34;&gt;kapp controller&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;So why did Jenkins X not use these tools and instead created its own &lt;a href=&#34;https://github.com/jenkins-x/jx-git-operator&#34;&gt;git operator&lt;/a&gt;?&lt;/p&gt;
&lt;h2 id=&#34;standardising-gitops-layouts&#34;&gt;Standardising GitOps layouts&lt;/h2&gt;
&lt;p&gt;Over time it would be great to have more standardisation of the Git layout given the different tool.&lt;/p&gt;
&lt;p&gt;Our current recommended layout that works with many GitOps tools is &lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-gitops/blob/main/docs/git_layout.md&#34;&gt;described here&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&#34;why-jenkins-x-uses-helmfile-template&#34;&gt;Why Jenkins X uses helmfile template&lt;/h2&gt;
&lt;p&gt;A number of solutions in the GitOps space define which helm charts to install in git with configuration files; or specify which kustomize templates to apply etc.&lt;/p&gt;
&lt;p&gt;However Jenkins X defaults to using &lt;a href=&#34;https://github.com/roboll/helmfile&#34;&gt;helmfile&lt;/a&gt; to manage installing, upgrading and configuring multiple helm charts. Then we use &lt;strong&gt;&lt;code&gt;helmfile template&lt;/code&gt;&lt;/strong&gt; to render the helm charts as kubernetes resources.&lt;/p&gt;
&lt;p&gt;We do this for a very good reason; so that we can easily &lt;a href=&#34;https://jenkins-x.io/v3/develop/faq/general/#why-does-jenkins-x-use-helmfile-template&#34;&gt;version all kubernetes resources in git including those that come from a helm chart&lt;/a&gt; - which means you can easily view the entire history of changes of any kubernetes resources - whether they come from inside a helm chart, some configuration values of a chart or kustomize scripts etc.&lt;/p&gt;
&lt;p&gt;This avoids you having to mentally understand how helm charts will change over time with the helm chart version and/or helm configuration; or the effect of kustommize scripts. You can just view the history of any kubernetes resource.&lt;/p&gt;
&lt;p&gt;We use conventions to ensure that each kubernetes resource has a canonical file name in git to make this whole process much simpler.&lt;/p&gt;
&lt;p&gt;e.g. this is the git history of the &lt;a href=&#34;https://github.com/jenkins-x/jx3-eagle/commits/master/config-root/namespaces/cert-manager/cert-manager/cert-manager-cainjector-deploy.yaml&#34;&gt;cert manager deployment resource in our production cluster&lt;/a&gt; so you can see what changed when over time.&lt;/p&gt;
&lt;p&gt;The exception to this rule is kubernetes &lt;code&gt;Secrets&lt;/code&gt; which are stored instead as &lt;code&gt;ExternalSecrets&lt;/code&gt; but which have their own history (e.g. in case you change the location of where the secrets are stored or modify the metadata, annotations or labels etc).&lt;/p&gt;
&lt;h2 id=&#34;why-we-use-kubernetes-external-secrets&#34;&gt;Why we use Kubernetes External Secrets&lt;/h2&gt;
&lt;p&gt;Jenkins X 3.x uses &lt;a href=&#34;https://github.com/external-secrets/kubernetes-external-secrets&#34;&gt;Kubernetes External Secrets&lt;/a&gt; to manage populating secrets from your underlying secret store such as:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Alibaba Cloud KMS Secret Manager&lt;/li&gt;
&lt;li&gt;Amazon Secret Manager&lt;/li&gt;
&lt;li&gt;Azure Key Vault&lt;/li&gt;
&lt;li&gt;Hashicorp Vault&lt;/li&gt;
&lt;li&gt;GCP Secret Manager&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;mermaid&#34;&gt;
    
graph TB
    subgraph A[Kubernetes Cluster]
        sqB[External Secrets Controller]
        subgraph C[secrets-infra ns]
            sqCV[Cloud Secret Manager]
        end
        subgraph D[Kube api server]
        end
        D -- Get ExternalSecrets --&gt; sqB
        sqB --&gt; D
        sqB -- Fetch secrets properties --&gt; sqCV
        sqCV --&gt; sqB
        subgraph E[app ns]
            sqEP[pods]
            sqES[secrets]
        end
        sqB -- Upsert Secrets --&gt; sqES
    end

&lt;/div&gt;
&lt;p&gt;You can then keep all your secrets inside your cloud native secret store which also allows:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;easy to automatically rotate any secret  at any time independently of git&lt;/li&gt;
&lt;li&gt;use fine grained RBAC on each secret&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;how-to-use-this-approach-to-gitops-and-secrets-if-not-using-jenkins-x&#34;&gt;How to use this approach to GitOps and Secrets if not using Jenkins X&lt;/h2&gt;
&lt;p&gt;If you use &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;Jenkins X&lt;/a&gt; then you get all of the above benefits. But what if you want to use some other kind of GitOps operator toolchain?&lt;/p&gt;
&lt;p&gt;One option is to use the &lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-secret-postrenderer#jx-secret-postrenderer&#34;&gt;jx-secret-postrenderer&lt;/a&gt; yourself if you use helm or &lt;a href=&#34;https://github.com/roboll/helmfile&#34;&gt;helmfile&lt;/a&gt; to then render the helm charts as raw YAML you can check into your git repository and implementing the conversion from &lt;code&gt;Secret&lt;/code&gt; to &lt;code&gt;ExternalSecret&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;Another option is to reuse the Jenkins X &lt;code&gt;Makefile&lt;/code&gt; and pipeline to setup the &lt;code&gt;config-root&lt;/code&gt; &lt;a href=&#34;https://github.com/jenkins-x-plugins/jx-gitops/blob/main/docs/git_layout.md&#34;&gt;git layout&lt;/a&gt; after converting Secrets to ExternalSecretes and pre-populating any missing secret store values.&lt;/p&gt;
&lt;h2 id=&#34;summary&#34;&gt;Summary&lt;/h2&gt;
&lt;p&gt;If you are looking at adopting GitOps then we highly recommend you &lt;a href=&#34;https://jenkins-x.io/v3/develop/faq/general/#why-does-jenkins-x-use-helmfile-template&#34;&gt;check into git all of your kubernetes resources including those that come from a helm charts or kustomize scripts&lt;/a&gt; (apart from &lt;code&gt;Secrets&lt;/code&gt;!) as it massively simplifies understanding how kubernetes resources change over time using just pure git.&lt;/p&gt;
&lt;p&gt;If you are using GitOps you may want to look into using &lt;a href=&#34;https://github.com/external-secrets/kubernetes-external-secrets&#34;&gt;Kubernetes External Secrets&lt;/a&gt; to simplify integrating secrets for cloud native secret stores into your kubernetes cluster to provide finer grained RBAC and easier secret rotation.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3 and Argo CD</title>
      <link>https://jenkins-x.io/blog/2021/06/28/argo/</link>
      <pubDate>Mon, 28 Jun 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/06/28/argo/</guid>
      <description>
        
        
        &lt;p&gt;There have been a number of requests from the Jenkins X community to use &lt;a href=&#34;https://argoproj.github.io/argo-cd/&#34;&gt;Argo CD&lt;/a&gt; for the last mile deployment phase of their continuous delivery pipelines.  This blog explains some of the advantages of using Jenkins X and Argo CD all together.&lt;/p&gt;
&lt;p&gt;What&amp;rsquo;s included?&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Jenkins X for Cloud Infrastructure using Terraform, core installation management with GitOps, external secret management, ingress controller, quickstarts, automated CI + CD pipelines, ChatOps&lt;/li&gt;
&lt;li&gt;Tekton for pipeline orchestration&lt;/li&gt;
&lt;li&gt;Argo CD for end users application deployments (not the main installation)
Argo CD provides a declarative GitOps approach to deploying Kubernetes based applications.  There is a GUI which helps construct the deployment definition (in the form of an &lt;code&gt;Application&lt;/code&gt; custom resource) which offers a number of configuration options, as well and providing insight into your clusters applications.&lt;/li&gt;
&lt;/ul&gt;
&lt;img src=&#34;https://jenkins-x.io/images/v3/argocd.png&#34;/&gt;
&lt;hr&gt;
&lt;p&gt;You might be wondering why you would want to use BOTH Jenkins X and Argo CD together.
Jenkins X aims to embrace OSS, where possible providing a nice UX to integrate with other projects and help provide better solutions for building, developing and running software on Kubernetes.  Jenkins X indeed does have a git operator that applies Kubernetes YAML from a Git repository but there are some differences:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;Jenkins X uses GitOps principles for the entire installation, i.e. the starting point is a Git repository which is used to provision a cluster and manage (automatic if users wish) upgrades whereas today Argo CD uses a manual &lt;code&gt;kubectl apply&lt;/code&gt; to manage the Argo installation itself.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;External Secrets integration for Vault, Google Secrets manager etc is something that Jenkins X provides out of the box.  When Kubernetes based applications require a secret we prefer the source is stored in a secrets manager and the value synchronised automatically into the cluster enabling easier secret rotation, avoiding local secrets on machines and an easier UX for working with secrets.  When adding an Application via Argo CD users can leverage the Jenkins X approach to working with secrets and rely on Argo to manage the deployments.  If users prefer to work with SOPS that is totally fine too and will work in the same way as they are used to.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;If you do not wish to expose direct access for the Kubernetes cluster to developers then using a combination of Jenkins X UI for accessing logs and Argo CD for managing application deployments may be enough.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Using the Jenkins X approach to promoting via automated pull requests via pipelines to add new helm charts and update chart release version numbers.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;In a Jenkins X &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/multi-cluster/multi-cluster/&#34;&gt;multi cluster&lt;/a&gt; setup you can choose to use jx-git-operator or Argo CD in the remote cluster to syncronise promoted applications into the staging or production clusters.  This way you get all the benefits of the integrated Jenkins X experience to manage the build infrastructure and provide the developer experience like preview environments and chatops etc.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This is done by creating a new Git repository that will contain a number of Argo CD &lt;code&gt;Application&lt;/code&gt; Kubernetes resources.  This also means we handle disaster recovery scenarios and are able to recover the Jenkins X installation which includes Argo CD plus any applications managed by Argo CD itself.&lt;/p&gt;
&lt;p&gt;There may be a couple of models to try but here we are going to describe an approach we have validated when using Jenkins X to manage the core Kubernetes installation, using Tekton for Continuous Integration, Jenkins X for application promotion and Argo CD for deployments.&lt;/p&gt;
&lt;h2 id=&#34;install-argo-cd-with-jenkins-x&#34;&gt;Install Argo CD with Jenkins X&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;Prerequisite is a working Jenkins X 3 installation&lt;/li&gt;
&lt;/ul&gt;
&lt;ol&gt;
&lt;li&gt;Add a Argo CD helmefile to your Jenkins X cluster git repository:&lt;/li&gt;
&lt;/ol&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;mkdir -p helmfiles/argocd
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Create a new file&lt;/p&gt;
&lt;p&gt;&lt;code&gt;./helmfiles/argocd/helmfile.yaml&lt;/code&gt;&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;namespace&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;argocd&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;releases&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;chart&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;argocd/argo-cd&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;argocd&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;chart&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;../../charts/argo-applications&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;argo-applications&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Edit the root &lt;code&gt;./helmfile.yaml&lt;/code&gt; and add a new path reference to the helmfile above&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;path&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;helmfiles/argocd/helmfile.yaml&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Jenkins X will resolve default helm values from the Jenkins X version stream.&lt;/p&gt;
&lt;ol start=&#34;2&#34;&gt;
&lt;li&gt;
&lt;p&gt;Create a new git repository to contain the Argo CD &lt;code&gt;Application&lt;/code&gt; Kubernetes resources, this means we can use Jenkins X pipelines to promote users applications via GitOps.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;Back in your clusters Git repository create a new folder:&lt;/p&gt;
&lt;/li&gt;
&lt;/ol&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;mkdir -p charts/argo-applications
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;create a file in the new folder and replace the &lt;code&gt;repoURL:&lt;/code&gt; with the Git URL from step 2 above.&lt;/p&gt;
&lt;p&gt;&lt;code&gt;charts/argo-applications/applications.yaml&lt;/code&gt;&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;apiVersion&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;argoproj.io/v1alpha1&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;kind&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;Application&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;metadata&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;staging&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;namespace&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;argocd&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;finalizers&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#ae81ff&#34;&gt;resources-finalizer.argocd.argoproj.io&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;spec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;destination&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;&amp;#39;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;namespace&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;argocd&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;server&lt;/span&gt;: &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;https://kubernetes.default.svc&amp;#39;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;source&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;path&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;.&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;repoURL&lt;/span&gt;: &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;https://github.com/$REPLACE_WITH_GIT_OWNER/  $REPLACE_WITH_GIT_REPO&amp;#39;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;targetRevision&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;HEAD&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;directory&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      &lt;span style=&#34;color:#f92672&#34;&gt;recurse&lt;/span&gt;: &lt;span style=&#34;color:#66d9ef&#34;&gt;true&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;project&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;default&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;syncPolicy&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;automated&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      &lt;span style=&#34;color:#f92672&#34;&gt;prune&lt;/span&gt;: &lt;span style=&#34;color:#66d9ef&#34;&gt;true&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      &lt;span style=&#34;color:#f92672&#34;&gt;selfHeal&lt;/span&gt;: &lt;span style=&#34;color:#66d9ef&#34;&gt;true&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;syncOptions&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      - &lt;span style=&#34;color:#ae81ff&#34;&gt;Replace=true&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      - &lt;span style=&#34;color:#ae81ff&#34;&gt;CreateNamespace=true&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ol start=&#34;4&#34;&gt;
&lt;li&gt;commit your changes and push&lt;/li&gt;
&lt;/ol&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;git add helmfiles/argocd/helmfile.yaml
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;git add charts/argo/applications.yaml
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;git commit -m &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#39;feat: enable Argo CD&amp;#39;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;git push
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;If you are on a fork then PR your changes&lt;/p&gt;
&lt;ol start=&#34;5&#34;&gt;
&lt;li&gt;Follow Jenkins X admin logs to ensure Argo CD is installed&lt;/li&gt;
&lt;/ol&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx admin logs
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ol start=&#34;6&#34;&gt;
&lt;li&gt;Get the Argo CD UI password using something like &lt;a href=&#34;https://github.com/mfuentesg/ksd&#34;&gt;ksd&lt;/a&gt; or &lt;code&gt;base64 -D&lt;/code&gt; to decode the value:&lt;/li&gt;
&lt;/ol&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get secret argocd-initial-admin-secret -n argocd -oyaml | ksd
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ol start=&#34;7&#34;&gt;
&lt;li&gt;Get the Argo CD UI hostname and login using the &lt;code&gt;admin&lt;/code&gt; username + passowrd from step 6 above (you may need to accept insecure TLS browser prompt if not using production TLS)&lt;/li&gt;
&lt;/ol&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get ing argocd-server -n argocd
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ol start=&#34;8&#34;&gt;
&lt;li&gt;Create a new quickstart or update an existing Jenkins X applications &lt;code&gt;./lighthouse/jenkins-x/release.yaml&lt;/code&gt; pipeline, replaceing the Tekton &lt;code&gt;promote-jx-promote&lt;/code&gt; step to use argo instead:&lt;/li&gt;
&lt;/ol&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:jenkins-x/jx3-pipeline-catalog/tasks/updatebot/release.yaml@versionStream&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;promote-release&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;script&lt;/span&gt;: |&lt;span style=&#34;color:#e6db74&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;    #!/usr/bin/env sh
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;    source .jx/variables.sh
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;    jx updatebot argo promote --target-git-url https://github.com/$REPLACE_WITH_GIT_OWNER/$REPLACE_WITH_GIT_REPO&lt;/span&gt;    
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Now merge a change to your application or manually trigger a release pipeline &lt;code&gt;jx pipeline start&lt;/code&gt; to get a new release and promote using Argo CD.
Once the release pipeline finished for your application you should see a new &lt;code&gt;application.yaml&lt;/code&gt; resource in your uber application Git repository we created in step 2 above.
Once this change is merged to the main branch Argo detects the new chart / version and applies it to the cluster.  You will be able to track the status and health of the deployment via the GUI that you logged in with step 7 above.&lt;/p&gt;
&lt;h1 id=&#34;conclusion&#34;&gt;Conclusion&lt;/h1&gt;
&lt;p&gt;I really did like the experience of Argo CD, there&amp;rsquo;s some overlaps with Jenkins X across the wider projects however I think there&amp;rsquo;s enough of a differentiation for both to complement each other.  What I loved was that both projects as well as others like &lt;a href=&#34;https://www.weave.works/oss/flux/&#34;&gt;flux&lt;/a&gt; promote the use of GitOps.  Anyways, congratulations to the Argo project and I hope users from both communities find this blog useful and / or interesting.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Continuous microservices with databases in Jenkins X</title>
      <link>https://jenkins-x.io/blog/2021/06/25/jx-cd-databases-2021/</link>
      <pubDate>Fri, 25 Jun 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/06/25/jx-cd-databases-2021/</guid>
      <description>
        
        
        &lt;p&gt;A common question we get asked on the &lt;a href=&#34;https://jenkins-x.io/&#34;&gt;Jenkins X project&lt;/a&gt; is how to get started creating microservices that use databases with &lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/&#34;&gt;automated CI/CD&lt;/a&gt; with &lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/promotion/&#34;&gt;GitOps Promotion&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/preview/&#34;&gt;Preview Environments&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;To make things a little easier to get started we&amp;rsquo;ve created a new &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql&#34;&gt;node-postgresql&lt;/a&gt; quickstart.&lt;/p&gt;
&lt;h2 id=&#34;before-you-start&#34;&gt;Before you start&lt;/h2&gt;
&lt;p&gt;If you are using the cloud then we prefer &lt;a href=&#34;https://jenkins-x.io/v3/devops/patterns/prefer_cloud_over_kube/&#34;&gt;cloud over kubernetes&lt;/a&gt; for things like databases, storage, ingress and secret managers so please try use your clouds managed databases if you can.&lt;/p&gt;
&lt;p&gt;So ideally you&amp;rsquo;d set up your database via your infrastructure as code solution, such as &lt;a href=&#34;https://www.terraform.io/&#34;&gt;terraform&lt;/a&gt;, and then associate your &lt;a href=&#34;https://jenkins-x.io/v3/devops/patterns/map-sa-to-cloud-iam/&#34;&gt;kubernetes Service Account to a cloud IAM role&lt;/a&gt; to access the database.&lt;/p&gt;
&lt;p&gt;However to provide something simple that just works in any kubernetes cluster this quickstart uses the &lt;a href=&#34;https://github.com/zalando/postgres-operator&#34;&gt;postgres-operator&lt;/a&gt; to manage setting up each database cluster in each environment. So to be able to use this quickstart you will need to install this operator into your cluster.&lt;/p&gt;
&lt;p&gt;You can &lt;a href=&#34;https://jenkins-x.io/v3/develop/apps/#using-the-cli&#34;&gt;add charts to your cluster via the CLI&lt;/a&gt;. From inside a git clone of your cluster git repository run the following command:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx gitops helmfile add --chart commonground/postgres-operator --repository https://charts.commonground.nl/ --namespace postgres --version 1.6.2
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;This will modify the &lt;code&gt;helmfile.yaml&lt;/code&gt; to point at a new &lt;code&gt;helmfiles/postgres/helmfile.yaml&lt;/code&gt; file to deploy the &lt;a href=&#34;https://github.com/zalando/postgres-operator&#34;&gt;postgres-operator&lt;/a&gt; chart.&lt;/p&gt;
&lt;p&gt;Then git commit and push that change to your cluster. You can watch it run via &lt;code&gt;jx admin log -w&lt;/code&gt;.&lt;/p&gt;
&lt;h2 id=&#34;create-the-quickstart&#34;&gt;Create the quickstart&lt;/h2&gt;
&lt;p&gt;Make sure you have an &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/cluster/&#34;&gt;up to date cluster&lt;/a&gt; as this particular quickstart is new and only shows up in recent clusters.&lt;/p&gt;
&lt;p&gt;Now &lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/#create-a-new-project-from-a-quickstart&#34;&gt;create the quickstart&lt;/a&gt; in the usual way&amp;hellip;&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx project quickstart
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;If you know you want to create the &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql&#34;&gt;node-postgresql&lt;/a&gt; quickstart you can do this to pre-filter the list for you:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx project quickstart -f postgres
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Once you have finished the import process will &lt;a href=&#34;https://jenkins-x.io/v3/about/how-it-works/#importing--creating-quickstarts&#34;&gt;set up the webhooks and enable CI/CD&lt;/a&gt; and the application will be released and promoted to the staging environment.&lt;/p&gt;
&lt;p&gt;If you want to know more about what happens as you create quickstarts or import projects &lt;a href=&#34;https://jenkins-x.io/v3/about/how-it-works/#importing--creating-quickstarts&#34;&gt;see how it works&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;You can watch via the various pipelines run in the various &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/&#34;&gt;UI options&lt;/a&gt; or via the CLI use:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx pipeline grid 
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;When the release is done and the promotion has completed you should be able to try it out via:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx application get 
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;You should be able to click on the URL for the new quickstart and try it out once the database is initialised and the pods start up.&lt;/p&gt;
&lt;p&gt;It can take a few minutes first time you deploy the quickstart for the database cluster to be setup and initialised; so you can watch the pods run via&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get pod -n jx-staging -w 
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;For a deeper look into whats going on try:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx ui
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Which will open the &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/octant/&#34;&gt;Octant UI with the Jenkins X plugin&lt;/a&gt; which lets you navigate around namespaces and look at all of your kubernetes resources, deployments, pods and so forth in real time.&lt;/p&gt;
&lt;h2 id=&#34;how-does-it-work&#34;&gt;How does it work&lt;/h2&gt;
&lt;p&gt;In many ways this chart is fairly similar to other quickstarts in that it uses the Jenkins X pipeline catalog with tekton to add automated CI/CD pipelines and so forth.&lt;/p&gt;
&lt;p&gt;However to support the database there is a custom chart included inside this quickstart that does a few different things&amp;hellip;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;it creates a &lt;code&gt;Postgresql&lt;/code&gt; custom resource for the &lt;a href=&#34;https://github.com/zalando/postgres-operator&#34;&gt;postgres-operator&lt;/a&gt; which will instruct the &lt;a href=&#34;https://github.com/zalando/postgres-operator&#34;&gt;postgres-operator&lt;/a&gt; to spin up a database cluster and generate a &lt;code&gt;Secret&lt;/code&gt; to access the database. You can view this in your file at &lt;code&gt;charts/$myAppName/templates/&lt;/code&gt; or &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql/blob/master/charts/templates/db-postgresql.yaml&#34;&gt;this file in the quickstart&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;there is a &lt;code&gt;charts/$myAppName/init.sql&lt;/code&gt; file or &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql/blob/master/charts/init.sql&#34;&gt;this file in the quickstart&lt;/a&gt; which is used to setup the database tables and populate any initial data. You can use this file to perform any startup schema migration or data population. For more realistic applications you could use a custom tool and image to implement schema migration in a more sophisticated way.&lt;/li&gt;
&lt;li&gt;the &lt;code&gt;init.sql&lt;/code&gt; script is then installed as a &lt;code&gt;ConfigMap&lt;/code&gt; via the &lt;code&gt;charts/$myAppName/templates/initdb-cm.yaml&lt;/code&gt; file or &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql/blob/master/charts/templates/initdb-cm.yaml&#34;&gt;this file in the quickstart&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;the &lt;code&gt;charts/$myAppName/templates/deployment.yaml&lt;/code&gt; file or &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql/blob/master/charts/templates/deployment.yaml#L41-L57&#34;&gt;this file in the quickstart&lt;/a&gt; defines:
&lt;ul&gt;
&lt;li&gt;an in &lt;a href=&#34;https://kubernetes.io/docs/concepts/workloads/pods/init-containers/&#34;&gt;init container&lt;/a&gt; which sets up the database before the application starts to run. The nice thing about using an init container for schema migration is that it runs before any new version of your application gets any network traffic so that you can keep iterating on your microservice and keep changing your database schema across all of your environments and things work well.
&lt;ul&gt;
&lt;li&gt;Though make sure your init container performs database locking correctly so that multiple init containers running concurrently don&amp;rsquo;t block each other unnecessarily. If this becomes an issue you could introduce something a little more complex. e.g. include a &lt;code&gt;Job&lt;/code&gt; with a unique name for each release in your chart to perform the migration so that only one migration Job runs at once and have your &lt;a href=&#34;https://kubernetes.io/docs/concepts/workloads/pods/init-containers/&#34;&gt;init container&lt;/a&gt; wait for your job to complete.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;the Deployment also uses &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql/blob/master/charts/templates/deployment.yaml#L69-L73&#34;&gt;a secret created by the postgresql operator&lt;/a&gt; to be able to connect to the database&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;previews&#34;&gt;Previews&lt;/h3&gt;
&lt;p&gt;Databases often need a fair amount of maintenance, backup, upgrading and clean up over time. e.g. you may periodically update your Staging database with data from Production (maybe anonymised in some way?).&lt;/p&gt;
&lt;p&gt;So creating a whole new database from scratch for every &lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/preview/&#34;&gt;Preview Environment&lt;/a&gt; to test every code change in your microservice is maybe overkill.&lt;/p&gt;
&lt;p&gt;By default the preview environment of this quickstart is configured to reuse the Staging environments database. This speeds up the preview startup time and reduces your cloud footprint and infrastructure cost.&lt;/p&gt;
&lt;p&gt;This is done via:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql/blob/master/preview/values.yaml.gotmpl#L1-L7&#34;&gt;configuring the preview environment&lt;/a&gt; to point at the database in the staging namespace and disabling the creation of the Posgresql custom resource to create a new database cluster in the preview environment&lt;/li&gt;
&lt;li&gt;using the &lt;a href=&#34;https://github.com/roboll/helmfile#hooks&#34;&gt;helmfile hooks mechanism&lt;/a&gt; in previews to &lt;a href=&#34;https://github.com/jenkins-x-quickstarts/node-postgresql/blob/master/preview/helmfile.yaml#L32-L44&#34;&gt;copy the required database secrets from the staging namespace&lt;/a&gt; so that the preview can connect to the staging database.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;how-we-can-improve&#34;&gt;How we can improve&lt;/h2&gt;
&lt;p&gt;This quickstart is just a start but we can improve in a number of directions - fancy &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;helping out&lt;/a&gt;?&lt;/p&gt;
&lt;h3 id=&#34;more-languages-and-frameworks&#34;&gt;More languages and frameworks&lt;/h3&gt;
&lt;p&gt;It should be easy to replicate the same kind of quickstart mechanism for other languages and frameworks if anyone fancies trying it out? :) We &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;love contributions&lt;/a&gt;! Pop by and chat with us on &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;slack&lt;/a&gt; if you want to discuss it further.&lt;/p&gt;
&lt;h3 id=&#34;cloud-databases&#34;&gt;Cloud databases&lt;/h3&gt;
&lt;p&gt;Longer term it would be nice to support other kinds of database operators too.&lt;/p&gt;
&lt;p&gt;We prefer &lt;a href=&#34;https://jenkins-x.io/v3/devops/patterns/prefer_cloud_over_kube/&#34;&gt;cloud over kubernetes&lt;/a&gt; so if you are using a cloud it would be better to default to a cloud database instead of a kubernetes hosted one.&lt;/p&gt;
&lt;p&gt;There are a number of other ways to define cloud infrastructure via &lt;a href=&#34;https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/&#34;&gt;Custom Resources&lt;/a&gt; such as:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://aws-controllers-k8s.github.io/community/&#34;&gt;AWS Controllers for Kubernetes&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/Azure/azure-service-operator&#34;&gt;Azure Service Operator&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://crossplane.io/&#34;&gt;Crossplane&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://cloud.google.com/config-connector/docs/overview&#34;&gt;Google Config Connector&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;So it&amp;rsquo;d be interesting to see if we can replicate this model for other kinds of cloud database on different cloud providers. Mostly it&amp;rsquo;d be a &lt;a href=&#34;https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/&#34;&gt;Custom Resources&lt;/a&gt; to define the database instance and a way to inject the host and secret.  Some database providers require an additional sidecar proxy too.&lt;/p&gt;
&lt;p&gt;It would be easy to add optional configuration in the quickstart to support either the &lt;a href=&#34;https://github.com/zalando/postgres-operator&#34;&gt;postgres-operator&lt;/a&gt; or equivalents in &lt;a href=&#34;https://aws-controllers-k8s.github.io/community/&#34;&gt;AWS Controllers for Kubernetes&lt;/a&gt;, &lt;a href=&#34;https://github.com/Azure/azure-service-operator&#34;&gt;Azure Service Operator&lt;/a&gt;, &lt;a href=&#34;https://crossplane.io/&#34;&gt;Crossplane&lt;/a&gt; or &lt;a href=&#34;https://cloud.google.com/config-connector/docs/overview&#34;&gt;Google Config Connector&lt;/a&gt; via a simple flag in the &lt;code&gt;chart/$name/values.yaml&lt;/code&gt; file&lt;/p&gt;
&lt;h3 id=&#34;more-modularity-options&#34;&gt;More modularity options&lt;/h3&gt;
&lt;p&gt;In a pure microservice kind of world, each database would be owned by a single microservice; so embedding the database definition and schema migration into a single helm chart is the simplest thing that can work across multiple environments and with progressive delivery etc. It makes it easier to tie changes to the microservice and schema together into a single chart.&lt;/p&gt;
&lt;p&gt;However sometimes you want to have multiple services sharing a database. For that you could have 1 microservice be the owner of the database and other services reuse it. Or you could separate out the database definition + migration to a separate helm chart which is released independently.&lt;/p&gt;
&lt;p&gt;So it might make sense to make separate quickstart just to define the database definition and schema migration for these use cases: maybe via a &lt;code&gt;Job&lt;/code&gt; rather than an &lt;a href=&#34;https://kubernetes.io/docs/concepts/workloads/pods/init-containers/&#34;&gt;init container&lt;/a&gt;).&lt;/p&gt;
&lt;h2 id=&#34;conclusion&#34;&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;So there&amp;rsquo;s a really quick way to spin up a node based microservice using a database with an operator handling the setup of the database cluster which works well with &lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/promotion/&#34;&gt;multiple environments&lt;/a&gt;, progressive delivery and &lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/preview/&#34;&gt;Preview Environments&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Give it a try and &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;let us know how you get on or if you can think of any more ways we can improve&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X at cdCon</title>
      <link>https://jenkins-x.io/blog/2021/06/22/jx-cdcon-2021/</link>
      <pubDate>Tue, 22 Jun 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/06/22/jx-cdcon-2021/</guid>
      <description>
        
        
        &lt;p&gt;&lt;a href=&#34;https://events.linuxfoundation.org/cdcon/&#34;&gt;cdCon 2021&lt;/a&gt; is about to start with lots of &lt;a href=&#34;https://events.linuxfoundation.org/cdcon/program/schedule/&#34;&gt;great sessions&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Here&amp;rsquo; a list of the &lt;a href=&#34;https://jenkins-x.io/&#34;&gt;Jenkins X related&lt;/a&gt; sessions:&lt;/p&gt;
&lt;h2 id=&#34;tuesday-june-22-gitops-summit&#34;&gt;Tuesday, June 22 GitOps Summit&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://sched.co/il6v&#34;&gt;Best Practices for Secret Management with GitOps&lt;/a&gt; - &lt;a href=&#34;https://gitopssummit2021.sched.com/speaker/kdelamarck&#34;&gt;Kara de la Marck&lt;/a&gt;, CloudBees
&lt;ul&gt;
&lt;li&gt;GitOps uses Git as the “single source of truth” for declarative infrastructure and enables developers to manage infrastructure with the same Git-based workflows they use to manage a codebase. Having all configuration files version-controlled by Git has many advantages, but best practices for securely managing secrets with GitOps remain contested. Join us in this presentation about GitOps and Secret Management. Attendees will learn about different approaches to secret management with GitOps, the issues involved, and the secret management solutions offered by various tools and platforms. We will discuss the pros and cons of Vault, SOPS, offerings by public cloud providers, and more.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;wednesday-june-23&#34;&gt;Wednesday, June 23&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://sched.co/ios6&#34;&gt;MLOps with Jenkins-X: Production-ready Machine Learning&lt;/a&gt; by &lt;a href=&#34;https://cdcon2021.sched.com/speaker/terry289&#34;&gt;Terry Cox&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;Explore ways to treat Machine Learning assets as first class citizens within a DevOps process as Jenkins-X MLOps Lead, Terry Cox demonstrates how to automate your training and release pipeline in Cloud environments, using the library of ML template projects provided with Jenkins-X.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://sched.co/iouo&#34;&gt;Enabling a DevOps Mindset at Scale in an Enterprise&lt;/a&gt; by Jimmy McNamara &amp;amp; Nick Penston, Fidelity Investments
&lt;ul&gt;
&lt;li&gt;Talk through the cultural enablers to create a strong DevOps culture within large organisations. Nick and Jimmy will talk through the cultural enablers to support large numbers of very talented and ambitious cloud engineers. Touching on strategies supporting strong communication and talent development for cloud engineers. Key themes: Talent Development Enabling DevOps culture Harnessing the voice of the developer/cloud engineer&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://sched.co/j06v&#34;&gt;BoF Session: Jenkins X - James Strachan &amp;amp; James Rawlings, Cloudbees&lt;/a&gt; by James Strachan &amp;amp; James Rawlings
&lt;ul&gt;
&lt;li&gt;This BoF will be an open discussion on anything related to Jenkins X, automating Continuous Delivery, Kubernetes, cloud and how to Accelerate delivering value to your customers&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;thursday-june-24&#34;&gt;Thursday, June 24&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&#34;https://sched.co/ios0&#34;&gt;How Jenkins X is Integrating Observability from the Inside, and the Benefits for its Users&lt;/a&gt; by &lt;a href=&#34;https://cdcon2021.sched.com/speaker/vincent.behar1&#34;&gt;Vincent Behar&lt;/a&gt;, Dailymotion&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;In this session, we&amp;rsquo;ll focus on observability for Jenkins X: what observability means for a Continuous Delivery platform such as Jenkins X, and why it&amp;rsquo;s important.&lt;/li&gt;
&lt;li&gt;We&amp;rsquo;ll see how Jenkins X v3 is integrating observability from the inside, using standards such as OpenTelemetry, and packaging a full observability stack using Grafana - with Loki, Promtail, Tempo, and Prometheus.&lt;/li&gt;
&lt;li&gt;And we&amp;rsquo;ll highlight the benefits for the users:
&lt;ul&gt;
&lt;li&gt;platform observability with alerting for all the Kubernetes components (Lighthouse, Tekton, Cert-Manager, &amp;hellip;)&lt;/li&gt;
&lt;li&gt;out-of-the-box dashboards for Continuous Delivery Indicators (Mean Lead Time, Time To Review, Release, and Deployment Frequency, &amp;hellip;)&lt;/li&gt;
&lt;li&gt;distributed traces for your pipelines&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&#34;https://sched.co/iotV&#34;&gt;What&amp;rsquo;s new with Jenkins X 3&lt;/a&gt; by James Rawlings &amp;amp; James Strachan, CloudBees&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;This session will cover the architectural improvements and new features of Jenkins X v3.&lt;/li&gt;
&lt;li&gt;We&amp;rsquo;ll dive into the key areas that have undergone major development.&lt;/li&gt;
&lt;li&gt;GitOps: a better approach to installation and upgrades leveraging Helmfile, using an in-cluster operator to apply desired state stored in Git.&lt;/li&gt;
&lt;li&gt;Secrets: out of the box integration with external secret management solutions such as Google + Amazon cloud services Infrastructure: decoupled infrastructure management using Terraform UX: hosted dashboard to link your pull request logs along with a local Octant UI for deeper cluster visualisations&lt;/li&gt;
&lt;li&gt;Cloud Native Pipelines: now using vanilla Tekton pipelines with no abstraction layer.&lt;/li&gt;
&lt;li&gt;Along with Lighthouse to handle both in repo and shared pipeline definitions we now have a clean, extendable way to describe pipelines. Health: health checks and insight via Grafana&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&#34;https://sched.co/iote&#34;&gt;Embrace ChatOps by Following the git-flow as Usual&lt;/a&gt; by &lt;a href=&#34;https://cdcon2021.sched.com/speaker/rick417&#34;&gt;Rick Zhao&lt;/a&gt;, Qingcloud&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Simplicity matters. It’s not desirable for us to invest in more systems or platforms. The best scenario is to keep our daily work unchanged. For example, software engineers usually spend a lot of time writing codes or documents and also have interactions with various pull requests. Lighthouse is similar to Prow, but it supports multiple git providers. We can speed up delivery no matter if you&amp;rsquo;re using GitHub, Gitlab, or Gitea.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Don&#39;t use docker, use kubernetes</title>
      <link>https://jenkins-x.io/blog/2021/05/17/dont-use-docker/</link>
      <pubDate>Mon, 17 May 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/05/17/dont-use-docker/</guid>
      <description>
        
        
        &lt;p&gt;Are you developing software that&amp;rsquo;s intended to run on kubernetes? If so we recommend not to use docker on your laptop.&lt;/p&gt;
&lt;p&gt;Docker on Windows/MacOS helps you run a VM that can then run linux containers easily. But why bother?&lt;/p&gt;
&lt;p&gt;We highly recommend just use a development kubernetes cluster - build and run your containers there instead then you&amp;rsquo;re closer to a production like environment.&lt;/p&gt;
&lt;h2 id=&#34;why-use-kubernetes-instead-of-docker&#34;&gt;Why use kubernetes instead of docker?&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;why test on a completely different VM and container orchestrator than production? It&amp;rsquo;s better to test on a similar environment to where you are really going to deploy your code&lt;/li&gt;
&lt;li&gt;test your kubernetes yaml / helm chart and associated configuration at the same time as you run your containers helps you catch mistakes earlier:
&lt;ul&gt;
&lt;li&gt;it&amp;rsquo;s not just about running the container image; it&amp;rsquo;s about lots of other things too like networking, configuration, secrets, storage/volumes, cloud infrastructure, service mesh, liveness/readiness/startup probes - so why not test all of those things rather than just the image?&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;some corporate environments don&amp;rsquo;t let you run VMs on your laptop anyway so running docker locally isn&amp;rsquo;t an option&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;how-to-get-kubernetes&#34;&gt;How to get kubernetes?&lt;/h2&gt;
&lt;p&gt;First you&amp;rsquo;ll need a kubernetes cluster.&lt;/p&gt;
&lt;p&gt;I fully agree with James Ward that &lt;a href=&#34;https://twitter.com/_JamesWard/status/1393270529474408450?s=20&#34;&gt;developers should not need to run kubernetes&lt;/a&gt;. Friends don&amp;rsquo;t let friends setup and manage kubernetes clusters by hand :).&lt;/p&gt;
&lt;p&gt;So try ask your infrastructure team for a development cluster or, if you can, use the cloud to set-up a managed kubernetes cluster. All the public clouds have a relatively straightforward way to spin up a fully managed kubernetes cluster for you that will be relatively inexpensive &amp;amp; they are easy to scale down when you don&amp;rsquo;t need them.&lt;/p&gt;
&lt;p&gt;e.g. on &lt;a href=&#34;https://cloud.google.com/kubernetes-engine&#34;&gt;Google Cloud&lt;/a&gt; it&amp;rsquo;s a couple of clicks and about 5 minutes later you&amp;rsquo;ll have a fully managed kubernetes cluster ready to use. Its easy to enable auto-scaling too. Plus there&amp;rsquo;s a free tier.&lt;/p&gt;
&lt;p&gt;If that&amp;rsquo;s not easy for you to achieve you could try reuse a namespace in your staging cluster? Though we don&amp;rsquo;t recommend developing on a production cluster; its too easy to accidentally mess up production; e.g. by using up too many resources or overwriting a cluster scoped resource like a &lt;code&gt;CustomResourceDefinition&lt;/code&gt; or &lt;code&gt;ClusterRole&lt;/code&gt; etc.&lt;/p&gt;
&lt;p&gt;If you have zero budget you could try &lt;a href=&#34;https://minikube.sigs.k8s.io/docs/start/&#34;&gt;minikube&lt;/a&gt; or &lt;a href=&#34;https://kind.sigs.k8s.io/docs/user/quick-start/&#34;&gt;kind&lt;/a&gt; on top of docker; though its much better to reuse as close to the production setup of kubernetes as you can - there can be large variations in platform, version, setup, network, machine size and so forth.&lt;/p&gt;
&lt;p&gt;If you are deploying software on kubernetes then I&amp;rsquo;d hope you&amp;rsquo;ve some managed kubernetes solution; so why not use that and spin up another cluster for your team for development?&lt;/p&gt;
&lt;p&gt;If your budget is so stretched that you can&amp;rsquo;t afford 2 kubernetes clusters; one for production and one for development + staging; maybe it&amp;rsquo;s time to look at using just pure serverless / FaaS instead of kubernetes anyway? Even in that case it&amp;rsquo;s better to use your serverless / FaaS infrastructure than docker locally for similar reasons.&lt;/p&gt;
&lt;h2 id=&#34;how-do-i-connect-to-kubernetes&#34;&gt;How do I connect to kubernetes?&lt;/h2&gt;
&lt;p&gt;So first you&amp;rsquo;ll need to &lt;a href=&#34;https://kubernetes.io/docs/tasks/tools/&#34;&gt;install kubectl&lt;/a&gt; and connect to your kubernetes cluster. This step is provider specific - so refer to your kubernetes provider / cloud vendor for that bit.&lt;/p&gt;
&lt;p&gt;You can then verify you are connected by running some &lt;a href=&#34;https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get&#34;&gt;kubectl get&lt;/a&gt; commands such as&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get ns
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get node
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get pod
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h2 id=&#34;how-do-i-replace-docker-with-kubernetes&#34;&gt;How do I replace docker with kubernetes?&lt;/h2&gt;
&lt;h3 id=&#34;docker-run--kubectl-run&#34;&gt;docker run =&amp;gt; kubectl run&lt;/h3&gt;
&lt;p&gt;Instead of &lt;code&gt;docker run&lt;/code&gt; to run container images you can use &lt;a href=&#34;https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#run&#34;&gt;kubectl run&lt;/a&gt; to run a container image&lt;/p&gt;
&lt;p&gt;If you wish to expose a DNS name for a pod you can use &lt;a href=&#34;https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#expose&#34;&gt;kubectl expose&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&#34;docker-build--kubectl-build&#34;&gt;docker build =&amp;gt; kubectl build&lt;/h3&gt;
&lt;p&gt;A drop in replacement for &lt;code&gt;docker build&lt;/code&gt; is this &lt;a href=&#34;https://github.com/vmware-tanzu/buildkit-cli-for-kubectl#buildkit-cli-for-kubectl&#34;&gt;kubectl plugin&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://raw.githubusercontent.com/vmware-tanzu/buildkit-cli-for-kubectl/main/docs/pants-cast.svg&#34; alt=&#34;Pants Cast&#34;&gt;&lt;/p&gt;
&lt;h3 id=&#34;compose--helm&#34;&gt;compose =&amp;gt; helm&lt;/h3&gt;
&lt;p&gt;Some folks use docker compose files to define all of their various microservices; front end, back end, database etc.&lt;/p&gt;
&lt;p&gt;If you have deployed your applications to staging/production then you are probably already using either &lt;a href=&#34;https://helm.sh/&#34;&gt;helm charts&lt;/a&gt; or kubernetes yaml to define those deployments and services already.&lt;/p&gt;
&lt;p&gt;So just reuse all of them when running things locally in your own cluster/namespace.&lt;/p&gt;
&lt;p&gt;Then you don&amp;rsquo;t have to keep 2 completely different configuration files in sync; you can usually just reuse the same helm charts in all environments and clusters.&lt;/p&gt;
&lt;p&gt;If you have some compose files you could try out &lt;a href=&#34;https://github.com/kubernetes/kompose&#34;&gt;kompose&lt;/a&gt; to help use them more effectively on kubernetes&lt;/p&gt;
&lt;h3 id=&#34;testcontainers--sidecars--kubedock&#34;&gt;testcontainers =&amp;gt; sidecars / kubedock&lt;/h3&gt;
&lt;p&gt;Some folks use &lt;a href=&#34;https://www.testcontainers.org/&#34;&gt;testcontainers&lt;/a&gt; for running extra containers in docker to make it easier to do testing. e.g. to run a database service to run tests using the database.&lt;/p&gt;
&lt;p&gt;You could try &lt;a href=&#34;https://github.com/joyrex2001/kubedock&#34;&gt;kubedock&lt;/a&gt; with testcontainers to see if that solves your problem without requiring a local docker installation.&lt;/p&gt;
&lt;p&gt;It does depend a little on what your solution is for CI.&lt;/p&gt;
&lt;p&gt;If you are using &lt;a href=&#34;https://jenkins-x.io/v3&#34;&gt;Jenkins X&lt;/a&gt; or &lt;a href=&#34;https://github.com/tektoncd/pipeline&#34;&gt;tekton pipelines&lt;/a&gt; then you can &lt;a href=&#34;https://github.com/tektoncd/pipeline/blob/main/docs/taskruns.md#specifying-sidecars&#34;&gt;define sidecars&lt;/a&gt; in your pipeline to make sure you have whatever additional services you need when running your tests.&lt;/p&gt;
&lt;p&gt;If you are using &lt;a href=&#34;https://www.jenkins.io/&#34;&gt;Jenkins&lt;/a&gt; then you can add the side cars to the &lt;code&gt;pod.yaml&lt;/code&gt; you use with the &lt;a href=&#34;https://plugins.jenkins.io/kubernetes/&#34;&gt;kubernetes plugin&lt;/a&gt; or you could reuse the &lt;a href=&#34;https://www.jenkins.io/blog/2021/04/21/tekton-plugin/&#34;&gt;tekton client plugin&lt;/a&gt; and use tekton pipelines and sidecars&lt;/p&gt;
&lt;p&gt;If you are &lt;a href=&#34;https://github.com/features/actions&#34;&gt;GitHub Actions&lt;/a&gt; then you can spin up a kubernetes cluster using &lt;a href=&#34;https://kind.sigs.k8s.io/&#34;&gt;kind&lt;/a&gt; via this &lt;a href=&#34;https://github.com/marketplace/actions/kind-kubernetes-in-docker-action&#34;&gt;kind github action&lt;/a&gt; - you can then spin up whatever services you need for your tests via &lt;a href=&#34;https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#apply&#34;&gt;kubectl apply&lt;/a&gt; or &lt;code&gt;helm install&lt;/code&gt;&lt;/p&gt;
&lt;h3 id=&#34;help-we-are-not-even-using-kubernetes-yet&#34;&gt;help! we are not even using kubernetes yet&lt;/h3&gt;
&lt;p&gt;If you have not even started on your journey to kubernetes and have no idea what a &lt;a href=&#34;https://helm.sh/&#34;&gt;helm chart&lt;/a&gt; is, you could consider &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;setting up Jenkins X&lt;/a&gt; in your cluster which will then:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/&#34;&gt;automate setting up the CI / CD&lt;/a&gt; for your projects including automatically creating versioned container images and helm charts whenever you merge changes to the main branch&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/promotion/&#34;&gt;automatic promotion through environments via GitOps&lt;/a&gt; so that new versions of your services are automatically promoted to your &lt;code&gt;Staging&lt;/code&gt; environment and, by default, when approved are promoted to &lt;code&gt;Production&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/preview/&#34;&gt;Preview Environments&lt;/a&gt; automatically spin up Preview Environments for your Pull Requests so you can get fast feedback before changes are merged to the main branch&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Once someone on your team has &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;setup up Jenkins X&lt;/a&gt; then please follow the &lt;a href=&#34;https://jenkins-x.io/v3/develop/developing/&#34;&gt;development guide&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&#34;other-handy-kubectl-commands&#34;&gt;other handy kubectl commands&lt;/h3&gt;
&lt;p&gt;You may find these handy:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&#34;https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs&#34;&gt;kubectl logs&lt;/a&gt; to view the logs of any running pod (which is kubernetes terminology for 1 or more containers deployed together as a single unit on the same node)&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;
&lt;p&gt;&lt;a href=&#34;https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#port-forward&#34;&gt;kubectl port-forward&lt;/a&gt; lets you easily port forward from a pod to a local port so you can easily test things out without having to expose things via ingress&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;inner-loop&#34;&gt;inner loop&lt;/h3&gt;
&lt;p&gt;If you want to optimise your inner loop so you can edit source code and see the changes running quickly on kubernetes then please check out the options for &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/inner-loop/&#34;&gt;inner development loop&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;conclusion&#34;&gt;Conclusion&lt;/h2&gt;
&lt;p&gt;Lots of developers have grown fond of their docker installation over the years. Docker was a total game changer in its day!&lt;/p&gt;
&lt;p&gt;However if you are building/testing/debugging software to deploy on kubernetes we highly recommend you consider reclaiming the memory, CPU &amp;amp; disk from your laptop and stop running docker locally and just use more kubernetes.&lt;/p&gt;
&lt;p&gt;It will help you go faster, find those kubernetes related issues sooner and help you learn more about kubernetes which will be useful for figuring out production issues whenever they happen.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3 - May 2021 LTS</title>
      <link>https://jenkins-x.io/blog/2021/05/12/jx3-lts-may-21/</link>
      <pubDate>Wed, 12 May 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/05/12/jx3-lts-may-21/</guid>
      <description>
        
        
        &lt;p&gt;May 2001 &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/lts/&#34;&gt;LTS release&lt;/a&gt; is now available!&lt;/p&gt;
&lt;p&gt;LTS is a slower cadence version stream which contains a verified set of releases and configurations that have been used by teams tracking the bleeding edge Jenkins X.&lt;/p&gt;
&lt;p&gt;Included in this release:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Protect Pipeline Visualiser with OAuth2 &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/ingress/oauth&#34;&gt;how to docs&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Terraform repositories are now protected by the Jenkins X version stream&lt;/li&gt;
&lt;li&gt;external-dns helm chart upgrade to &lt;a href=&#34;https://artifacthub.io/packages/helm/bitnami/external-dns/5.0.0&#34;&gt;v5.0.0&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Reduce external secrets polling of cloud services to reduce cloud costs&lt;/li&gt;
&lt;li&gt;[Jenkins] for users using Jenkins the &lt;a href=&#34;https://github.com/jenkinsci/tekton-client-plugin&#34;&gt;Tekton Client plugin&lt;/a&gt; is now installed by default&lt;/li&gt;
&lt;li&gt;Stackdriver format logging enabled when using GKE and services that use &lt;a href=&#34;https://github.com/jenkins-x/jx-logging&#34;&gt;jx-logging&lt;/a&gt; library.  If you enable the Stackdriver API in GCP you will get well formatted logs and alerts via Stackdriver.&lt;/li&gt;
&lt;li&gt;Jenkins X Grafana dashboards updates with Lighthouse telemetry&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3.x GA is here!</title>
      <link>https://jenkins-x.io/blog/2021/04/15/jx-v3-ga/</link>
      <pubDate>Thu, 15 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/04/15/jx-v3-ga/</guid>
      <description>
        
        
        &lt;p&gt;I&amp;rsquo;m super excited to announce the 3.0 GA (General Availability) release of Jenkins X!&lt;/p&gt;
&lt;img width=&#34;387px&#34; src=&#34;https://jenkins-x.io/images/jxxx.png&#34;&gt;
&lt;p&gt;Jenkins X automates your CI/CD on kubernetes to help you &lt;a href=&#34;https://jenkins-x.io/v3/devops/accelerate/&#34;&gt;accelerate&lt;/a&gt;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/&#34;&gt;Automated CI/CD pipelines&lt;/a&gt; lets you focus on your actually application code while Jenkins X automatically creates battle tested &lt;a href=&#34;https://github.com/tektoncd/pipeline&#34;&gt;Tekton&lt;/a&gt;  CI/CD pipelines for your project which are &lt;a href=&#34;https://jenkins-x.io/blog/2021/02/25/gitops-pipelines/&#34;&gt;managed via GitOps&lt;/a&gt; so that its super easy to keep your pipelines up to date across your repositories or to upgrade or &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/catalog/#overriding-a-pipeline-step-locally&#34;&gt;override pipelines or steps&lt;/a&gt; for specific repositories.&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/promotion&#34;&gt;Automatic promotion of versioned artifacts&lt;/a&gt; via &lt;a href=&#34;https://jenkins-x.io/v3/devops/patterns/gitops/&#34;&gt;GitOps&lt;/a&gt; through your &lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/&#34;&gt;Environments&lt;/a&gt; such as &lt;code&gt;Staging&lt;/code&gt;, &lt;code&gt;Pre-production&lt;/code&gt; and &lt;code&gt;Production&lt;/code&gt; whether they are running in the same kubernetes cluster or you are using &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/multi-cluster/&#34;&gt;multiple clusters for your environments&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/preview/&#34;&gt;Preview Environments&lt;/a&gt; lets you propose code changes via Pull Requests and have a Preview Environment automatically created, running your code in kubernetes to get fast feedback from your team before agreeing to merge changes to the main branch&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/develop/developing/#using-chatops&#34;&gt;ChatOps&lt;/a&gt; comment on Pull Requests to give feedback, approve/hold changes, trigger optional pipelines for additional testing and other &lt;a href=&#34;https://jenkins-x.io/v3/develop/reference/chatops/&#34;&gt;ChatOps commands&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;demo&#34;&gt;Demo&lt;/h2&gt;
&lt;p&gt;Here&amp;rsquo;s a &lt;a href=&#34;https://jenkins-x.io/v3/develop/developing/#demo&#34;&gt;demo&lt;/a&gt; of &lt;a href=&#34;https://jenkins-x.io/v3/develop/developing/&#34;&gt;how to develop code with Jenkins X&lt;/a&gt;&lt;/p&gt;
&lt;iframe width=&#34;560&#34; height=&#34;315&#34; src=&#34;https://www.youtube.com/embed/4wqwulEzseM?t=279s&#34; title=&#34;Demo of developing with Jenkins X&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h2 id=&#34;documentation&#34;&gt;Documentation&lt;/h2&gt;
&lt;p&gt;the main documentation of the changes are:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/about/overview/&#34;&gt;the new architecture&lt;/a&gt; with modular plugins and improved &lt;a href=&#34;https://jenkins-x.io/v3/about/extending/&#34;&gt;extension points&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/about/changes/&#34;&gt;what has changed since 3.x started&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/about/comparison/&#34;&gt;how 3.x compares to 2.x&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/devops/&#34;&gt;DevOps Guides&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/v3/devops/patterns/&#34;&gt;DevOps Patterns&lt;/a&gt; provides an overview of our learnings in the DevOps space&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;here&amp;rsquo;s a brief summary of the differences:&lt;/p&gt;
&lt;h3 id=&#34;changes-since-the-3x-beta&#34;&gt;Changes since the 3.x beta&lt;/h3&gt;
&lt;p&gt;The following &lt;a href=&#34;https://jenkins-x.io/v3/about/changes/&#34;&gt;improvements have been made since the first beta&lt;/a&gt;:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/blog/2021/04/01/jx3-builtin-observability/&#34;&gt;Integrated observability and monitoring&lt;/a&gt; with &lt;a href=&#34;https://jenkins-x.io/blog/2021/04/08/jx3-pipeline-trace/&#34;&gt;Pipeline Tracing&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/blog/2021/04/01/jx3-osiris-preview-envs/&#34;&gt;Auto scale preview environments with Osiris&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/cluster/#automatic-upgrades&#34;&gt;Enable auto upgrade&lt;/a&gt; to keep your cluster up to date&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;user-changes-since-2x&#34;&gt;User Changes since 2.x&lt;/h3&gt;
&lt;p&gt;As a user the high level UX of Jenkins X is similar:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#automated-pipelines&#34;&gt;automated Continuous Delivery pipelines&lt;/a&gt; for using &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/&#34;&gt;tekton&lt;/a&gt; for your repositories with &lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#promotion&#34;&gt;automatic promotion&lt;/a&gt; between your &lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#environments&#34;&gt;environments&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;pull requests on your repositories create separate &lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#preview-environments&#34;&gt;Preview Environments&lt;/a&gt; where your team can review your changes and give fast feedback before your changes are approved and merged into the main trunk.&lt;/li&gt;
&lt;/ul&gt;
&lt;img width=&#34;600&#34; src=&#34;https://jenkins-x.io/images/pr-comment.png&#34; class=&#34;img-thumbnail&#34;&gt;
&lt;h4 id=&#34;new-features&#34;&gt;New features&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;we now default to &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#source-changes&#34;&gt;vanilla tekton YAML for defining pipelines&lt;/a&gt; while &lt;a href=&#34;https://jenkins-x.io/blog/2020/11/11/accelerate-tekton/&#34;&gt;accelerating your tekton&lt;/a&gt; with &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#adding-tasks-from-the-tekton-catalog&#34;&gt;tekton catalog&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;we include an open source &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/dashboard/&#34;&gt;dashboard&lt;/a&gt; for visualising pipelines and logs which you can invoke via:&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx dash
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ul&gt;
&lt;li&gt;we have a full &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/octant/&#34;&gt;Kubernetes and Jenkins X console&lt;/a&gt; based on the excellent &lt;a href=&#34;https://octant.dev/&#34;&gt;octant&lt;/a&gt; which you can try out via:&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx ui
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/2LCPHi0BnUg&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h3 id=&#34;platform-changes&#34;&gt;Platform Changes&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;we now use &lt;a href=&#34;https://helm.sh/&#34;&gt;helm&lt;/a&gt; (3.x) and &lt;a href=&#34;https://github.com/roboll/helmfile&#34;&gt;helmfile&lt;/a&gt; along with optionally &lt;a href=&#34;https://kustomize.io/&#34;&gt;kustomize&lt;/a&gt; in a GitOps style to define and configure both Jenkins X itself, your tools and applications in any namespace&lt;/li&gt;
&lt;li&gt;support &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/multi-cluster/&#34;&gt;multi cluster&lt;/a&gt; out of the box so you can keep &lt;code&gt;Staging&lt;/code&gt; and &lt;code&gt;Production&lt;/code&gt; in separate clusters to your development cluster where your pipelines run, you create and release immutable container images and other artifacts.&lt;/li&gt;
&lt;li&gt;to &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;setup or upgrade&lt;/a&gt; Jenkins X we use &lt;a href=&#34;https://www.terraform.io/&#34;&gt;terraform&lt;/a&gt; to setup your cloud resources on &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/azure/&#34;&gt;Azure&lt;/a&gt;, &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/eks/&#34;&gt;Amazon&lt;/a&gt; or &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/google/&#34;&gt;Google&lt;/a&gt; while also supporting on-premises, minkube and OpenShift - see the &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;Admin Guides&lt;/a&gt; for more detail
&lt;ul&gt;
&lt;li&gt;the actual installation of kubernetes resources takes place using the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/operator/&#34;&gt;git operator&lt;/a&gt; so it runs reliably inside the cluster itself&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;we default to using &lt;a href=&#34;https://github.com/external-secrets/kubernetes-external-secrets&#34;&gt;Kubernetes External Secrets&lt;/a&gt; to manage all secrets for Jenkins X itself, development tools and your applications too.
&lt;ul&gt;
&lt;li&gt;This means we can support various secret backends such as Alibaba Cloud KMS Secret Manager, Amazon Secret Manager, Azure Key Vault, Hashicorp Vault or GCP Secret Manager&lt;/li&gt;
&lt;li&gt;It also means we can then check in all kubernetes resources and custom resources directly into git (apart from Kubernetes &lt;code&gt;Secrets&lt;/code&gt;) so that it super easy to version, review and reason about your kubernetes resources in a GitOps way.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;built in &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/tls_dns/&#34;&gt;TLS and DNS&lt;/a&gt; support along with &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/health/&#34;&gt;Heath&lt;/a&gt; reporting and visualising via &lt;a href=&#34;https://github.com/Comcast/kuberhealthy&#34;&gt;kuberhealthy&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;we now have an &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/lts/&#34;&gt;LTS distribution&lt;/a&gt; which lets you switch to a much more slower cadence of releases of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We have been using Jenkins X 3.x in production now for many months (for CI/CD of all of the &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/source/&#34;&gt;3.x codebase&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/&#34;&gt;continuously upgrading our cluster in the standard way&lt;/a&gt; and it&amp;rsquo;s been much simpler and easier to use, operate and configure.&lt;/p&gt;
&lt;p&gt;We have also been continuously delivering changes from Jenkins X into our production cluster for many months now and it&amp;rsquo;s been working great - &lt;a href=&#34;https://jenkins-x.io/v3/devops/patterns/gitops/&#34;&gt;GitOps&lt;/a&gt; FTW!&lt;/p&gt;
&lt;p&gt;In general Jenkins X 3.x is now much simpler and more flexible. It supports &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;lots more platforms than before&lt;/a&gt; and should be easy to extend and configure for other platforms too.&lt;/p&gt;
&lt;div class=&#34;row&#34;&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/eks/&#34; title=&#34;setup Jenkins X on Amazon cloud with EKS&#34;&gt;
            &lt;img alt=&#34;Amazon&#34; src=&#34;https://jenkins-x.io/images/logo/aws.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/azure/&#34; title=&#34;setup Jenkins X on Azure cloud with AKS&#34;&gt;
            &lt;img alt=&#34;Azure&#34; src=&#34;https://jenkins-x.io/images/logo/azure.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/gke/&#34; title=&#34;setup Jenkins X on Google Cloud with GKE&#34;&gt;
            &lt;img alt=&#34;Google&#34; src=&#34;https://jenkins-x.io/images/logo/gcp.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
&lt;/div&gt;

&lt;div class=&#34;row pt-4&#34;&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/on-premises/&#34; title=&#34;setup Jenkins X on any Kubernetes cluster without cloud resources&#34;&gt;
            &lt;img alt=&#34;On-Premises&#34; src=&#34;https://jenkins-x.io/images/logo/k8s.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/minikube/&#34; title=&#34;setup Jenkins X on your laptop&#34;&gt;
            &lt;img alt=&#34;Minkube&#34; src=&#34;https://jenkins-x.io/images/logo/minikube.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;h1 class=&#34;card-title&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/openshift/&#34; title=&#34;setup Jenkins X on OpenShift&#34;&gt;
            &lt;img width=&#34;397&#34; height=&#34;66&#34; alt=&#34;OpenShift&#34; src=&#34;https://jenkins-x.io/images/logo/openshift.png&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/h1&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
&lt;/div&gt;

&lt;div class=&#34;row pt-4&#34;&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/k3s/&#34; title=&#34;setup Jenkins X on k3s&#34;&gt;
            &lt;img alt=&#34;k3s&#34; src=&#34;https://jenkins-x.io/images/logo/k3s-horizontal-color.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
&lt;/div&gt;


&lt;h3 id=&#34;getting-started&#34;&gt;Getting started&lt;/h3&gt;
&lt;p&gt;If you have never tried &lt;a href=&#34;https://jenkins-x.io/v3/about/&#34;&gt;3.x&lt;/a&gt; before then please follow the &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;Admin Guide&lt;/a&gt; to get Jenkins X installed on your cloud provider, on-premises kubernetes cluster or minikube.&lt;/p&gt;
&lt;p&gt;If you previously tried the 3.x alpha then the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/migrate/v3-alpha/&#34;&gt;migration instructions are here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;For folks on older 2.x versions of Jenkins X please see &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/migrate/v2/&#34;&gt;the 2.x migration instructions&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Once your cluster has been installed or migrated then check out the &lt;a href=&#34;https://jenkins-x.io/v3/develop/&#34;&gt;User Guide&lt;/a&gt; on how to develop software continuously with Jenkins X.&lt;/p&gt;
&lt;h3 id=&#34;final-thoughts&#34;&gt;Final thoughts&lt;/h3&gt;
&lt;p&gt;A huge thanks goes out to all the &lt;a href=&#34;https://jenkins-x.io/community/#contributors&#34;&gt;contributors&lt;/a&gt;, folks in the &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;Jenkins X community&lt;/a&gt; and the &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/projects/&#34;&gt;community around all the open source projects we reuse&lt;/a&gt; who&amp;rsquo;ve helped get this beta together. The improvements in Jenkins X 3.x since 2.x are totally amazing, well done everyone!&lt;/p&gt;
&lt;p&gt;Please give Jenkins X a try and &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;let us know what you think&lt;/a&gt; or &lt;a href=&#34;https://github.com/jenkins-x/issues&#34;&gt;raise an issue&lt;/a&gt;. All feedback highly appreciated - particularly how we can keep improving to help you develop faster.&lt;/p&gt;
&lt;p&gt;If you are at all interested in Continuous Delivery with kubernetes using &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/projects/&#34;&gt;tools&lt;/a&gt; like &lt;a href=&#34;https://helm.sh/&#34;&gt;helm&lt;/a&gt;, &lt;a href=&#34;https://github.com/roboll/helmfile&#34;&gt;helmfile&lt;/a&gt;, &lt;a href=&#34;https://knative.dev/&#34;&gt;knative&lt;/a&gt;,  &lt;a href=&#34;https://github.com/jenkins-x/lighthouse&#34;&gt;lighthouse&lt;/a&gt; and last but definitely not least, &lt;a href=&#34;https://github.com/tektoncd/cli&#34;&gt;tekton&lt;/a&gt;  then please join the &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;community&lt;/a&gt; - its great fun!&lt;/p&gt;
&lt;p&gt;For any questions and feedback please reach out on slack &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;https://jenkins-x.io/community/#slack&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3 - April 2021 LTS</title>
      <link>https://jenkins-x.io/blog/2021/04/12/jx3-lts-apr-21/</link>
      <pubDate>Mon, 12 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/04/12/jx3-lts-apr-21/</guid>
      <description>
        
        
        &lt;p&gt;This is the second &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/lts/&#34;&gt;LTS release&lt;/a&gt; for Jenkins X 3.x.&lt;/p&gt;
&lt;p&gt;LTS is a slower cadence version stream which contains a verified set of releases and configurations that have been used by teams tracking the bleeding edge Jenkins X.&lt;/p&gt;
&lt;p&gt;Initially when we decided to maintain an LTS version stream we thought we&amp;rsquo;d aim for monthly releases however this second release comes two months after the first.  This has given us more chances to run fixes and chart upgrades on Jenkins X own infrastructure to verify stability.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Note&lt;/strong&gt; This LTS release is intended to be the final one before Jenkins X 3 is made Generally Available so stay tuned for the exciting news coming very soon!  We will of course continue to develop and release LTS post GA.&lt;/p&gt;
&lt;p&gt;Included in this release:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;General beta bug fixes and helm chart upgrades&lt;/li&gt;
&lt;li&gt;Enable &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/observability&#34;&gt;Observability&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;Enable &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/slack&#34;&gt;Slack&lt;/a&gt; notifications&lt;/li&gt;
&lt;li&gt;Support for GitLab, Gitea, BitBucket Server and GitHub Enterprise&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Please be aware of these changes&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/about/changes&#34;&gt;Breaking changes&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;If using Vault move it outside of being managed by Jenkins X GitOps &lt;a href=&#34;https://jenkins-x.io/v3/develop/faq/config/vault/#after-an-upgrade-the-boot-job-is-waiting-for-vault-in-jx-vault&#34;&gt;important notes&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Traces for your pipelines</title>
      <link>https://jenkins-x.io/blog/2021/04/08/jx3-pipeline-trace/</link>
      <pubDate>Thu, 08 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/04/08/jx3-pipeline-trace/</guid>
      <description>
        
        
        &lt;p&gt;Now that Jenkins X has solid integration with &lt;a href=&#34;https://grafana.com/&#34;&gt;Grafana&lt;/a&gt; for its &lt;a href=&#34;https://jenkins-x.io/blog/2021/04/01/jx3-builtin-observability/&#34;&gt;observability&lt;/a&gt;, it&amp;rsquo;s time to start building fun things!&lt;/p&gt;
&lt;p&gt;And the first one is &lt;strong&gt;tracing for all your pipelines&lt;/strong&gt;:&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/jx-pipelines-visualizer/pipeline-trace.gif&#34; alt=&#34;&#34;&gt;&lt;/p&gt;
&lt;p&gt;With it, you can easily see the timings of all your pipelines, stages, and steps. This is great to inspect a &amp;ldquo;slow&amp;rdquo; pipeline and quickly see the slower steps.&lt;/p&gt;
&lt;p&gt;We are using &lt;a href=&#34;https://opentelemetry.io/&#34;&gt;OpenTelemetry&lt;/a&gt; to generate a &amp;ldquo;logical&amp;rdquo; view of the pipeline, with 1 trace per pipeline and 1 span for each stage and step.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/v3/observability_pipeline_trace.png&#34; alt=&#34;&#34;&gt;&lt;/p&gt;
&lt;p&gt;By default, these traces are ingested by &lt;a href=&#34;https://github.com/grafana/tempo&#34;&gt;Grafana Tempo&lt;/a&gt;. But if you prefer to export them to a different destination, it&amp;rsquo;s very easy, and thanks to the &lt;a href=&#34;https://opentelemetry.io/docs/collector/&#34;&gt;OpenTelemetry Collector&lt;/a&gt; you can export to a lot of different services. You can see the full list &lt;a href=&#34;https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter&#34;&gt;here&lt;/a&gt; and &lt;a href=&#34;https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The trace identifier is also stored in the pipeline itself so that the &lt;a href=&#34;https://github.com/jenkins-x/jx-pipelines-visualizer&#34;&gt;Jenkins X Pipelines Visualizer UI&lt;/a&gt; can link directly to the trace.&lt;/p&gt;
&lt;h3 id=&#34;how-can-you-benefit-from-it-in-your-own-jenkins-x-cluster&#34;&gt;How can you benefit from it in your own Jenkins X cluster?&lt;/h3&gt;
&lt;p&gt;You just need to enable the observability stack, as explained in the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/observability/&#34;&gt;observability admin guide&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Then, trigger a pipeline, and once it&amp;rsquo;s finished, go to the web UI, and click on the &amp;ldquo;Trace&amp;rdquo; button on the top-right. That&amp;rsquo;s it!&lt;/p&gt;
&lt;h3 id=&#34;whats-next&#34;&gt;What&amp;rsquo;s next?&lt;/h3&gt;
&lt;p&gt;This is only the first step of native tracing support in Jenkins X. Stay tuned for more!&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X v3: now with built-in observability</title>
      <link>https://jenkins-x.io/blog/2021/04/01/jx3-builtin-observability/</link>
      <pubDate>Thu, 01 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/04/01/jx3-builtin-observability/</guid>
      <description>
        
        
        &lt;p&gt;As a Continuous Delivery platform, Jenkins X has a central part in your infrastructure. If it becomes unstable or unusable, it will impact the whole software delivery of your organization.&lt;/p&gt;
&lt;p&gt;This is why observability is a critical topic for Jenkins X, and work has started to get observability built-in for Jenkins X v3:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Platform Observability&lt;/strong&gt;: visualize logs and metrics for everything running in the Kubernetes cluster: Jenkins X&amp;rsquo;s own components - Tekton, Lighthouse, cert-manager, &amp;hellip; - but also your own applications, that will be deployed either in preview environments or in the staging/prod environments.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Continuous Delivery Indicators&lt;/strong&gt;: visualize pull requests, pipelines, releases, and deployments metrics, collected from cluster events and git events.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We&amp;rsquo;re using &lt;a href=&#34;https://grafana.com/&#34;&gt;Grafana&lt;/a&gt; as the central visualization component: the main entry point from which you can get a complete overview of both your application&amp;rsquo;s lifecycle - development, build, tests, releases, deployments, runtime - and your Continuous Delivery platform.&lt;/p&gt;
&lt;h2 id=&#34;platform-observability&#34;&gt;Platform Observability&lt;/h2&gt;
&lt;p&gt;Platform observability is not enabled by default for the moment, so the first step is to enable it, as explained in the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/observability/platform-observability/&#34;&gt;platform observability admin guide&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Once it&amp;rsquo;s done, you&amp;rsquo;ll get a running Grafana instance, pre-configured with data sources for applications logs - using &lt;a href=&#34;https://grafana.com/oss/loki/&#34;&gt;Loki&lt;/a&gt; - and applications metrics - using &lt;a href=&#34;https://prometheus.io/&#34;&gt;Prometheus&lt;/a&gt;. But most important, it comes with a set of pre-defined &lt;a href=&#34;https://github.com/jenkins-x-charts/grafana-dashboard&#34;&gt;Grafana dashboards&lt;/a&gt; for the main platform components: Tekton, Lighthouse, cert-manager, &amp;hellip;&lt;/p&gt;
&lt;p&gt;Here is an example of such a dashboard, using a mix of data sources to display &lt;a href=&#34;https://cert-manager.io/&#34;&gt;cert-manager&lt;/a&gt; metrics collected by Prometheus - including the certificates expiration dates - and logs collected by Loki/Promtail:&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/v3/observability_platform_cert-manager.png&#34; alt=&#34;cert-manager grafana dashboard for Jenkins X&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;continuous-delivery-indicators&#34;&gt;Continuous Delivery Indicators&lt;/h2&gt;
&lt;p&gt;Continuous Delivery Indicators&amp;rsquo; main goal is to give people insights into their workflows/processes so that they can continuously improve them. This is based on the &lt;a href=&#34;https://www.devops-research.com/research.html&#34;&gt;DORA devops metrics&lt;/a&gt; and the &lt;a href=&#34;https://queue.acm.org/detail.cfm?id=3454124k&#34;&gt;SPACE framework&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The &lt;a href=&#34;https://github.com/jenkins-x/cd-indicators&#34;&gt;CD Indicators&lt;/a&gt; addon is not enabled by default for the moment, so the first step is to enable it, as explained in the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/observability/cd-indicators/&#34;&gt;continuous delivery indicators admin guide&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Once it&amp;rsquo;s done, you&amp;rsquo;ll get a running collector, along with a PostgreSQL database. The collector will listen for various events, both from the cluster and the git repositories, and store pull requests, pipelines, releases, and deployments data in the PostgreSQL database. The addon will also expose a new Grafana data source along with pre-configured Grafana dashboards, which will be picked up by your running Grafana instance.&lt;/p&gt;
&lt;p&gt;Here is an example of such a dashboard, displaying various indicators for a single repository/application: contributors, reviews, pull requests, releases, deployments, &amp;hellip;&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/v3/observability_cd_indicators_repository.png&#34; alt=&#34;Continuous Delivery Indicators for a single repository&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;roadmap&#34;&gt;Roadmap&lt;/h2&gt;
&lt;p&gt;This is only the beginning! The next steps - in no particular order:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;configure alerting - using Prometheus alertmanager and Grafana alerting features - with a set of pre-defined alerts&lt;/li&gt;
&lt;li&gt;improve the dashboards&lt;/li&gt;
&lt;li&gt;enable it by default, so that users can benefit from it out of the box&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Contributions are welcomed:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx3-versions&#34;&gt;Grafana/loki/prometheus/&amp;hellip; configuration in the versionstream&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x-charts/grafana-dashboard&#34;&gt;Grafana dashboards&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/cd-indicators&#34;&gt;Continuous Delivery Indicators Collector &amp;amp; Grafana dashboards&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Scaling Preview Environments with Osiris</title>
      <link>https://jenkins-x.io/blog/2021/04/01/jx3-osiris-preview-envs/</link>
      <pubDate>Thu, 01 Apr 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/04/01/jx3-osiris-preview-envs/</guid>
      <description>
        
        
        &lt;p&gt;One of Jenkins X&amp;rsquo;s core features is the &lt;a href=&#34;https://jenkins-x.io/v3/develop/environments/preview/&#34;&gt;preview environments&lt;/a&gt;: temporary environments created automatically for each Pull Requests, to deploy your application and its dependencies. You can then use this preview environment to run integration tests, or manually use/test your application.&lt;/p&gt;
&lt;p&gt;This is all great until you have more and more applications, each with a few dependencies (postgresql, mongodb, &amp;hellip;) and a few opened pull requests at any time. This means that you&amp;rsquo;ll get more and more pods running in your Kubernetes cluster, in addition to Jenkins X&amp;rsquo;s own components, your build pipelines, and of course your staging and production applications - unless you are using &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/multi-cluster/&#34;&gt;multi-cluster&lt;/a&gt;. The result is that you&amp;rsquo;ll need more nodes or bigger nodes. Which means more money.&lt;/p&gt;
&lt;p&gt;But, these preview environments are in fact idle most of the time: they are only used for the integration tests, and sometimes when someone manually uses them. The rest of the time - including all night for example - they are just staying there, idle, and consuming resources. What if we could easily scale them down when they are idle, and automatically bring them up when we need them? So that a Pull Request staying opened for 2 weeks because someone went on vacation won&amp;rsquo;t consume resources in your cluster.&lt;/p&gt;
&lt;h3 id=&#34;osiris&#34;&gt;Osiris&lt;/h3&gt;
&lt;p&gt;Enter &lt;a href=&#34;https://github.com/dailymotion-oss/osiris&#34;&gt;Osiris&lt;/a&gt;! Initially created by the &lt;a href=&#34;https://github.com/deislabs&#34;&gt;Deislabs team&lt;/a&gt;, Osiris is a Kubernetes component that will automatically scale down your &amp;ldquo;idle&amp;rdquo; pods, and scale them up when a request comes in. Although the &lt;a href=&#34;https://github.com/deislabs/osiris&#34;&gt;original project&lt;/a&gt; has been archived, the &lt;a href=&#34;https://github.com/dailymotion-oss&#34;&gt;Dailymotion team&lt;/a&gt; has taken over the maintenance of &lt;a href=&#34;https://github.com/dailymotion-oss/osiris&#34;&gt;a fork&lt;/a&gt;. And they have been using it with success in their Jenkins X dev cluster for more than 2 years: they regularly have around 50 preview environments active at any time, and&amp;hellip; 0 pods from these environments running at night - or on weekends. Coupled with a cluster autoscaler, it means that their Kubernetes cluster use between 3 and more than 20 nodes depending on the workload. Being able to scale down to a minimum number of nodes is a great benefit when using cloud resources.&lt;/p&gt;
&lt;h3 id=&#34;how-can-you-benefit-from-it-in-your-own-jenkins-x-cluster&#34;&gt;How can you benefit from it in your own Jenkins X cluster?&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;first, you&amp;rsquo;ll need to follow the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/preview-environments/&#34;&gt;admin guide to enable Osiris in your dev cluster&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;and then, you&amp;rsquo;ll need to add annotations to your Deployment/Statefulset and Service manifests - as explained in the &lt;a href=&#34;https://github.com/dailymotion-oss/osiris&#34;&gt;Osiris documentation&lt;/a&gt; - in your application&amp;rsquo;s Helm chart&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Note that if you store data, you&amp;rsquo;ll need to use persistent volumes (for postgresql, mongodb, &amp;hellip;) so that you won&amp;rsquo;t lose your data after a scale down/up of your pods.&lt;/p&gt;
&lt;h3 id=&#34;how-does-it-work&#34;&gt;How does it work?&lt;/h3&gt;
&lt;p&gt;Osiris will automatically inject itself as a proxy in front of all the pods with the right annotation, so that it can see all requests for your pods. If it doesn&amp;rsquo;t see any request for a configurable amount of time - 10 minutes by default - it will scale down the deployment (or statefulset), and place itself behind the associated service. So that if a new request comes in, Osiris will be able to scale up the deployment (or statefulset), and then forward the request to the new pod.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: cdCon 2021 - Call for Jenkins X Proposals</title>
      <link>https://jenkins-x.io/blog/2021/02/25/cdcon-cfp/</link>
      <pubDate>Thu, 25 Feb 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/02/25/cdcon-cfp/</guid>
      <description>
        
        
        &lt;p&gt;Hear ye! Hear ye! Jenkins X Community,&lt;/p&gt;
&lt;p&gt;cdCon 2021 (the Continuous Delivery Foundation’s annual flagship event) is happening June 23-24 and its call for papers is open!&lt;/p&gt;
&lt;p&gt;This is your chance to share what you’ve been doing with Jenkins X. Are you building something cool? Using it to solve real-world problems? Are you making things fast? Secure? Or maybe you’re a contributor and want to share what’s new. In all cases, we want to hear from you!&lt;/p&gt;
&lt;p&gt;Submit your talk for &lt;a href=&#34;https://events.linuxfoundation.org/cdcon/&#34;&gt;cdCon 2021&lt;/a&gt; to be part of the conversation driving the future of software delivery for technology teams, enterprise leadership, and open-source communities.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Submission Deadline&lt;/strong&gt;: Friday, March 5 at 11:59 PM PST&lt;/p&gt;
&lt;h2 id=&#34;topics&#34;&gt;Topics&lt;/h2&gt;
&lt;p&gt;Here are the suggested tracks:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Continuous Delivery Ecosystem&lt;/strong&gt; – This track spans the entire Continuous Delivery ecosystem, from workflow orchestration, configuration management, testing, security, release automation, deployment strategies, developer experience, and more.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Advanced Delivery Techniques&lt;/strong&gt; – For talks on the very cutting edge of continuous delivery and emerging technology, for example, progressive delivery, observability, and MLOps.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;GitOps &amp;amp; Cloud-Native CD&lt;/strong&gt; – Submit to this track for talks related to continuous delivery involving containers, Kubernetes, and cloud*native technologies. This includes GitOps, cloud-native CD pipelines, chatops, best practices, etc.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Continuous Delivery in Action&lt;/strong&gt; – This track is for showcasing real-world continuous delivery addressing challenges in specific domains e.g. fintech, embedded, healthcare, retail, etc. Talks may cover topics such as governance, compliance, security, etc.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Leadership Track&lt;/strong&gt; – Talks for leaders and decision-makers on topics such as measuring DevOps, build vs buy, scaling, culture, security, FinOps, and developer productivity.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Community Track&lt;/strong&gt; – There is more to open source than code contributions. This track covers topics such as growing open source project communities, diversity &amp;amp; inclusion, measuring community health, project roadmaps, and any other topic around sustaining open source and open source communities.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Singular project focus and/or interoperability between:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Jenkins&lt;/li&gt;
&lt;li&gt;Jenkins X&lt;/li&gt;
&lt;li&gt;Ortelius&lt;/li&gt;
&lt;li&gt;Spinnaker&lt;/li&gt;
&lt;li&gt;Screwdriver&lt;/li&gt;
&lt;li&gt;Tekton&lt;/li&gt;
&lt;li&gt;Other – e.g. Keptn, Flagger, Argo, Flux&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;View all tracks and read &lt;a href=&#34;https://events.linuxfoundation.org/cdcon/program/cfp/&#34;&gt;CFP details here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;We look forward to reading your proposal!&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://events.linuxfoundation.org/cdcon/program/cfp/&#34;&gt;Submit your talk&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/cdcon-cfp-jx.png&#34; alt=&#34;cfp image&#34;&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: GitOps your cloud native pipelines</title>
      <link>https://jenkins-x.io/blog/2021/02/25/gitops-pipelines/</link>
      <pubDate>Thu, 25 Feb 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/02/25/gitops-pipelines/</guid>
      <description>
        
        
        &lt;p&gt;&lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton pipelines&lt;/a&gt; are cloud native and are designed from the ground up for kubernetes and the cloud:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;there&amp;rsquo;s no single point of failure and the pipelines are elastically scalable&lt;/li&gt;
&lt;li&gt;each pipeline is completely declarative and self defined&lt;/li&gt;
&lt;li&gt;each pipeline executes independently of any others&lt;/li&gt;
&lt;li&gt;pipelines are orchestrated via the sophisticated kubernetes scheduler:
&lt;ul&gt;
&lt;li&gt;can use pipeline specific metadata for resource limits and node selectors: memory, CPU, machine type (GPU, windows/macOS/linux etc)&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;its easy to associate pipelines with &lt;a href=&#34;https://jenkins-x.io/v3/devops/cloud-native/#map-iam-roles-to-kubernetes-service-accounts&#34;&gt;Cloud IAM roles&lt;/a&gt; to avoid you having to upload cluster admin secrets to your public CI service which really helps security and helps reduce accidental bitcoin mining on your cloud account&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;In a previous blog we talked about how you can &lt;a href=&#34;https://jenkins-x.io/blog/2020/11/11/accelerate-tekton/&#34;&gt;accelerate your use of tekton with Jenkins X&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&#34;the-problem&#34;&gt;The problem&lt;/h2&gt;
&lt;p&gt;We are moving towards a microservice kind of world with many teams writing many bits of software in many repositories. So there are lots and lots of pipelines. These pipelines keep getting more sophisticated over time; doing much more (all kinds of building, analysis, reporting, testing, ChatOps etc) and the software/images/approaches they use change.&lt;/p&gt;
&lt;p&gt;So how can we manage, configure and maintain them all so that there are many pipelines for many repositories; where each repository can customise anything it needs but we can easily maintain everything continuously and its easy to understand and tool around?&lt;/p&gt;
&lt;h3 id=&#34;previous-solutions&#34;&gt;Previous solutions&lt;/h3&gt;
&lt;p&gt;We&amp;rsquo;ve tried to tackle this problem in a number of ways over the years; each has pros and cons.&lt;/p&gt;
&lt;p&gt;One option is to put all your pipelines in a shared library. You can then reference the pipelines by name in each of your repositories.&lt;/p&gt;
&lt;p&gt;But what if you want to change a bit of a pipeline for a specific repository? If you change it globally for everyone you can break things. You may just want local customisation for your repository only.&lt;/p&gt;
&lt;p&gt;You can add parameters into your pipelines. They are &lt;a href=&#34;https://github.com/tektoncd/pipeline/issues/1484&#34;&gt;quite verbose on Pipelines and PipelineRuns&lt;/a&gt;; but it&amp;rsquo;s hard to think up front of every parameterisation that may be required by downstream repositories. e.g. changing any image; changing any command line argument in any step, adding/changing any environment variables or volumes? How about adding extra steps before/after a particular step? It can soon get very complex and results in very complex pipelines that are hard to understand and use.&lt;/p&gt;
&lt;p&gt;Another option is if you need to change a pipeline file you just copy the entire file or create a fork. But then you end up with 100s of copies or forks of pipelines that are hard to synchronise and manage. You end using ancient image versions or older approaches in some repositories which leads to maintenance nightmare. How do you roll out security updates to images in all those repositories, copies and forks?&lt;/p&gt;
&lt;p&gt;Another approach we tried is using a tool like &lt;a href=&#34;https://googlecontainertools.github.io/kpt/&#34;&gt;kpt&lt;/a&gt; to share YAML files across git repositories and then upgrade them via git. This does work quite well; though the downside is whenever you upgrade a new version (e.g. we roll out a new pipeline catalog or a new image change to a tool for security reasons) you need to generate a pull request on every git repository to upgrade them and usually you end up with merge conflicts as the tekton YAML is not trivial; even fairly minor local customisations lead to merge conflict hell.&lt;/p&gt;
&lt;p&gt;So how can you apply the benefits of &lt;a href=&#34;https://jenkins-x.io/v3/devops/gitops/&#34;&gt;GitOps&lt;/a&gt; to your cloud native pipelines while also avoiding copy-paste of lots of YAML into all of your repositories, keeping things easy to understand and flexible so any repository can customize things when required but at the same time make it painless to move reliably forward as the pipeline catalogs and images change?&lt;/p&gt;
&lt;h2 id=&#34;gitops-your-pipelines&#34;&gt;GitOps your pipelines&lt;/h2&gt;
&lt;p&gt;Now our recommendation on the &lt;a href=&#34;https://jenkins-x.io/&#34;&gt;Jenkins X&lt;/a&gt; project is to use &lt;a href=&#34;https://jenkins-x.io/v3/devops/gitops/&#34;&gt;GitOps&lt;/a&gt; for your pipelines as well as for your source code and deployment configuration:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;store your pipelines as declarative YAML files inside each of your git repositories.&lt;/li&gt;
&lt;li&gt;use the standard &lt;a href=&#34;https://jenkins-x.io/v3/develop/reference/pipelines/&#34;&gt;Tekton YAML syntax&lt;/a&gt; so that you get &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/editing/#ide-support&#34;&gt;IDE support&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/editing/#linting&#34;&gt;easy linting&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;This lets each git repository configure what pipelines are triggered by what events with what pipeline steps.&lt;/p&gt;
&lt;p&gt;If you need to &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/editing/&#34;&gt;edit your pipelines in any repository&lt;/a&gt; they are right there in git; it is then easy for each repository to use its own version and configuration if required. This lets pipelines and repositories change over time independently to help you accelerate.&lt;/p&gt;
&lt;h2 id=&#34;sharing-tasks-and-steps-across-repositories&#34;&gt;Sharing Tasks and Steps across repositories&lt;/h2&gt;
&lt;p&gt;Rather than copy pasting &lt;a href=&#34;https://tekton.dev/docs/pipelines/tasks/#configuring-a-task&#34;&gt;task and step YAML&lt;/a&gt; between repositories we can refer to a &lt;code&gt;Task&lt;/code&gt; or a &lt;code&gt;Step&lt;/code&gt; in a Task as follows:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;refer to all the steps in a shared task by using&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;taskSpec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;steps&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  - &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:sourceURI&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ul&gt;
&lt;li&gt;refer to a single &lt;em&gt;named&lt;/em&gt; step from a shared task&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;taskSpec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;stepTemplate&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:sourceURI&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;steps&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;mystep&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h3 id=&#34;sourceuri-notation&#34;&gt;SourceURI notation&lt;/h3&gt;
&lt;p&gt;The source URI notation is enabled by a special &lt;code&gt;image&lt;/code&gt; prefix of &lt;strong&gt;uses:&lt;/strong&gt; on step or if an image on a step is blank and the &lt;code&gt;stepTemplate:&lt;/code&gt; has an &lt;code&gt;image&lt;/code&gt; prefix of &lt;strong&gt;uses:&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;We borrowed this idea from &lt;a href=&#34;https://github.com/google/ko&#34;&gt;ko&lt;/a&gt; and &lt;a href=&#34;https://github.com/mattmoor/mink&#34;&gt;mink&lt;/a&gt;; the idea of using a custom prefix on image URIs.&lt;/p&gt;
&lt;p&gt;You can refer to the &lt;a href=&#34;https://github.com/jenkins-x/lighthouse/blob/master/docs/pipelines.md&#34;&gt;detailed documentation&lt;/a&gt; on how the step inheritence and overriding works.&lt;/p&gt;
&lt;p&gt;For a &lt;a href=&#34;https://github.com&#34;&gt;github.com&lt;/a&gt; source URI we use the syntax:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:owner/repository/pathToFile@version&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;This references the &lt;a href=&#34;https://github.com&#34;&gt;https://github.com&lt;/a&gt; repository for &lt;code&gt;owner/repository&lt;/code&gt; and &lt;strong&gt;@version&lt;/strong&gt; can be a git tag, branch or SHA.&lt;/p&gt;
&lt;p&gt;If you are not using &lt;a href=&#34;https://github.com&#34;&gt;github.com&lt;/a&gt; to host your git repositories you can access a pipeline task or step from your custom git serve use the &lt;strong&gt;uses:lighthouse:&lt;/strong&gt; prefix before &lt;code&gt;owner&lt;/code&gt;:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;- &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:lighthouse:owner/repository/pathToFile@version&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;We &lt;a href=&#34;https://jenkins-x.io/v3/devops/gitops/#recommendations&#34;&gt;recommend you version everything with GitOps&lt;/a&gt; so you know exactly what versions are being used from git.&lt;/p&gt;
&lt;p&gt;However you can use &lt;strong&gt;@HEAD&lt;/strong&gt; to reference the latest version.&lt;/p&gt;
&lt;p&gt;To use a locked down version based on the &lt;em&gt;version stream&lt;/em&gt; of your cluster, you can use &lt;strong&gt;@versionStream&lt;/strong&gt; which means use the git SHA for the repository which is configured in the version stream.&lt;/p&gt;
&lt;p&gt;The nice thing about &lt;strong&gt;@versionStream&lt;/strong&gt; is that the pipeline catalog you inherit tasks and steps from is locked down to an exact SHA in the version stream; but it avoids you having to go through every one of your git repositories whenever you upgrade a pipeline catalog.&lt;/p&gt;
&lt;h2 id=&#34;reusing-tasks-and-steps-from-tekton-catalog&#34;&gt;Reusing Tasks and Steps from Tekton Catalog&lt;/h2&gt;
&lt;p&gt;The &lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog&lt;/a&gt; git repository defines a ton of Tekton pipelines you can reuse in your pipelines&lt;/p&gt;
&lt;p&gt;You can &lt;code&gt;image: uses:sourceURI&lt;/code&gt; notation inside any pipeline file in your &lt;code&gt;.lighthouse/jenkins-x/mypipeline.yaml&lt;/code&gt; file like this:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;steps&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  - &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:tektoncd/catalog/task/git-clone/0.2/git-clone.yaml@HEAD&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;This will then include the steps from the &lt;a href=&#34;https://github.com/tektoncd/catalog/blob/master/task/git-clone/0.2/git-clone.yaml&#34;&gt;git-clone.yaml&lt;/a&gt; file&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s not just the &lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog&lt;/a&gt;  - you can use this same approach to reuse Tasks or steps from any git repository of your choosing; such as the &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/tree/master/tasks&#34;&gt;Jenkins X Pipeline catalog&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;how-it-looks&#34;&gt;How it looks&lt;/h2&gt;
&lt;p&gt;So here is an &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/blob/master/packs/javascript/.lighthouse/jenkins-x/release.yaml&#34;&gt;example release pipeline&lt;/a&gt; generated via the &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/tree/master/tasks&#34;&gt;Jenkins X Pipeline catalog&lt;/a&gt; if you create a &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/catalog&#34;&gt;JavaScript quickstart&lt;/a&gt;&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;apiVersion&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;tekton.dev/v1beta1&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;kind&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;PipelineRun&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;metadata&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;release&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;spec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;pipelineSpec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;tasks&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;from-build-pack&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      &lt;span style=&#34;color:#f92672&#34;&gt;taskSpec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;stepTemplate&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;env&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;NPM_CONFIG_USERCONFIG&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;            &lt;span style=&#34;color:#f92672&#34;&gt;value&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;/tekton/home/npm/.npmrc&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:jenkins-x/jx3-pipeline-catalog/tasks/javascript/release.yaml@versionStream&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;resources&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;            &lt;span style=&#34;color:#f92672&#34;&gt;requests&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;              &lt;span style=&#34;color:#f92672&#34;&gt;cpu&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;400m&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;              &lt;span style=&#34;color:#f92672&#34;&gt;memory&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;512Mi&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;volumeMounts&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          - &lt;span style=&#34;color:#f92672&#34;&gt;mountPath&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;/tekton/home/npm&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;            &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;npmrc&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;workingDir&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;/workspace/source&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;steps&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:jenkins-x/jx3-pipeline-catalog/tasks/git-clone/git-clone.yaml@versionStream&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;next-version&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;jx-variables&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;build-npm-install&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;build-npm-test&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;check-registry&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;build-container-build&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;promote-changelog&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;promote-helm-release&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;promote-jx-promote&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;volumes&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;npmrc&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;secret&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;            &lt;span style=&#34;color:#f92672&#34;&gt;optional&lt;/span&gt;: &lt;span style=&#34;color:#66d9ef&#34;&gt;true&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;            &lt;span style=&#34;color:#f92672&#34;&gt;secretName&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;npmrc&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;serviceAccountName&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;tekton-bot&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;timeout&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;240h0m0s&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;You can see it mounts an npm secret for using npm package management and specifies CPU and memory requirements. It then is using the &lt;strong&gt;uses:&lt;/strong&gt; notation to inherit a bunch of steps from the &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/blob/master/tasks/javascript/release.yaml&#34;&gt;jenkins-x/jx3-pipeline-catalog/tasks/javascript/release.yaml&lt;/a&gt; as well as sharing the &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/blob/master/tasks/git-clone/git-clone.yaml&#34;&gt;jenkins-x/jx3-pipeline-catalog/tasks/git-clone/git-clone.yaml&lt;/a&gt; task&lt;/p&gt;
&lt;p&gt;Also notice we don&amp;rsquo;t have to copy and paste the exact details of the images, commands, arguments, environment variables and volume mounts required for each step; we can just reference them via Git. Also each pipeline in each repository can reference different versions if required.&lt;/p&gt;
&lt;h3 id=&#34;customizing-an-inherited-step&#34;&gt;Customizing an inherited step&lt;/h3&gt;
&lt;p&gt;You can edit the step in your &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/#ide-support&#34;&gt;IDE&lt;/a&gt; and add any custom properties such as &lt;code&gt;command&lt;/code&gt;, &lt;code&gt;args&lt;/code&gt;, &lt;code&gt;env&lt;/code&gt;, &lt;code&gt;script&lt;/code&gt; or &lt;code&gt;volumeMount&lt;/code&gt; - those values then override the inherited step.&lt;/p&gt;
&lt;p&gt;e.g. you can then change any command line, add an environment variable or add a new volume mount without copy pasting the whole step. e.g. we change the &lt;code&gt;script&lt;/code&gt; value of the &lt;code&gt;jx-variables&lt;/code&gt; step below:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;apiVersion&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;tekton.dev/v1beta1&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;kind&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;PipelineRun&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;spec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;pipelineSpec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;tasks&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    - &lt;span style=&#34;color:#f92672&#34;&gt;taskSpec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;stepTemplate&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;uses:jenkins-x/jx3-pipeline-catalog/tasks/javascript/release.yaml@versionStream&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;steps&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        - &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;jx-variables&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;script&lt;/span&gt;: |&lt;span style=&#34;color:#e6db74&#34;&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;            #!/usr/bin/env sh
&lt;/span&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;            echo my replacement command script goes here&lt;/span&gt;            
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Any extra properties in the steps are used to override the underlying uses step.&lt;/p&gt;
&lt;h3 id=&#34;inlining-a-pipeline-step-locally&#34;&gt;Inlining a pipeline step locally&lt;/h3&gt;
&lt;p&gt;If you want to edit a step that is inherited from a pipeline catalog just run the &lt;a href=&#34;https://github.com/jenkins-x/jx-pipeline/blob/master/docs/cmd/jx-pipeline_override.md#jx-pipeline-override&#34;&gt;jx pipeline override&lt;/a&gt; command from a clone of your repository.&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx pipeline override
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;This will then prompt you to pick which pipeline and step that&amp;rsquo;s inherited via the &lt;code&gt;image: uses:sourceURI&lt;/code&gt; notation. When chosen the step will be inlined into your local file so you can &lt;a href=&#34;#customizing-an-inherited-step&#34;&gt;edit any of the properties&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;You can use the git compare to see the changes and remove any properties you don&amp;rsquo;t wish to override.&lt;/p&gt;
&lt;h3 id=&#34;viewing-the-effective-pipeline&#34;&gt;Viewing the effective pipeline&lt;/h3&gt;
&lt;p&gt;To see the actual Tekton pipeline that would be executed from your local source directory you can run the &lt;a href=&#34;https://github.com/jenkins-x/jx-pipeline/blob/master/docs/cmd/jx-pipeline_effective.md#jx-pipeline-effective&#34;&gt;jx pipeline effective&lt;/a&gt; command:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx pipeline effective
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;If you want to open the effective pipeline in your editor, such as &lt;a href=&#34;https://code.visualstudio.com/&#34;&gt;VS Code&lt;/a&gt; you can do:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx pipeline effective -e code
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;If you use &lt;a href=&#34;https://www.jetbrains.com/idea/&#34;&gt;Intellij&lt;/a&gt; or any of &lt;a href=&#34;https://www.jetbrains.com/products/#type=ide&#34;&gt;JetBrains other IDEs&lt;/a&gt; you can do the following if you have &lt;a href=&#34;https://www.youtube.com/watch?v=SVANj3gAWt8&#34;&gt;enabled&lt;/a&gt; the &lt;code&gt;idea&lt;/code&gt; &lt;a href=&#34;https://www.youtube.com/watch?v=SVANj3gAWt8&#34;&gt;command line tool&lt;/a&gt;:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx pipeline effective -e idea
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;If you want to always view an effective pipeline in your editor then define the &lt;code&gt;JX_EDITOR&lt;/code&gt; environment variable&amp;hellip;&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;export JX_EDITOR&lt;span style=&#34;color:#f92672&#34;&gt;=&lt;/span&gt;&lt;span style=&#34;color:#e6db74&#34;&gt;&amp;#34;code&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#75715e&#34;&gt;# now we will always open effective pipelines inside VS Code&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx pipeline effective
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h2 id=&#34;summary&#34;&gt;Summary&lt;/h2&gt;
&lt;p&gt;We&amp;rsquo;ve been on our own digital transformation journey in the world of pipelines and used many different approaches over the years to manage many pipelines across many repositories.&lt;/p&gt;
&lt;p&gt;A few months ago we moved to the above GitOps approach for our cloud native pipelines and we are absolutely loving it!&lt;/p&gt;
&lt;p&gt;Its super easy to:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;share pipelines across all of your git repositories without copy/paste&lt;/li&gt;
&lt;li&gt;easily customise pipelines in any project and be able to easily understand what the local changes are and roll them back if required&lt;/li&gt;
&lt;li&gt;upgrade pipelines across your repositories in a consistent way as you &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/cluster/&#34;&gt;upgrade your images, applications and cluster via GitOps&lt;/a&gt; so that new versions of pipeline catalogs are upgraded once they pass the system tests.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;If you are thinking about using cloud native pipelines with &lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton&lt;/a&gt; please try it out and see what you think. We&amp;rsquo;d love to hear your &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;feedback&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3 - February 2021 LTS</title>
      <link>https://jenkins-x.io/blog/2021/02/01/jx3-lts-feb-21/</link>
      <pubDate>Mon, 01 Feb 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/02/01/jx3-lts-feb-21/</guid>
      <description>
        
        
        &lt;p&gt;This is the first &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/lts/&#34;&gt;LTS release&lt;/a&gt; for Jenkins X 3.x.  We are  still in the Beta release and the leadup to GA includes ensuring the process for LTS monthly releases is validated and working well.
This first releases focuses on:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;community feedback following the Beta release&lt;/li&gt;
&lt;li&gt;general helm chart upgrades&lt;/li&gt;
&lt;li&gt;improved developer UX when editing Tekton pipelines &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipelines/editing&#34;&gt;here&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;support for in-repo and shared Tekton pipeline libraries including git URI support,
e.g.&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;uses:jenkins-x/jx3-pipeline-catalog/packs/javascript/.lighthouse/jenkins-x/pullrequest.yaml@v1.2.3&lt;span style=&#34;color:#e6db74&#34;&gt;`&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;more documentation and examples can be found &lt;a href=&#34;https://github.com/jenkins-x/lighthouse/blob/master/docs/pipelines.md#configuring-pipelines&#34;&gt;here&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;whats-the-difference&#34;&gt;What&amp;rsquo;s the difference?&lt;/h2&gt;
&lt;p&gt;Because Jenkins X uses GitOps we can see the git diff of changes that will be brought in with a cluster upgrade.   Here is the Pull Request that has been verified for February LTS release.
&lt;a href=&#34;https://github.com/jenkins-x/jx3-lts-versions/pull/209/files&#34;&gt;https://github.com/jenkins-x/jx3-lts-versions/pull/209/files&lt;/a&gt;&lt;/p&gt;
&lt;h2 id=&#34;anything-else-to-be-aware-of&#34;&gt;Anything else to be aware of?&lt;/h2&gt;
&lt;p&gt;Included in the release is a switch of the NGINX Helm chart from the old Helm stable registry.  It was discussed on the community slack that some users on EKS and not using a custom domain had to change the domain in their cluster jx-requirements.yml file.&lt;/p&gt;
&lt;p&gt;The change of Chart repository meant the old resources were removed and new ones added, resulting in a new Kubernetes LoadBalancer service was created, resulting in a new external IP address.  You may need to update the domain in your &lt;code&gt;jx-requirements.yml&lt;/code&gt;.  To get the external IP run:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get service -n nginx
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Note the external ip address and update your cluster git repository, &lt;code&gt;jx-requirements.yml&lt;/code&gt;:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;domain: $EXTERNAL_IP_FROM_ABOVE.nip.io
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;git commit
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;git push
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx admin logs
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;And you should see the new ingress rules created when the boot job finishes:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;kubectl get ing -n jx
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;h1 id=&#34;whats-next&#34;&gt;What&amp;rsquo;s next?&lt;/h1&gt;
&lt;p&gt;March LTS release aims to switch the incluster boot jobs to use &lt;a href=&#34;https://carvel.dev/kapp/&#34;&gt;https://carvel.dev/kapp/&lt;/a&gt; rather than using &lt;code&gt;kubectl&lt;/code&gt; to apply and prune Kubernetes resources.  &lt;code&gt;kapp&lt;/code&gt; is a dependency aware approach to installing Kubernetes resources, this aims to help avoid timing issues when installing resources before certain services like cert-manager are fully up and running.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3.x walkthroughs</title>
      <link>https://jenkins-x.io/blog/2021/01/26/jx3-walkthroughs/</link>
      <pubDate>Tue, 26 Jan 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/01/26/jx3-walkthroughs/</guid>
      <description>
        
        
        &lt;p&gt;Jenkins X 3.x is now looking ahead towards a GA release, with that we are producing walkthroughs for key areas to help users not only get started but get the most out of Jenkins X.&lt;/p&gt;
&lt;p&gt;To kick this off we are going to start with 9 videos that we&amp;rsquo;ll follow up with more dedicated blogs over the coming weeks.  The complete playlist can be found &lt;a href=&#34;https://www.youtube.com/playlist?list=PLr_PmC4W69dKM3fo8OK729fdmX_MTqdHd&#34;&gt;here&lt;/a&gt; however the blog below gives a more context for each one.&lt;/p&gt;
&lt;p&gt;There are a few key areas we are focusing on here:&lt;/p&gt;
&lt;h2 id=&#34;intro--high-level-architecture&#34;&gt;Intro + high level architecture&lt;/h2&gt;
&lt;p&gt;Starting off with a very quick introduction including what to expect from the walkthrough series.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/kDCNDAyqwpo?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;p&gt;Jenkins X 3.x has focussed on clearer lines of separation, making the architecture significantly more pluggable, extensible and maintainable.  With better tooling including UIs and more reliable guard rails for installations and upgrades.  Jenkins X 3 also minimises abstractions and wrapping; so it promotes the direct use of open source projects like Helm, Helmfile and Tekton.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/bVp5_tZ21AA?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h1 id=&#34;installation-and-setup&#34;&gt;Installation and setup&lt;/h1&gt;
&lt;h2 id=&#34;infrastructure-and-provisioning&#34;&gt;Infrastructure and provisioning&lt;/h2&gt;
&lt;p&gt;Decoupling the management of Cloud infrastructure away from Jenkins X to tools that are better suited for the job.  Jenkins X has started with Terraform and this manages all the cloud resources needed by Jenkins X&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Kubernetes cluster&lt;/li&gt;
&lt;li&gt;Cloud Service Accounts&lt;/li&gt;
&lt;li&gt;IAM bindings&lt;/li&gt;
&lt;li&gt;Storage buckets&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Over time Jenkins X plans to support other tools (aided by the &lt;a href=&#34;https://github.com/kubernetes-sigs/cluster-api&#34;&gt;Kubernetes Cluster API&lt;/a&gt;) users in the Kubernetes ecosystem leverage such as &lt;a href=&#34;https://crossplane.io/&#34;&gt;crossplane.io&lt;/a&gt;, &lt;a href=&#34;https://cloud.google.com/config-connector/docs/overview&#34;&gt;Google Config Connector&lt;/a&gt;, &lt;a href=&#34;https://github.com/aws/aws-controllers-k8s&#34;&gt;AWS Controller&lt;/a&gt; etc.  These make use of cloud resources declared as custom resources with a Kubernetes operator managing CRUD activities for them.&lt;/p&gt;
&lt;p&gt;Once the cloud infrastructure is created, self provisioning happens using GitOps and incluster installation.  No more flakey client side installs.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/fKGZrNgs8So?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h2 id=&#34;tls-and-dns&#34;&gt;TLS and DNS&lt;/h2&gt;
&lt;p&gt;A large number of deployments require inbound traffic, whether that is for access to their applications, websites, REST endpoints, Webhook handlers there is often a need for Ingress HTTP traffic into a cluster and to ensure communication is secure.&lt;/p&gt;
&lt;p&gt;To achieve this there are two common efforts needed&lt;/p&gt;
&lt;p&gt;DNS - configuring a custom owned domain and using DNS to route traffic to endpoints
TLS - providing end to end security for web traffic on the internet&lt;/p&gt;
&lt;p&gt;In fact many web services do not accept working with insecure endpoints and others require manual override to accept the risk before being able to use the service.&lt;/p&gt;
&lt;p&gt;Jenkins X uses two OSS projects to automatically manage DNS (&lt;a href=&#34;https://github.com/kubernetes-sigs/external-dns&#34;&gt;External DNS&lt;/a&gt;) and handle the management of TLS certificates (&lt;a href=&#34;https://cert-manager.io/&#34;&gt;Cert-manager&lt;/a&gt;)&lt;/p&gt;
&lt;p&gt;Once a domain is owned, External DNS will work with cloud providers to create A records that route traffic from the internet to users clusters.  Cert-manager will react to a request from Jenkins X to verify a cluster owns a domain and will issue a wildcard TLS certificate using Lets Encrypt that is used for all Ingress into the cluster.  Cert-manager will also handle certificate renewals.  This is all handled automatically following the setup of Jenkins X.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/OqsSqZqF0gY?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h1 id=&#34;using-jenkins-x&#34;&gt;Using Jenkins X&lt;/h1&gt;
&lt;h2 id=&#34;gitops&#34;&gt;GitOps&lt;/h2&gt;
&lt;p&gt;Initially started out as an implementation detail of Jenkins X but has evolved much more into an administrators typical workflow.  Managing installs, upgrades and rollbacks via Git provides approvals, reviews, traceability, RBAC in the same way we manage code.  This is the backbone of Jenkins X and provides us with the peace of mind for disaster recovery.&lt;/p&gt;
&lt;p&gt;Jenkins X ships with a git operator which is responsible for applying generated Kubernetes resources which live in the cluster Git repository.  Every application and configuration for the cluster is in this repository.&lt;/p&gt;
&lt;h2 id=&#34;health&#34;&gt;Health&lt;/h2&gt;
&lt;p&gt;In any Kubernetes installation there can be a lot of microservices each with the responsibility to provide functionality that is needed by the overall system.  Understanding when things go wrong and the impact of these issues can be difficult to evaluate.  It is also useful to have a status page of sorts to quickly check the health of your system.&lt;/p&gt;
&lt;p&gt;Jenkins X uses &lt;a href=&#34;https://github.com/Comcast/kuberhealthy&#34;&gt;Kuberhealthy&lt;/a&gt; and a lot of custom health checks to periodically report on the health of a Jenkins X installation.  These custom health checks are easy to extend in any language, already the Jenkins X community has been contributing their own.&lt;/p&gt;
&lt;p&gt;There is a CLI which can be used to query the health report as well and a UI.&lt;/p&gt;
&lt;p&gt;The health statuses can be easily integrated into users operational alerting systems too.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/4wqwulEzseM?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h2 id=&#34;extending-pipelines&#34;&gt;Extending pipelines&lt;/h2&gt;
&lt;p&gt;Jenkins X uses vanilla Tekton pipeline resources and has deprecated the v2 &lt;code&gt;jenkins-x.yml&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;We will show a demo shortly of working with Tekton pipelines and inheriting shared Tasks but for now we can see it is easy using Lighthouse to trigger shared Pipelines from a git repository.  The demo uses the old favorite from the Jenkins project Chuck Norris, only here we are invoking a cloud native pipeline to comment with the joke on a Pull Request.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/cJcwV4jgE0Y?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h2 id=&#34;secrets&#34;&gt;Secrets&lt;/h2&gt;
&lt;p&gt;Secrets management stores (e.g. AWS Secrets Manager, Hashicorp Vault, Google Secrets Manager) have gained popularity from both Administrators and Developers.  Having a single source of truth for a secret is extremely useful especially when obtaining and changing values, some solutions even offer automatic secret rotation.&lt;/p&gt;
&lt;p&gt;With GitOps as described above we need a way to inject real secrets into a cluster rather than storing them in Git.&lt;/p&gt;
&lt;p&gt;Jenkins X uses &lt;a href=&#34;https://github.com/external-secrets/kubernetes-external-secrets&#34;&gt;External Secrets&lt;/a&gt; from which runs as a Kubernetes controller, using a Kubernetes Custom Resource it knows how to automatically map values from a Secret Management Store into Kubernetes Secrets.  This makes it easy for applications to leverage GitOps while keeping the benefits of using a secrets management solution.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/_gjGfwlxEY4?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h2 id=&#34;upgrades&#34;&gt;Upgrades&lt;/h2&gt;
&lt;p&gt;Jenkins X now uses GitOps for the whole cluster, one repository keeps all applications and configurations that should be applied to a cluster.  This cluster repository also includes a copy of the version stream mentioned below.  Jenkins X uses a tool called &lt;a href=&#34;https://github.com/GoogleContainerTools/kpt&#34;&gt;kpt&lt;/a&gt; which reliable syncrosises released version configuration into their own repository that can then be committed and applied to your cluster.&lt;/p&gt;
&lt;h2 id=&#34;version-streams&#34;&gt;Version Streams&lt;/h2&gt;
&lt;p&gt;The world of continuous delivery can bring challenges.  One of the biggest challenges Jenkins X itself had while embracing CD was how people handle receiving constant change via releases.&lt;/p&gt;
&lt;p&gt;Some people wanted to live on the bleeding edge, receiving fixes, improvements and new features as fast as possible so they can help provide feedback and continually improve.  Others had more stable requirements which expect more mature features along with corresponding complete documentation that gave better confidence an upgrade will not cause any adverse effects.&lt;/p&gt;
&lt;p&gt;Jenkins X has had the concept of version streams which allows the project to collect a number of helm charts, CLI, Docker image version changes together, run further automated testing and release together for users to consume in an upgrade.  This acts as a quality gate.&lt;/p&gt;
&lt;p&gt;For Jenkins X 3 we have extended this to include a second version stream which gets automatically updated via a Pull Request however that is merged on a slower cadence to cater for users that want greater confidence in the release.  We call this the &lt;a href=&#34;https://jenkins-x.io/v3/guides/upgrades/lts&#34;&gt;Long Term Support (LTS) version stream&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Users can decide which version stream to track or even use a custom one that they maintain themselves.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/9ZaqdwD3cTs?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h2 id=&#34;cluster-recovery&#34;&gt;Cluster recovery&lt;/h2&gt;
&lt;p&gt;Clusters can be recreated if they move regions, are accidentally deleted or part of intentional housekeeping to continually verify disaster recovery processes.&lt;/p&gt;
&lt;p&gt;Because Jenkins X uses Terraform for infrastructure checked into Git and a another Git repository specifically for the cluster, it means we can recreate a cluster and resume all services with very little manual intervention.  This video deletes and recovers a cluster on GCP using Jenkins X.&lt;/p&gt;
&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/2QgX3cn0GqU?VQ=HD1080&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: New features in the pipelines visualizer UI</title>
      <link>https://jenkins-x.io/blog/2021/01/18/jx-pipelines-visualizer-v1/</link>
      <pubDate>Mon, 18 Jan 2021 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2021/01/18/jx-pipelines-visualizer-v1/</guid>
      <description>
        
        
        &lt;p&gt;The &lt;a href=&#34;https://github.com/jenkins-x/jx-pipelines-visualizer&#34;&gt;Jenkins X Pipelines Visualizer UI&lt;/a&gt; has recently received a number of new features, so let&amp;rsquo;s do a little tour of these new features!&lt;/p&gt;
&lt;h2 id=&#34;pipeline-view&#34;&gt;Pipeline View&lt;/h2&gt;
&lt;p&gt;When viewing a pipeline, the biggest new feature is the &lt;strong&gt;collapsed logs&lt;/strong&gt;. No more hundreds - or thousands - of log lines, we now group the logs per-container (step), which are collapsed by default. Along with the status of the step and its duration, so it&amp;rsquo;s easier to go to the interesting part of the logs.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/jx-pipelines-visualizer/v1-pipeline-success.png&#34; alt=&#34;&#34;&gt;&lt;/p&gt;
&lt;p&gt;Clicking on a log line will expand the logs for this specific container. You can also use the &amp;ldquo;Toggle Steps&amp;rdquo; button to expand/collapse the logs for all the steps at once.&lt;/p&gt;
&lt;p&gt;While we&amp;rsquo;re talking about the logs, you can notice the 2 new buttons:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;View raw logs&lt;/li&gt;
&lt;li&gt;Download raw logs&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;On top of the logs, we now display some information about the pipeline:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;the pipeline &lt;strong&gt;meta information&lt;/strong&gt;: name, context, build, and a link to see the raw YAML representation of the pipeline&lt;/li&gt;
&lt;li&gt;the pipeline &lt;strong&gt;status&lt;/strong&gt;: status, started/finished date/time, and duration&lt;/li&gt;
&lt;li&gt;the pipeline &lt;strong&gt;source&lt;/strong&gt;: git repository, pull request or branch, commit SHA, author&lt;/li&gt;
&lt;li&gt;the pipeline &lt;strong&gt;stages&lt;/strong&gt;, with links to see the timeline of the steps in each stage. You can also click on the &amp;ldquo;Show Timeline&amp;rdquo; button to view the pipeline timeline with all stages and steps.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;The &lt;strong&gt;pipeline timeline&lt;/strong&gt; has been improved to include all the steps for all stages, but it is currently hidden by default - to avoid using too much space. Clicking on a stage will bring you to the steps, and clicking on a step will bring you to the logs for this step.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/jx-pipelines-visualizer/v1-pipeline-success-with-timeline.png&#34; alt=&#34;&#34;&gt;&lt;/p&gt;
&lt;p&gt;Note that for a pipeline which includes a deployment to a Preview Environment, the UI will also display a link to the application&amp;rsquo;s URL in that specific Preview Environment.&lt;/p&gt;
&lt;h2 id=&#34;homepage&#34;&gt;Homepage&lt;/h2&gt;
&lt;p&gt;The homepage got some love too, with:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;a few stats about the pipelines: top statuses, repositories, authors and durations - with links to filter the pipelines&lt;/li&gt;
&lt;li&gt;direct links to the git repositories and pull requests&lt;/li&gt;
&lt;li&gt;the Jenkins X logo&lt;/li&gt;
&lt;li&gt;and a favicon&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/jx-pipelines-visualizer/v1-home.png&#34; alt=&#34;&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;roadmap&#34;&gt;Roadmap&lt;/h2&gt;
&lt;p&gt;We started this project at v0, and we believe that now it has enough features to be a v1!&lt;/p&gt;
&lt;p&gt;On our roadmap - without any specific order - we have:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-pipelines-visualizer/issues/73&#34;&gt;#73&lt;/a&gt; &lt;strong&gt;live refresh of a running pipeline&lt;/strong&gt; - for now only the logs are updated live, not the meta information of the pipeline (status, stages/steps timings)&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-pipelines-visualizer/issues/42&#34;&gt;#42&lt;/a&gt; &lt;strong&gt;support local timezone&lt;/strong&gt; - for now everything is in UTC&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;improve the support for archived pipelines&lt;/strong&gt;: load pipelines archived in the long-term storage&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;contributing&#34;&gt;Contributing&lt;/h3&gt;
&lt;p&gt;Thanks to all the contributors!&lt;/p&gt;
&lt;p&gt;All contributions are welcomed, the source code is: &lt;a href=&#34;https://github.com/jenkins-x/jx-pipelines-visualizer&#34;&gt;github.com/jenkins-x/jx-pipelines-visualizer&lt;/a&gt;.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3.x beta is here!</title>
      <link>https://jenkins-x.io/blog/2020/12/09/jx-v3-beta/</link>
      <pubDate>Wed, 09 Dec 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/12/09/jx-v3-beta/</guid>
      <description>
        
        
        &lt;p&gt;I&amp;rsquo;m super excited to announce the 3.0 beta of Jenkins X! Christmas has come early this year!&lt;/p&gt;
&lt;img width=&#34;387px&#34; src=&#34;https://jenkins-x.io/images/jxxx.png&#34;&gt;
&lt;p&gt;the main documentation of the changes are:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/about/overview/&#34;&gt;the new architecture&lt;/a&gt; with modular plugins and improved &lt;a href=&#34;https://jenkins-x.io/v3/about/extending/&#34;&gt;extension points&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/about/changes/&#34;&gt;what has changed since 3.x started&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/about/comparison/&#34;&gt;how 3.x compares to 2.x&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;but here&amp;rsquo;s a brief summary of the differences:&lt;/p&gt;
&lt;h3 id=&#34;user-changes&#34;&gt;User Changes&lt;/h3&gt;
&lt;p&gt;As a user the high level UX of Jenkins X is similar:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#automated-pipelines&#34;&gt;automated Continuous Delivery pipelines&lt;/a&gt; for using &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/&#34;&gt;tekton&lt;/a&gt; for your repositories with &lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#promotion&#34;&gt;automatic promotion&lt;/a&gt; between your &lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#environments&#34;&gt;environments&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;pull requests on your repositories create separate &lt;a href=&#34;https://jenkins-x.io/about/concepts/features/#preview-environments&#34;&gt;Preview Environments&lt;/a&gt; where your team can review your changes and give fast feedback before your changes are approved and merged into the main trunk.&lt;/li&gt;
&lt;/ul&gt;
&lt;img width=&#34;600&#34; src=&#34;https://jenkins-x.io/images/pr-comment.png&#34; class=&#34;img-thumbnail&#34;&gt;
&lt;h4 id=&#34;new-features&#34;&gt;New features&lt;/h4&gt;
&lt;ul&gt;
&lt;li&gt;we now default to &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#source-changes&#34;&gt;vanilla tekton YAML for defining pipelines&lt;/a&gt; while &lt;a href=&#34;https://jenkins-x.io/blog/2020/11/11/accelerate-tekton/&#34;&gt;accelerating your tekton&lt;/a&gt; with &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#adding-tasks-from-the-tekton-catalog&#34;&gt;tekton catalog&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;we include an open source &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/dashboard/&#34;&gt;dashboard&lt;/a&gt; for visualising pipelines and logs which you can invoke via:&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx dash
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;ul&gt;
&lt;li&gt;we have a full &lt;a href=&#34;https://jenkins-x.io/v3/develop/ui/octant/&#34;&gt;Kubernetes and Jenkins X console&lt;/a&gt; based on the excellent &lt;a href=&#34;https://octant.dev/&#34;&gt;octant&lt;/a&gt; which you can try out via:&lt;/li&gt;
&lt;/ul&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-bash&#34; data-lang=&#34;bash&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;jx ui
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;iframe width=&#34;600&#34; height=&#34;300&#34; src=&#34;https://www.youtube.com/embed/2LCPHi0BnUg&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h3 id=&#34;platform-changes&#34;&gt;Platform Changes&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;we now use &lt;a href=&#34;https://helm.sh/&#34;&gt;helm&lt;/a&gt; (3.x) and &lt;a href=&#34;https://github.com/roboll/helmfile&#34;&gt;helmfile&lt;/a&gt; along with optionally &lt;a href=&#34;https://kustomize.io/&#34;&gt;kustomize&lt;/a&gt; in a GitOps style to define and configure both Jenkins X itself, your tools and applications in any namespace&lt;/li&gt;
&lt;li&gt;support &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/multi-cluster/&#34;&gt;multi cluster&lt;/a&gt; out of the box so you can keep &lt;code&gt;Staging&lt;/code&gt; and &lt;code&gt;Production&lt;/code&gt; in separate clusters to your development cluster where your pipelines run, you create and release immutable container images and other artifacts.&lt;/li&gt;
&lt;li&gt;to &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;setup or upgrade&lt;/a&gt; Jenkins X we use &lt;a href=&#34;https://www.terraform.io/&#34;&gt;terraform&lt;/a&gt; to setup your cloud resources on &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/azure/&#34;&gt;Azure&lt;/a&gt;, &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/eks/&#34;&gt;Amazon&lt;/a&gt; or &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/google/&#34;&gt;Google&lt;/a&gt; while also supporting on-premises, minkube and OpenShift - see the &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;Admin Guides&lt;/a&gt; for more detail
&lt;ul&gt;
&lt;li&gt;the actual installation of kubernetes resources takes place using the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/operator/&#34;&gt;git operator&lt;/a&gt; so it runs reliably inside the cluster itself&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;we default to using &lt;a href=&#34;https://github.com/external-secrets/kubernetes-external-secrets&#34;&gt;Kubernetes External Secrets&lt;/a&gt; to manage all secrets for Jenkins X itself, development tools and your applications too.
&lt;ul&gt;
&lt;li&gt;This means we can support various secret backends such as Alibaba Cloud KMS Secret Manager, Amazon Secret Manager, Azure Key Vault, Hashicorp Vault or GCP Secret Manager&lt;/li&gt;
&lt;li&gt;It also means we can then check in all kubernetes resources and custom resources directly into git (apart from Kubernetes &lt;code&gt;Secrets&lt;/code&gt;) so that it super easy to version, review and reason about your kubernetes resources in a GitOps way.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;built in &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/tls_dns/&#34;&gt;TLS and DNS&lt;/a&gt; support along with &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/health/&#34;&gt;Heath&lt;/a&gt; reporting and visualising via &lt;a href=&#34;https://github.com/Comcast/kuberhealthy&#34;&gt;kuberhealthy&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;we now have an &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/lts/&#34;&gt;LTS distribution&lt;/a&gt; which lets you switch to a much more slower cadence of releases of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We have been using Jenkins X 3.x in production now for many months (for CI/CD of all of the &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/source/&#34;&gt;3.x codebase&lt;/a&gt; and &lt;a href=&#34;https://jenkins-x.io/v3/admin/setup/upgrades/&#34;&gt;continuously upgrading our cluster in the standard way&lt;/a&gt; and it&amp;rsquo;s been much simpler and easier to use, operate and configure.&lt;/p&gt;
&lt;p&gt;In general Jenkins X 3.x is now much simpler and more flexible. It supports &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;lots more platforms than before&lt;/a&gt; and should be easy to extend and configure for other platforms too.&lt;/p&gt;
&lt;div class=&#34;row&#34;&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/eks/&#34; title=&#34;setup Jenkins X on Amazon cloud with EKS&#34;&gt;
            &lt;img alt=&#34;Amazon&#34; src=&#34;https://jenkins-x.io/images/logo/aws.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/azure/&#34; title=&#34;setup Jenkins X on Azure cloud with AKS&#34;&gt;
            &lt;img alt=&#34;Azure&#34; src=&#34;https://jenkins-x.io/images/logo/azure.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/gke/&#34; title=&#34;setup Jenkins X on Google Cloud with GKE&#34;&gt;
            &lt;img alt=&#34;Google&#34; src=&#34;https://jenkins-x.io/images/logo/gcp.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
&lt;/div&gt;

&lt;div class=&#34;row pt-4&#34;&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/on-premises/&#34; title=&#34;setup Jenkins X on any Kubernetes cluster without cloud resources&#34;&gt;
            &lt;img alt=&#34;On-Premises&#34; src=&#34;https://jenkins-x.io/images/logo/k8s.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/minikube/&#34; title=&#34;setup Jenkins X on your laptop&#34;&gt;
            &lt;img alt=&#34;Minkube&#34; src=&#34;https://jenkins-x.io/images/logo/minikube.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;h1 class=&#34;card-title&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/openshift/&#34; title=&#34;setup Jenkins X on OpenShift&#34;&gt;
            &lt;img width=&#34;397&#34; height=&#34;66&#34; alt=&#34;OpenShift&#34; src=&#34;https://jenkins-x.io/images/logo/openshift.png&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/h1&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
&lt;/div&gt;

&lt;div class=&#34;row pt-4&#34;&gt;
  &lt;div class=&#34;col-sm-4&#34;&gt;
    &lt;div class=&#34;card text-center align-center h-100&#34;&gt;
      &lt;div class=&#34;card-body align-center&#34;&gt;
        &lt;p class=&#34;card-text text-center&#34;&gt;
          &lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/k3s/&#34; title=&#34;setup Jenkins X on k3s&#34;&gt;
            &lt;img alt=&#34;k3s&#34; src=&#34;https://jenkins-x.io/images/logo/k3s-horizontal-color.svg&#34; style=&#34;float: none;&#34;/&gt;
          &lt;/a&gt;
        &lt;/p&gt;
      &lt;/div&gt;
    &lt;/div&gt;
  &lt;/div&gt;
&lt;/div&gt;


&lt;h3 id=&#34;getting-started&#34;&gt;Getting started&lt;/h3&gt;
&lt;p&gt;If you have never tried &lt;a href=&#34;https://jenkins-x.io/v3/about/&#34;&gt;3.x&lt;/a&gt; before then please follow the &lt;a href=&#34;https://jenkins-x.io/v3/admin/&#34;&gt;Admin Guide&lt;/a&gt; to get Jenkins X installed on your cloud provider, on-premises kubernetes cluster or minikube.&lt;/p&gt;
&lt;p&gt;If you previously tried the 3.x alpha then the &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/migrate/v3-alpha/&#34;&gt;migration instructions are here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;For folks on older 2.x versions of Jenkins X please see &lt;a href=&#34;https://jenkins-x.io/v3/admin/guides/migrate/v2/&#34;&gt;the 2.x migration instructions&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Once your cluster has been installed or migrated then check out the &lt;a href=&#34;https://jenkins-x.io/v3/develop/&#34;&gt;User Guide&lt;/a&gt; on how to develop software continuously with Jenkins X.&lt;/p&gt;
&lt;h3 id=&#34;final-thoughts&#34;&gt;Final thoughts&lt;/h3&gt;
&lt;p&gt;A huge thanks goes out to all the &lt;a href=&#34;https://jenkins-x.io/community/#contributors&#34;&gt;contributors&lt;/a&gt;, folks in the &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;Jenkins X community&lt;/a&gt; and the &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/projects/&#34;&gt;community around all the open source projects we reuse&lt;/a&gt; who&amp;rsquo;ve helped get this beta together. The improvements in Jenkins X 3.x since 2.x are totally amazing, well done everyone!&lt;/p&gt;
&lt;p&gt;Please give Jenkins X a try and &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;let us know what you think&lt;/a&gt; or &lt;a href=&#34;https://github.com/jenkins-x/issues&#34;&gt;raise an issue&lt;/a&gt;. All feedback highly appreciated - particularly how we can keep improving to help you develop faster.&lt;/p&gt;
&lt;p&gt;If you are at all interested in Continuous Delivery with kubernetes using &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/projects/&#34;&gt;tools&lt;/a&gt; like &lt;a href=&#34;https://helm.sh/&#34;&gt;helm&lt;/a&gt;, &lt;a href=&#34;https://github.com/roboll/helmfile&#34;&gt;helmfile&lt;/a&gt;, &lt;a href=&#34;https://knative.dev/&#34;&gt;knative&lt;/a&gt;,  &lt;a href=&#34;https://github.com/jenkins-x/lighthouse&#34;&gt;lighthouse&lt;/a&gt; and last but definitely not least, &lt;a href=&#34;https://github.com/tektoncd/cli&#34;&gt;tekton&lt;/a&gt;  then please join the &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;community&lt;/a&gt; - its great fun!&lt;/p&gt;
&lt;p&gt;I hope you have a great break over the holiday season and 2021 is a little better and more fun than 2020!&lt;/p&gt;
&lt;p&gt;For any questions and feedback please reach out on slack &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;https://jenkins-x.io/community/#slack&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X 3.x - beta is close!</title>
      <link>https://jenkins-x.io/blog/2020/12/04/jx-v3-update/</link>
      <pubDate>Fri, 04 Dec 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/12/04/jx-v3-update/</guid>
      <description>
        
        
        &lt;p&gt;It has been &amp;lsquo;all hands on deck&amp;rsquo; in recent months with the focus on Jenkins X 3 alpha.  First off a huge thankyou to everyone involved.  The OSS community spirit has really shone through what has been a very difficult year for everyone.  Knowing that people from all over the world come and help each other, share banter and work at all hours of the day to help build out a true open source cloud native continuous delivery solution for developers - it&amp;rsquo;s quite fantastic to see and amazing to be apart of.&lt;/p&gt;
&lt;p&gt;As a result of all this hard work the Beta is iminent so this is a good opportunity to thank all involved so far and to outline what to expect in the coming days.&lt;/p&gt;
&lt;p&gt;While we&amp;rsquo;ve been in the Alpha phase it has provided us with the opportunity to deprecate and remove APIs, commands and obsolete features that existed in v2.  This means we will not have any code dependency on the v2 codebase and so going forward v3 will be easier to maintain without the tech debt.&lt;/p&gt;
&lt;p&gt;With that, we aim to make a big push and roll out a few last changes in preparation for Beta, here&amp;rsquo;s a couple you will notice if you are already on the Alpha.  We recommend taking time to understand these, and avoid upgrading for a few days so that changes can be handled in one go, as there will be a constant stream of larger updates happening:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;jx requirements - this is the yaml file used to describe install needs for Jenkins X, until now there have been options available that were unsupported, confusing and in some cases did nothing.  These have now all been removed and the structure of the file has changed to be CRD like including an API version.  Upon upgrade &lt;code&gt;jx gitops upgrade&lt;/code&gt; will migrate your &lt;code&gt;jx-requirements.yml&lt;/code&gt; and push the changes back to the cluster gitops repository.  You should not see any errors however there are some pipeline steps that need to be updated in order to work with the new structure, this is covered next.&lt;/li&gt;
&lt;li&gt;pipeline catalog - currently Jenkins X 3.x defaults to in-repo pipelines where your Tekton resources are managed by kpt, these will need to be updated to work with the new or old requirements described above.  This means you will also need to run &lt;code&gt;jx gitops upgrade&lt;/code&gt; in each your application git repos.  In the near future Jenkins X 3.x will make it easy to work with shared pipeline libraries / catalog repositories, referencing them via URL rather than in-repo.  This is so that users have the flexibility to choose which option is best for your use case.  In-repo pipelines and shared pipeline libraries have pros and cons for each, mainly about maintaining changes.  But for now, you will need to upgrade each application git repository.&lt;/li&gt;
&lt;li&gt;nested helmfiles - this is a great feature from Chris Mellard which will be merged very soon.  The idea is that your cluster git repository will have support for multiple helmfiles, ones that will contain core Jenkins X charts and maintained by kpt via the &lt;code&gt;jx gitops upgrade&lt;/code&gt; process, and others where you can add your own charts rather than extending the single helmfile that is there today.&lt;/li&gt;
&lt;li&gt;nginx - for the alpha we have upgraded all the core helm charts we ship in a base Jenkins X installation, the last to land is Nginx thanks to Ankit!  This is not expected to cause issues however the change does involve moving to a different chart, there is a risk that there may be some very small window of downtime for the ingress controller so webhooks fired during the upgrade may fail to be delivered.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Balancing upgrades with continuous delivery brings many challenges.  However with Kubernetes, GitOps, Jenkins X version streams (including the monthly LTS coming soon) and other tools like kpt makes the process more transparent and provides a greater level of high availability.&lt;/p&gt;
&lt;p&gt;Jenkins X automatically upgrades its own infrastructure with every version stream release and we haven&amp;rsquo;t experienced any disruption during the alpha period so far.  We aim to continue this, but when we know there will be disruption we endeavour to inform and explain why ahead of time.&lt;/p&gt;
&lt;p&gt;Keep an eye out for announcements of the Beta and thanks again to all involved in the community and we are very much looking forward to welcoming new people too.  We are very excited for the Beta release and given the feedback so far we understand users are too.&lt;/p&gt;
&lt;p&gt;For any questions and feedback please reach out on slack &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;https://jenkins-x.io/community/#slack&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Accelerate your Tekton with Jenkins X</title>
      <link>https://jenkins-x.io/blog/2020/11/11/accelerate-tekton/</link>
      <pubDate>Wed, 11 Nov 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/11/11/accelerate-tekton/</guid>
      <description>
        
        
        &lt;p&gt;One of the goals of &lt;a href=&#34;https://jenkins-x.io/&#34;&gt;Jenkins X&lt;/a&gt; has always been to help &lt;a href=&#34;https://jenkins-x.io/about/overview/accelerate/&#34;&gt;accelerate&lt;/a&gt; and automate Continuous Delivery so that developers can focus on delivering value to their customers; either by creating that new microservice or adding features to an existing project and not writing and managing pipelines.&lt;/p&gt;
&lt;p&gt;Pipeline engines like &lt;a href=&#34;https://www.jenkins.io/&#34;&gt;Jenkins&lt;/a&gt; and &lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton&lt;/a&gt; are awesome - they can do anything! But they start as a blank sheet of paper where you have to fill in all the details of how to compile your code, test it, verify it, tag it, release, distribute and delivery it to production. Figuring all that stuff out can take a huge amount of time to create and maintain. This gets even more complex as we are all creating more and more microservices each with their own pipelines making more and more things to create and manage.&lt;/p&gt;
&lt;p&gt;We want to be able to reuse pipelines and tasks to get work done. But at the same time we want flexibility; not all applications are the same and sometimes things need to be changed on a per team or application basis.&lt;/p&gt;
&lt;h2 id=&#34;version-2x&#34;&gt;Version 2.x&lt;/h2&gt;
&lt;p&gt;In Jenkins X 2.x we went with a &lt;code&gt;jenkins-x.xml&lt;/code&gt; approach to pipelines which let you inherit pipelines from reuable pipeline library and then use a composition DSL above &lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton&lt;/a&gt; which lets you add/remove/replace steps.&lt;/p&gt;
&lt;p&gt;e.g. to use the &lt;code&gt;javascript&lt;/code&gt; pipeline library but override a step you could use:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;buildPack&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;javascript&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;pipelineConfig&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;pipelines&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;overrides&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;      - &lt;span style=&#34;color:#f92672&#34;&gt;pipeline&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;release&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;name&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;helm-release&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;        &lt;span style=&#34;color:#f92672&#34;&gt;step&lt;/span&gt;: 
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;image&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;busybox&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;          &lt;span style=&#34;color:#f92672&#34;&gt;sh&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;echo &amp;#34;this command is replaced&amp;#34;&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;This was a pretty good approach; it lets us reuse common pipelines in a shared git repository and let&amp;rsquo;s reuse a composition DSL.&lt;/p&gt;
&lt;p&gt;However we&amp;rsquo;ve found that this approach as a few downsides:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;we have to create and maintain a DSL above Tekton which adds complexity and can be a leaky abstraction
&lt;ul&gt;
&lt;li&gt;e.g. the DSL does not yet support all of the semantics of Tekton yet such as conditions, &lt;a href=&#34;https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#using-the-runafter-parameter&#34;&gt;runAfter&lt;/a&gt; or &lt;a href=&#34;https://github.com/tektoncd/pipeline/blob/master/docs/pipelines.md#adding-finally-to-the-pipeline&#34;&gt;finally tasks&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;tekton moves fast; it&amp;rsquo;s hard to keep up in a DSL ;)&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;its complex trying to understand how to make local modifications of pipelines
&lt;ul&gt;
&lt;li&gt;particularly if you just want to add an environment variable; modify a command line argument or something&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;we can&amp;rsquo;t use &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#ide-support&#34;&gt;IDE tooling&lt;/a&gt; for &lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton&lt;/a&gt; to edit/visualise pipelines&lt;/li&gt;
&lt;li&gt;we can&amp;rsquo;t reuse &lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog tasks&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;vision&#34;&gt;Vision&lt;/h2&gt;
&lt;p&gt;We want developers to have reusable pipelines for all their applications lifecycles:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;continuous integration&lt;/li&gt;
&lt;li&gt;verification, testing, linting&lt;/li&gt;
&lt;li&gt;releasing, packaging, promoting, deploying&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We also want to:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;automate the generation of pipelines so most of the time developers don&amp;rsquo;t need to care about pipelines&lt;/li&gt;
&lt;li&gt;reuse pipelines across applications
&lt;ul&gt;
&lt;li&gt;usually all, say, spring boot microservices tend to be built and released in the same way&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;make it easy for developers to view/edit the pipelines if required
&lt;ul&gt;
&lt;li&gt;maintain those changes over time as everything in the cloud native ecosystem is changing all the time&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;From a technical perspective:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;we believe &lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton&lt;/a&gt; is currently the best cloud native standard way to represent pipelines and tasks for Continuous Delivery and we want that to be the primary DSL for developers and tools&lt;/li&gt;
&lt;li&gt;we want to work with the &lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog&lt;/a&gt; so its easy to share tasks among teams&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;version-3x&#34;&gt;Version 3.x&lt;/h2&gt;
&lt;p&gt;For &lt;a href=&#34;https://jenkins-x.io/v3/&#34;&gt;Jenkins X 3.x&lt;/a&gt; we really wanted to move closer to this vision: to &lt;em&gt;accelerate&lt;/em&gt; the adoption of Tekton and help give developers Tekton super powers.&lt;/p&gt;
&lt;p&gt;Re-reading &lt;a href=&#34;https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/declarative-application-management.md&#34;&gt;Brian Grant&amp;rsquo;s document on Declarative application management in Kubernetes&lt;/a&gt; really got us thinking about this problem of how to reuse complex YAML files for pipelines and tasks while also allowing local modifications while also avoiding a complex leaky DSL for composition.&lt;/p&gt;
&lt;p&gt;Then we tried out &lt;a href=&#34;https://googlecontainertools.github.io/kpt/&#34;&gt;kpt&lt;/a&gt; (pronounced &lt;code&gt;kept&lt;/code&gt;) and everything fell into place pretty quickly.&lt;/p&gt;
&lt;h3 id=&#34;using-tekton-in-your-repository&#34;&gt;Using Tekton in your repository&lt;/h3&gt;
&lt;p&gt;When you &lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/#create-a-new-project-from-a-quickstart&#34;&gt;create a new quickstart&lt;/a&gt; or &lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/#import-an-existing-project&#34;&gt;import a repository&lt;/a&gt; into &lt;a href=&#34;https://jenkins-x.io/v3/&#34;&gt;Jenkins X 3.x&lt;/a&gt; you get a new folder: &lt;strong&gt;.lighthouse/jenkins-x&lt;/strong&gt; added to your source code which contains the Tekton pipeline files you need for your application.&lt;/p&gt;
&lt;p&gt;So for a typical application the &lt;strong&gt;.lighthouse/jenkins-x&lt;/strong&gt; folder will contain:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;release.yaml&lt;/strong&gt; the Tekton &lt;code&gt;PipelineRun&lt;/code&gt; for releasing your application&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;pullrequest.yaml&lt;/strong&gt; the Tekton &lt;code&gt;PipelineRun&lt;/code&gt; for perform continuous integration testing, verification and the creation of a Preview Environment for your proposed changes before they merge to the main branch&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;triggers.yaml&lt;/strong&gt; to define the &lt;a href=&#34;https://github.com/jenkins-x/lighthouse&#34;&gt;lighthouse&lt;/a&gt; &lt;a href=&#34;https://github.com/jenkins-x/lighthouse/blob/master/docs/trigger/github-com-jenkins-x-lighthouse-pkg-triggerconfig.md#Config&#34;&gt;TriggerConfig&lt;/a&gt; which defines the &lt;a href=&#34;https://jenkins-x.io/docs/resources/faq/using/chatops/#what-is-chatops&#34;&gt;ChatOps&lt;/a&gt; and triggering configuration via a &lt;a href=&#34;https://github.com/jenkins-x/lighthouse/blob/master/docs/trigger/github-com-jenkins-x-lighthouse-pkg-triggerconfig.md#ConfigSpec&#34;&gt;spec field&lt;/a&gt; which defines &lt;a href=&#34;https://github.com/jenkins-x/lighthouse/blob/master/docs/trigger/github-com-jenkins-x-lighthouse-pkg-config-job.md#Presubmit&#34;&gt;presubmits&lt;/a&gt; and &lt;a href=&#34;https://github.com/jenkins-x/lighthouse/blob/master/docs/trigger/github-com-jenkins-x-lighthouse-pkg-config-job.md#Postsubmit&#34;&gt;postsubmits&lt;/a&gt; (i.e. Pull Request and Release triggers).&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;See the &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/&#34;&gt;Pipeline Catalog documentation&lt;/a&gt; for more details on how this works and go to the &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#reference-guide&#34;&gt;reference guide&lt;/a&gt; if you want to dive into the details.&lt;/p&gt;
&lt;p&gt;As a developer you can mostly ignore the &lt;code&gt;.lighthouse&lt;/code&gt; folder if you don&amp;rsquo;t care about how the pipelines work. If you are interested you can look inside.&lt;/p&gt;
&lt;p&gt;If you need to modify anything, just open the Tekton files in your &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#ide-support&#34;&gt;IDE&lt;/a&gt; and modify them. No complex DSL to understand other than Tekton itself. Then the changes will be used when you submit your local changes via a Pull Request (for the pull request pipeline) or they get merged to the main branch (for release pipeline changes).&lt;/p&gt;
&lt;p&gt;To handle change going forward from upstream pipeline catalogs while preserving any local modifications we use a generic &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#upgrading-pipelines-and-helm-charts&#34;&gt;update mechanism on all git repositories&lt;/a&gt; which is powered by &lt;a href=&#34;https://googlecontainertools.github.io/kpt/&#34;&gt;kpt&lt;/a&gt;&lt;/p&gt;
&lt;h3 id=&#34;reusing-tekton-catalog-tasks&#34;&gt;Reusing Tekton Catalog Tasks&lt;/h3&gt;
&lt;p&gt;The &lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog&lt;/a&gt; contains a ton of reusable Tekton &lt;code&gt;Tasks&lt;/code&gt; for doing all kinds of things in the Continuous Delivery landscape with a variety of tools.&lt;/p&gt;
&lt;p&gt;We want to make it super easy for you to reuse any of them easily in your project.&lt;/p&gt;
&lt;p&gt;So now the new &lt;a href=&#34;https://github.com/jenkins-x/jx-pipeline/blob/master/docs/cmd/jx-pipeline_import.md&#34;&gt;jx pipeline import&lt;/a&gt; command can be used to import &lt;code&gt;Task&lt;/code&gt; resources from the &lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog&lt;/a&gt; so you can use them inside your project.&lt;/p&gt;
&lt;p&gt;Here&amp;rsquo;s a &lt;a href=&#34;https://asciinema.org/a/368282&#34;&gt;demo of this in action&lt;/a&gt;:&lt;/p&gt;
&lt;script src=&#34;https://asciinema.org/a/368282.js&#34; id=&#34;asciicast-368282&#34; async&gt;&lt;/script&gt;
&lt;p&gt;The tekton Task resources are copied into your &lt;strong&gt;.lighthouse&lt;/strong&gt; directory in a folder using &lt;a href=&#34;https://googlecontainertools.github.io/kpt/&#34;&gt;kpt&lt;/a&gt; so that you can modify things locally if you need to and can &lt;a href=&#34;https://jenkins-x.io/v3/develop/pipeline-catalog/#upgrading-pipelines-and-helm-charts&#34;&gt;upgrade your local copy with upstream changes&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;This lets you work with shared resources from the Tekton community and, when required, modify them to suit and manage them easily over time.&lt;/p&gt;
&lt;h3 id=&#34;sharing-steps-between-tasks&#34;&gt;Sharing steps between Tasks&lt;/h3&gt;
&lt;p&gt;&lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton&lt;/a&gt; makes it super easy to share &lt;code&gt;Task&lt;/code&gt; resources between different &lt;code&gt;Pipeline&lt;/code&gt; instances. Though there is a current &lt;a href=&#34;https://github.com/tektoncd/pipeline/issues/3476&#34;&gt;limitation&lt;/a&gt; where splitting a &lt;code&gt;Pipeline&lt;/code&gt; into multiple reusable &lt;code&gt;Task&lt;/code&gt; instances results in the pipeline being split among multiple &lt;code&gt;Pod&lt;/code&gt; resources; which means to share state between the Tasks you need to use a &lt;code&gt;Persistent Volume&lt;/code&gt; for each pipeline run which can be a bit of an overhead.&lt;/p&gt;
&lt;p&gt;For example: you may think it&amp;rsquo;s a nice idea to have a reusable &lt;code&gt;Task&lt;/code&gt; to git clone your source code then use it with your other &lt;code&gt;Task&lt;/code&gt; to run your tests. It turns out that can be quite expensive infrastructure wise; as it means your cluster will end up making a Persistent Volume for each pipeline invocation so that the git clone pod can clone git and store the state on the PV so that your real Task pod can start and mount the same volume to see the contents of git. Its much easier to just share the git clone steps in each Task; so that there&amp;rsquo;s no need for the PV; just git clone in each separate Task directly.&lt;/p&gt;
&lt;p&gt;So for cases where you want to reuse a collection of steps inside &lt;code&gt;Task&lt;/code&gt; resources we added an annotation in &lt;a href=&#34;https://github.com/jenkins-x/lighthouse&#34;&gt;lighthouse&lt;/a&gt; so that we can import steps from a URL to avoid the copy/paste.&lt;/p&gt;
&lt;p&gt;e.g. in our &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/tree/master/packs&#34;&gt;pipeline catalog&lt;/a&gt; we use this approach to share the git clone Task steps such as &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/blob/master/packs/javascript/.lighthouse/jenkins-x/release.yaml#L4-L5&#34;&gt;this example&lt;/a&gt;:&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; style=&#34;color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;&#34;&gt;&lt;code class=&#34;language-yaml&#34; data-lang=&#34;yaml&#34;&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;apiVersion&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;tekton.dev/v1beta1&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;kind&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;Task&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;metadata&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#f92672&#34;&gt;annotations&lt;/span&gt;:        
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#75715e&#34;&gt;# lets share the git clone tasks as the initial steps in this Task&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;    &lt;span style=&#34;color:#f92672&#34;&gt;lighthouse.jenkins-x.io/prependStepsURL&lt;/span&gt;: &lt;span style=&#34;color:#ae81ff&#34;&gt;https://raw.githubusercontent.com/jenkins-x/jx3-pipeline-catalog/005e78cf69b643862344397a635736a51dd1bd89/tasks/git-clone/git-clone.yaml&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;&lt;span style=&#34;color:#f92672&#34;&gt;spec&lt;/span&gt;:
&lt;/span&gt;&lt;/span&gt;&lt;span style=&#34;display:flex;&#34;&gt;&lt;span&gt;  &lt;span style=&#34;color:#ae81ff&#34;&gt;...&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;Hopefully we can migrate to a standard tekton based approach &lt;a href=&#34;https://github.com/tektoncd/pipeline/issues/3476&#34;&gt;if this issue is resolved&lt;/a&gt;.&lt;/p&gt;
&lt;h3 id=&#34;custom-pipeline-catalogs&#34;&gt;Custom Pipeline Catalogs&lt;/h3&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog&lt;/a&gt; is an awesome way to reuse Tasks but it doesn&amp;rsquo;t help when trying to reuse complete &lt;code&gt;PipelineRun&lt;/code&gt; and &lt;code&gt;Pipeline&lt;/code&gt; resources across projects and repositories while also being able to modify them as needed on a per team or repository basis.&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://jenkins-x.io/v3/&#34;&gt;Jenkins X 3.x&lt;/a&gt; comes with its own default &lt;a href=&#34;https://github.com/jenkins-x/jx3-pipeline-catalog/tree/master/packs&#34;&gt;pipeline catalog for different languages, tools and frameworks&lt;/a&gt;. This catalog contains reusable steps, Tasks and Pipelines you can use on any project.&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s easy for you to fork this catalog to make changes for your team or share between teams in your company. You can make as many catalogs as you like and put whichever catalogs you want in the &lt;code&gt;extensions/pipeline-catalogs.yaml&lt;/code&gt; file of your cluster git repository of your &lt;a href=&#34;https://jenkins-x.io/v3/&#34;&gt;Jenkins X 3.x install&lt;/a&gt;. For more detail there&amp;rsquo;s the &lt;a href=&#34;https://github.com/jenkins-x/jx-project/blob/master/docs/config.md#project.jenkins-x.io/v1alpha1.PipelineCatalog&#34;&gt;configuration reference here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Then when developers &lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/#create-a-new-project-from-a-quickstart&#34;&gt;create a new quickstart&lt;/a&gt; or &lt;a href=&#34;https://jenkins-x.io/v3/develop/create-project/#import-an-existing-project&#34;&gt;import a repository&lt;/a&gt; developers will be asked to pick the catalog they want from your list if there is more than one, or the configured catalog is silently used.&lt;/p&gt;
&lt;p&gt;This gives you complete freedom to configure things at a global, team or repository level while also making it easy to share changes across projects, teams and companies.&lt;/p&gt;
&lt;h3 id=&#34;conclusion&#34;&gt;Conclusion&lt;/h3&gt;
&lt;p&gt;We are super excited about the combination of &lt;a href=&#34;https://jenkins-x.io/v3/&#34;&gt;Jenkins X 3.x&lt;/a&gt;, &lt;a href=&#34;https://tekton.dev/&#34;&gt;Tekton&lt;/a&gt;, &lt;a href=&#34;https://github.com/tektoncd/catalog&#34;&gt;Tekton Catalog&lt;/a&gt; and ChatOps.&lt;/p&gt;
&lt;p&gt;We hope that you can use the above capabilities to solve your Continuous Delivery needs and over time you can take your Pipelines and make your own Pipeline Catalogs and share them with folks inside and outside of your company.&lt;/p&gt;
&lt;p&gt;Hopefully this can help us all accelerate our Tekton pipelines and catalogs towards more continuous delivery awesome with flexible reusable tasks and pipelines! If you want to give this a try &lt;a href=&#34;https://jenkins-x.io/v3/&#34;&gt;check out Jenkins X 3.x&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Hacktoberfest</title>
      <link>https://jenkins-x.io/blog/2020/09/23/hacktoberfest2020/</link>
      <pubDate>Wed, 23 Sep 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/09/23/hacktoberfest2020/</guid>
      <description>
        
        
        &lt;figure&gt;
&lt;img src=&#34;https://jenkins-x.io/images/community/events/2020-hacktoberfest.jpg&#34;/&gt;
&lt;/figure&gt;
&lt;p&gt;We are excited to announce that Jenkins X will be participating in Hacktoberfest again this year! Hacktoberfest is a month-long global celebration of open source software.&lt;/p&gt;
&lt;p&gt;From October 1 to October 31, submit four pull requests to qualify for the limited edition Hacktoberfest shirt. All backgrounds and skill levels are encouraged to participate in Hacktoberfest and join a global community of open source contributors.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Learn more about Hacktoberfest and sign up &lt;a href=&#34;https://hacktoberfest.digitalocean.com/&#34;&gt;here&lt;/a&gt;.&lt;/strong&gt;&lt;/p&gt;
&lt;h3 id=&#34;contribute-to-jenkins-x&#34;&gt;Contribute to Jenkins X&lt;/h3&gt;
&lt;p&gt;We welcome your contributions to the Jenkins X project!&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-docs/issues?q=is%3Aissue+is%3Aopen+hacktoberfest&#34;&gt;Issues labelled &amp;ldquo;hacktoberfest&amp;rdquo;&lt;/a&gt; generally indicate good first issues. However, all pull requests will count towards your Hacktoberfest challenge. Jenkins X welcomes contributors to both:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx&#34;&gt;the Jenkins X &lt;code&gt;jx&lt;/code&gt; source code&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://github.com/jenkins-x/jx-docs&#34;&gt;the Jenkins X documentation website&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id=&#34;contribute-to-jx-source-code&#34;&gt;Contribute to &lt;code&gt;jx&lt;/code&gt; source code&lt;/h3&gt;
&lt;p&gt;There are plenty of &lt;a href=&#34;https://github.com/jenkins-x/jx/issues&#34;&gt;open issues&lt;/a&gt;, and we welcome your help in making Jenkins X even more awesome.&lt;/p&gt;
&lt;p&gt;Jenkins X is written largely in Go, but you don&amp;rsquo;t need to be an expert to contribute! If you are new to the project, search for issues labelled &amp;ldquo;good-first-issue&amp;rdquo;. Our &lt;a href=&#34;https://jenkins-x.io/community/code/&#34;&gt;Contributing Guide&lt;/a&gt; has advice for getting started with contributing to Jenkins X.&lt;/p&gt;
&lt;h3 id=&#34;contribute-to-the-docs&#34;&gt;Contribute to the docs&lt;/h3&gt;
&lt;p&gt;We welcome your help in improving the Jenkins X documenation. If you see areas of the documentation that need fixing or augmentation please raise a pull request. Our guide for &lt;a href=&#34;https://jenkins-x.io/community/documentation/&#34;&gt;Contributing to the Documentation&lt;/a&gt; has advice for getting started with contributing to the Jenkins X docs.&lt;/p&gt;
&lt;h3 id=&#34;ask-us-questions&#34;&gt;Ask us questions&lt;/h3&gt;
&lt;p&gt;We&amp;rsquo;re happy to help if you have any questions. Talk to us on our slack channels, which are part of the Kubernetes slack. Join  Kubernetes slack &lt;a href=&#34;http://slack.k8s.io/&#34;&gt;here&lt;/a&gt; and find us on our channels:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;#jenkins-x-dev for developers of Jenkins X&lt;/li&gt;
&lt;li&gt;#jenkins-x-user for users of Jenkins X&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We also have online office hours, where we talk about new developments in Jenkins X and you are welcome to ask us questions. We meet for office hours &lt;strong&gt;every other Tuesday&lt;/strong&gt; at 15:00 UTC (&lt;em&gt;See your timezone &lt;a href=&#34;https://time.is/1500_in_UTC&#34;&gt;here&lt;/a&gt;&lt;/em&gt;).&lt;/p&gt;
&lt;p&gt;Next office hours are on &lt;strong&gt;6 October&lt;/strong&gt;. Join us on this &lt;a href=&#34;https://zoom.us/j/397862697&#34;&gt;meeting link&lt;/a&gt;. See the &lt;a href=&#34;https://jenkins-x.io/community/calendar/&#34;&gt;Jenkins X calendar&lt;/a&gt; for events that you are welcome to join.&lt;/p&gt;
&lt;p&gt;Find out more about becoming involved in the Jenkins X community &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;We look forward to seeing you in open source, fixing all the things!&lt;/em&gt;&lt;/p&gt;
&lt;img src=&#34;https://jenkins-x.io/images/404-page/GOPHER RIDING REX.png&#34; class=&#34;img-thumbnail&#34;&gt;
&lt;p&gt;image by Ashley McNamara, &lt;a href=&#34;https://github.com/ashleymcnamara/gophers/blob/master/GOPHER%20RIDING%20REX.png&#34;&gt;creative commons license&lt;/a&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: New UI to visualize your pipelines and logs</title>
      <link>https://jenkins-x.io/blog/2020/09/23/jx-pipelines-visualizer/</link>
      <pubDate>Wed, 23 Sep 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/09/23/jx-pipelines-visualizer/</guid>
      <description>
        
        
        &lt;p&gt;Welcome to the &lt;a href=&#34;https://github.com/dailymotion/jx-pipelines-visualizer&#34;&gt;Jenkins X Pipelines Visualizer&lt;/a&gt;: a new open-source read-only UI for Jenkins X, with a very specific goal and scope: visualize the pipelines and logs.&lt;/p&gt;
&lt;p&gt;This project was started at &lt;a href=&#34;https://www.dailymotion.com/&#34;&gt;Dailymotion&lt;/a&gt; and quickly shared with the Jenkins X community.&lt;/p&gt;
&lt;h2 id=&#34;why-a-new-ui&#34;&gt;Why a new UI?&lt;/h2&gt;
&lt;p&gt;There is already the &lt;a href=&#34;https://jenkins-x.io/blog/2020/08/06/octant-jx/&#34;&gt;Octant-based UI&lt;/a&gt;, so why a new UI?&lt;/p&gt;
&lt;p&gt;The main reason is that &lt;a href=&#34;https://octant.dev/&#34;&gt;Octant&lt;/a&gt; &amp;ldquo;is an application and is intended as a single client tool and at this time there are no plans to support hosted versions of Octant&amp;rdquo; - see &lt;a href=&#34;https://github.com/vmware-tanzu/octant/pull/450&#34;&gt;this thread on the Octant github repository&lt;/a&gt; for more information and details.&lt;/p&gt;
&lt;p&gt;So while Octant answers to a lot of use-cases, there is one for which it is not suited: quickly printing the build logs on a browser, for a specific pipeline. We want to be able to click on a link from a Pull/Merge Request, and get the pipeline logs. This is the specific use-case covered by the Pipelines Visualizer.&lt;/p&gt;
&lt;h2 id=&#34;features&#34;&gt;Features&lt;/h2&gt;
&lt;p&gt;We want to keep it small, focused, and fast. It&amp;rsquo;s a read-only UI, so there won&amp;rsquo;t be &amp;ldquo;actions&amp;rdquo; to trigger a pipeline - because it can already be done using &amp;ldquo;chatops&amp;rdquo; commands in the Pull Request for example.&lt;/p&gt;
&lt;p&gt;But there are a few interesting features already:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;first, it&amp;rsquo;s very fast to get the logs. Much faster than the old JXUI.&lt;/li&gt;
&lt;li&gt;it can retrieve the logs from pipelines that have been garbage-collected - if you configure the URL of the buckets where the logs are stored.&lt;/li&gt;
&lt;li&gt;it has URLs compatible with the old JXUI - so it&amp;rsquo;s very easy to replace the old JXUI with this new UI and keep all the links working.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;roadmap&#34;&gt;Roadmap&lt;/h2&gt;
&lt;p&gt;This project was shared very early with the community, after just a few hours of work. So our short-term goal is to improve the UI - make it beautiful.&lt;/p&gt;
&lt;h2 id=&#34;demo&#34;&gt;Demo&lt;/h2&gt;
&lt;p&gt;We did a &lt;a href=&#34;https://youtu.be/zv0Dn9RYzwE?t=709&#34;&gt;demo of jx-pipelines-visualizer&lt;/a&gt; at the last &lt;a href=&#34;https://jenkins-x.io/community/office_hours/&#34;&gt;office hours&lt;/a&gt;:&lt;/p&gt;
 &lt;iframe width=&#34;80%&#34; height=&#34;460&#34; src=&#34;https://www.youtube.com/embed/zv0Dn9RYzwE?start=709&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;h2 id=&#34;next-steps&#34;&gt;Next steps&lt;/h2&gt;
&lt;p&gt;Check out the &lt;a href=&#34;https://github.com/dailymotion/jx-pipelines-visualizer&#34;&gt;jx-pipelines-visualizer github repository&lt;/a&gt; if you want to install it in your cluster - there is a Helm Chart which can be added to your Jenkins X Dev Environment.&lt;/p&gt;
&lt;p&gt;And any contributions are welcomed - either create an issue or pull request in the project&amp;rsquo;s github repository, or come in the &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;#jenkins-x-dev&lt;/a&gt; Slack Channel.&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Jenkins X Talks at CDCon</title>
      <link>https://jenkins-x.io/blog/2020/09/16/cdcon2020/</link>
      <pubDate>Wed, 16 Sep 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/09/16/cdcon2020/</guid>
      <description>
        
        
        &lt;p&gt;There will be six Jenkins X talks given by various speakers at the first-ever &lt;a href=&#34;https://events.linuxfoundation.org/cdcon/&#34;&gt;CDCon&lt;/a&gt; on October 7-8. The two-day virtual event, hosted by the Continuous Delivery Foundation, will focus on improving the world&amp;rsquo;s capacity to deliver software with security and speed.&lt;/p&gt;
&lt;p&gt;&lt;a href=&#34;https://events.linuxfoundation.org/cdcon/&#34;&gt;Register&lt;/a&gt; to attend the virtual event for only 25 USD and get access to all of the following Jenkins X talks and more.&lt;/p&gt;
&lt;h2 id=&#34;wednesday-october-7&#34;&gt;Wednesday, October 7&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://cdcon2020.sched.com/event/dpvW/a-cicd-framework-for-production-machine-learning-at-massive-scale-using-jenkins-x-and-seldon-core-alejandro-saucedo-seldon&#34;&gt;A CI/CD Framework for Production Machine Learning at Massive Scale (using Jenkins X and Seldon Core)&lt;/a&gt;&lt;/strong&gt;
&lt;strong&gt;Speaker:&lt;/strong&gt; Alejandro Saucedo, Seldon
&lt;strong&gt;Time:&lt;/strong&gt; 1:15 PM PDT&lt;/p&gt;
&lt;p&gt;Managing production machine learning systems as internal data science infrastructure requirements grow, has uncovered new challenges which have required fundamentally different approaches to that of traditional CI/CD in software engineering. In this talk we will dive into the work we are doing at the SIG-MLOps and the CD Foundation towards developing the methodologies that encompass best practices to continuously integrate and deploy machine learning in production at massive scale. In this talk, we&amp;rsquo;ll provide key insights on the core MLOps concepts, as well as a hands-on coding example where we take a text classification model through its training, deployment and promotion as canary and shadow deployments, which will also allow us to get deeper and more specific insight on our production environment.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://cdcon2020.sched.com/event/dpvQ/dailymotions-continuous-delivery-story-vincent-behar-dailymotion&#34;&gt;Dailymotion&amp;rsquo;s Continuous Delivery Story&lt;/a&gt;&lt;/strong&gt;
&lt;strong&gt;Speaker:&lt;/strong&gt; Vincent Behar, Dailymotion
&lt;strong&gt;Time:&lt;/strong&gt; 3:30 PM PDT&lt;/p&gt;
&lt;p&gt;In this session, Vincent will share Dailymotion&amp;rsquo;s Continuous Delivery story with Jenkins, Jenkins X and Tekton. He will come back on the initial state and issues faced on the CI/CD topic, and how it was solved. He will insist on the practices that were put in place and the benefits that resulted from switching to Jenkins X. He will conclude with the new challenges brought by improving Dailymotion&amp;rsquo;s Continuous Delivery platform. If you are wondering if Jenkins X is the right tool for you, and the impact it can have on your team(s), then this is the right session for you!&lt;/p&gt;
&lt;h2 id=&#34;thursday-october-8&#34;&gt;Thursday, October 8&lt;/h2&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://cdcon2020.sched.com/event/e2NG/moving-from-jenkins-to-jenkins-x-scaling-and-accelerating-cicd-dr-michael-garbade-education-ecosystem&#34;&gt;Moving from Jenkins to Jenkins X: Scaling and Accelerating CI/CD&lt;/a&gt;&lt;/strong&gt;
&lt;strong&gt;Speaker:&lt;/strong&gt; Dr Michael Garbade, Education Ecosystem
&lt;strong&gt;Time:&lt;/strong&gt; 12:00 PM PDT&lt;/p&gt;
&lt;p&gt;Jenkins has served as a continuous integration (CI) tool long before the emergence of Kubernetes and distributed systems running on cloud-native platforms.
Working with Jenkins as a stand-alone open-source tool has proved to be extremely difficult for distributed systems engineers, as it is designed for small projects and not scalable to bigger projects.
Jenkins X has emerged as a way to both improve and automate continuous delivery pipelines to Kubernetes and cloud-native environments.
In this talk, we will discuss the limitations of Jenkins, how Jenkins X addresses those limitations, how it leverages open source and commercial CI/CD tools for easier bug fixes, faster deployments, stability, consistency and improved communication.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://cdcon2020.sched.com/event/dpvc/enable-a-pipeline-as-code-capability-for-12000-developers-jimmy-mcnamara-fidelity-investments&#34;&gt;Enable a Pipeline As Code Capability for 12,000 Developers&lt;/a&gt;&lt;/strong&gt;
&lt;strong&gt;Speaker:&lt;/strong&gt; Jimmy McNamara, Fidelity Investments
&lt;strong&gt;Time:&lt;/strong&gt; 1:00 PM PDT&lt;/p&gt;
&lt;p&gt;Aoife Fitzmaurice and Jimmy McNamara take us through a journey on how Fidelity Investments plans to roll out a Pipeline As Code capability to 12,000 developers. Leveraging cloud-based Kubernetes platforms to ensure best operational outcomes the team is driven to enable this best practice capability across Fidelity. This capability is key to assisting the growth of both an inner-sourcing and open-sourcing culture throughout the firm.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://cdcon2020.sched.com/event/dqON/gitops-and-secrets-kara-de-la-marck-cloudbees&#34;&gt;GitOps and Secrets&lt;/a&gt;&lt;/strong&gt;
&lt;strong&gt;Speaker:&lt;/strong&gt; Kara de la Marck, CloudBees
&lt;strong&gt;Time:&lt;/strong&gt; 1:00 PM PDT&lt;/p&gt;
&lt;p&gt;GitOps uses Git as the “single source of truth” for declarative infrastructure and enables developers to manage infrastructure with the same Git pull requests they use to manage a codebase. Having all configuration files version-controlled by Git has many advantages, but best practices for securely managing secrets with GitOps remain contested. Join us in this presentation about GitOps and secret management. Attendees will learn about the pros and cons of various approaches and why the Jenkins X project has chosen to standardize on Kubernetes external secrets for secret management.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;&lt;a href=&#34;https://cdcon2020.sched.com/event/dpvT/kubernetes-chaos-engineering-with-chaos-toolkit-and-jenkins-x-viktor-farcic-cloudbees&#34;&gt;Kubernetes Chaos Engineering With Chaos Toolkit and Jenkins X&lt;/a&gt;&lt;/strong&gt;
&lt;strong&gt;Speaker:&lt;/strong&gt; Viktor Farcic, CloudBees
&lt;strong&gt;Time:&lt;/strong&gt; 3:15 PM PDT&lt;/p&gt;
&lt;p&gt;The only thing more satisfying than being able to destroy things without consequences is to be awarded for destruction. If you do have destructive tendencies, but you&amp;rsquo;d like to convert them into something positive, chaos engineering might be just the thing you need. We&amp;rsquo;ll explore through a hands-on demo on how to use Chaos Toolkit to define and run chaos experiments inside a Kubernetes cluster with Istio. We&amp;rsquo;ll see a few use-cases of potential problems that can be detected and solved. We&amp;rsquo;ll automate the deployment of chaos experiments using Jenkins X and make them an integral part of our continuous delivery pipelines.&lt;/p&gt;
&lt;h2 id=&#34;register-for-cdcon&#34;&gt;Register for CDCon&lt;/h2&gt;
&lt;p&gt;Don&amp;rsquo;t miss out on these great talks. &lt;a href=&#34;https://events.linuxfoundation.org/cdcon/&#34;&gt;Register for CDCon&lt;/a&gt; to attend.&lt;/p&gt;
&lt;p&gt;CDCon has pledged to donate 100% of the proceeds received from CDCon 2020 registration to charitable causes: Black Girls Code, Women Who Code and the CDF Diversity Fund. Registrants indicate which charitable fund they want their 25 USD registration fees to go to during registration. If you can’t afford the registration cost, please apply for the &lt;a href=&#34;https://events.linuxfoundation.org/cdcon/attend/scholarships/&#34;&gt;diversity scholarship&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;img src=&#34;https://jenkins-x.io/images/cdcon-register.png&#34; alt=&#34;CDCon Banner&#34;&gt;&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Welcome to Jenkins X 3.x alpha!</title>
      <link>https://jenkins-x.io/blog/2020/09/16/jx-v3-alpha/</link>
      <pubDate>Wed, 16 Sep 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/09/16/jx-v3-alpha/</guid>
      <description>
        
        
        &lt;p&gt;We are very pleased to announce the &lt;a href=&#34;https://jenkins-x.io/v3/&#34;&gt;alpha release of Jenkins X version 3&lt;/a&gt;&lt;/p&gt;
&lt;iframe style=&#34;border:none&#34; width=&#34;800&#34; height=&#34;450&#34; src=&#34;https://whimsical.com/embed/SnJBgXG6jz9pqQewiDTNRt@2Ux7TurymNDXVRa4FpLk&#34;&gt;&lt;/iframe&gt;
&lt;p&gt;You can read more about the &lt;a href=&#34;https://jenkins-x.io/v3/about/overview/&#34;&gt;overview of the architecture and components here&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;This release has lots of &lt;a href=&#34;https://jenkins-x.io/v3/about/benefits/&#34;&gt;benefits over version 2&lt;/a&gt; is much easier to use, understand and manage. It is more flexible and simpler to configure for different infrastructures and cloud providers.&lt;/p&gt;
&lt;p&gt;The new release works well with any combination of helm 3, helmfile, kpt and/or kustomize.&lt;/p&gt;
&lt;p&gt;For those who&amp;rsquo;ve used Jenkins X version 2 you can check out a &lt;a href=&#34;https://jenkins-x.io/v3/about/comparison/&#34;&gt;comparison of the two versions&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Here is a &lt;a href=&#34;https://www.youtube.com/watch?v=RYgKvRpjkoY&amp;amp;feature=youtu.be&#34;&gt;demo video showing how to get started with Jenkins X on Google Cloud with Terraform and Vault&lt;/a&gt;:&lt;/p&gt;
 &lt;iframe width=&#34;1292&#34; height=&#34;654&#34; src=&#34;https://www.youtube.com/embed/RYgKvRpjkoY&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;
&lt;p&gt;We also &lt;a href=&#34;https://www.youtube.com/watch?v=NZVp66YDl5s&#34;&gt;did a live demo of getting started and using version 3&lt;/a&gt; at the &lt;a href=&#34;https://octant.dev/community/&#34;&gt;octant office hours last week&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;We also included the &lt;a href=&#34;https://github.com/jenkins-x/enhancements/issues/38&#34;&gt;helmfile based preview environments enhancement&lt;/a&gt; via the new &lt;a href=&#34;https://github.com/jenkins-x/jx-preview&#34;&gt;jx-preview&lt;/a&gt; plugin which makes it much easier to make more sophisticated previews such as&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;using multiple namespaces for you previews&lt;/li&gt;
&lt;li&gt;using per preview namespaces or deploying previews into shared namespaces (e.g. via Canaries)&lt;/li&gt;
&lt;li&gt;using helmfile to cleanly remove resources&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We now have support, via Terraform for 2 of the big 3 public clouds:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/admin/platform/eks/&#34;&gt;Amazon&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/admin/platform/gke/&#34;&gt;Google&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Azure support is getting really close; if you&amp;rsquo;d like to help get it ready &lt;a href=&#34;https://jenkins-x.io/community/#slack&#34;&gt;join us on slack&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Also when using your laptop or local kubernetes cluster without terraform we support:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/admin/platform/minikube/&#34;&gt;Minikube&lt;/a&gt; so you can run Jenkins X on your laptop&lt;/li&gt;
&lt;li&gt;&lt;a href=&#34;https://jenkins-x.io/v3/admin/platforms/on-premises/&#34;&gt;On-Premises&lt;/a&gt; so you can use any vanilla kubernetes cluster&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We are working on improving the UX of the installation/upgrade; we&amp;rsquo;re hoping to soon have a pure terraform (or Terraform Cloud) way to spin up a Jenkins X installation on a public cloud with a minimum of fuss. We&amp;rsquo;ll hopefully blog about that soon&amp;hellip;&lt;/p&gt;
&lt;p&gt;So please take it for a spin and &lt;a href=&#34;https://jenkins-x.io/community/&#34;&gt;let us know what you think&lt;/a&gt;! If you can think of any ways we can improve let us know!&lt;/p&gt;

      </description>
    </item>
    
    <item>
      <title>Blog: Octant: the OSS UI for Jenkins X</title>
      <link>https://jenkins-x.io/blog/2020/08/06/octant-jx/</link>
      <pubDate>Thu, 06 Aug 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-x.io/blog/2020/08/06/octant-jx/</guid>
      <description>
        
        
        &lt;p&gt;A common question we have heard in the community over the years is &lt;a href=&#34;https://jenkins-x.io/docs/resources/faq/config/#is-there-a-ui-available-for-jenkins-x&#34;&gt;Is there an open source UI for Jenkins X?&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Well we now have an answer: its &lt;a href=&#34;https://github.com/vmware-tanzu/octant&#34;&gt;Octant&lt;/a&gt; using the &lt;a href=&#34;https://github.com/jenkins-x/octant-jx&#34;&gt;octant-jx&lt;/a&gt; plugin.&lt;/p&gt;
&lt;h2 id=&#34;why-octant&#34;&gt;Why Octant?&lt;/h2&gt;
&lt;p&gt;We love &lt;a href=&#34;https://github.com/vmware-tanzu/octant&#34;&gt;Octant&lt;/a&gt; because:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;open source and very easy to extend with plugins in Go or TypeScript/JavaScript&lt;/li&gt;
&lt;li&gt;lets you visualise and work with all kubernetes and custom resources across multiple clusters&lt;/li&gt;
&lt;li&gt;thanks to &lt;a href=&#34;https://github.com/jenkins-x/octant-jx&#34;&gt;octant-jx&lt;/a&gt;  has awesome integration with Jenkins X components like apps, environments, pipelines, repositories etc.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id=&#34;features&#34;&gt;Features&lt;/h2&gt;
&lt;p&gt;Longer term we&amp;rsquo;re planning on making most of the developer and operations features of Jenkins X available through the UI via &lt;a href=&#34;https://github.com/jenkins-x/octant-jx&#34;&gt;octant-jx&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;e.g. we hope as part of &lt;a href=&#34;https://github.com/jenkins-x/enhancements/issues/36&#34;&gt;Jenkins X 3.x&lt;/a&gt; you&amp;rsquo;ll be able to install or upgrade Jenkins X and watch the installation proceed all via Octant.&lt;/p&gt;
&lt;p&gt;But already right now today you can:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;view applications, environments, pipelines, repositories&lt;/li&gt;
&lt;li&gt;for a pipeline quickly navigate to:
&lt;ul&gt;
&lt;li&gt;its Pod, Log, Pull Request or Preview Environment&lt;/li&gt;
&lt;li&gt;for each step you can view the step detail or log of the step&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;li&gt;see the various jobs and pipelines used to operate Jenkins X itself&lt;/li&gt;
&lt;li&gt;over time will add management UI capabilities for installing, upgrading and administering Jenkins&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Find out &lt;a href=&#34;https://github.com/vmware-tanzu/octant#usage&#34;&gt;more about installing and using Octant here&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&#34;demo&#34;&gt;Demo&lt;/h2&gt;
&lt;p&gt;We did a &lt;a href=&#34;https://youtu.be/Njl247hjRuU?t=186&#34;&gt;demo of octant-jx&lt;/a&gt; at the last &lt;a href=&#34;https://jenkins-x.io/community/office_hours/&#34;&gt;office hours&lt;/a&gt;. We also &lt;a href=&#34;https://www.youtube.com/watch?v=Njl247hjRuU&amp;amp;t=2027s&#34;&gt;presented octant-jx&lt;/a&gt; at the &lt;a href=&#34;https://octant.dev/community/&#34;&gt;octant office hours this week&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;Here is a &lt;a href=&#34;https://www.youtube.com/watch?v=2LCPHi0BnUg&amp;amp;feature=youtu.be&#34;&gt;demo video showing octant in action with Jenkins X&lt;/a&gt;:&lt;/p&gt;
 &lt;iframe width=&#34;1292&#34; height=&#34;654&#34; src=&#34;https://www.youtube.com/embed/2LCPHi0BnUg&#34; frameborder=&#34;0&#34; allow=&#34;accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture&#34; allowfullscreen&gt;&lt;/iframe&gt;

      </description>
    </item>
    
  </channel>
</rss>