Category

Blog

What’s New in Tekton 0.9

By Blog
By Dan Lorenc
dlorenc@google.com
twitter.com/lorenc_dan


Another 6 weeks, another Tekton release. It’s mostly common knowledge that Tekton’s logo is a robot cat, but it’s lesser known that the releases are named after robots and cats! Each Tekton Pipelines release is given a codename of a type of cat followed by a famous robot.

On Monday, December 2nd, Andrea Frittoli of IBM cut the v0.9.0 release, dubbed “Bengal Bender”. This release contained commits from 21 different individuals. I wanted to take the time to highlight some of the new features and API changes, as well as to point out what much of the “under the covers” work is laying the groundwork for.

So let’s jump in!

New Features and Bug Fixes

“Bengal Bender” includes a solid set of features, bug fixes and performance improvements. Apologies if I missed anything here, this list is simply what I find most exciting.

Script mode!

https://github.com/tektoncd/pipeline/pull/1432

If you were at Kubecon San Diego you might have come away with the impression that Go is the language of the cloud. And while that is true to some extent, good old bash and yaml also play a huge part, especially when it comes to “glue” systems like delivery pipelines.

If you’ve spent much time working with containers, you’ve probably seen a yaml file with something like this in it:

- name: hello
  image: ubuntu
  command: ['bash']
  args:
  - -c
  - |
      set -ex
      echo "hello"

This is a lot of complicated boilerplate just to run a simple bash script inside a container. And if you’re not deeply familiar with how bash, shells, entrypoints and shebangs all work at the system level, this is a bit opaque. It’s also prone to subtle and confusing bugs. Even if you are familiar with these things, you’ve probably wasted time debugging issues when the shell in your container is set to something you’re not used to, or the entrypoint is overridden, or “bash -c” doesn’t do what you expect.

This makes delivery pipelines harder to write, understand and maintain.

Enter script mode! Inspired by some ideas from Ahmet Alp Balkan, Jason Hall put together a proposal to make it much easier to define tasks that just need to run a simple bash script. Here’s what it looks like:

- name: hello
  image: ubuntu
  script: |
    #!/bin/bash
    echo "hello"

You’ll notice that there are far fewer lines of boilerplate. No more need to specify args, an entrypoint or remember the tricky “-c” part. Just specify the interpreter you want to use and the commands to run. This has already let us simplify dozens of test cases and examples!

Performance

https://github.com/tektoncd/pipeline/pull/1545

Tekton has long suffered from poor performance around starting PipelineRuns. Christie Wilson and I did a debugging/coding session last spring to try to improve this, and identified PVC mounting as a major contributor. Unfortunately, our attempted fix didn’t work and needed to be rolled back.

A more general longer term fix is being handled by Scott Seaward and the re-resources effort, but I decided to take another stab at a short term fix. Fingers crossed that it works, but initial testing shows improvements of anywhere between 5 and 20 seconds per PipelineRun!

API Changes

There have been a few changes to the API as we start to firm things up for a beta release. We’re hoping to get the majority of these breaking changes in over the next few releases so users can start to build production systems on top of stable versions.

The breaking changes in v0.9.0 include:

Standardization of output paths for image digests

Tekton currently provides a mechanism to store the digests of container images built by Tasks. This mechanism predated the PipelineResource subsystem, and required Task authors to write these digests to a specific location at /builder/image-outputs. This change moves that to the standard path for output resources, at /workspace/output/<resource-name>.

Simplification of the cluster resource

Cluster PipelineResources make deploying and working with Kubernetes clusters from within Tasks simple. They provide mechanisms for users to declare where a cluster endpoint is and how to authenticate with it. Then, during Task execution, they automatically configure a .kubeconfig file so Kubernetes tooling can find that cluster. This release contained a few changes to make these cluster resources easier to work with.

Previously, users had to specify a name parameter twice: once in the resource name and once as a parameter to the resource. The second parameter has been removed.

Ground Work

Following the age-old programming advice above, most of the work contained in each Tekton release is in service of features that won’t be exposed until a later release. Digging into the commit log shows a detailed picture of what the community is working toward.

Here’s my editorialized version of what’s coming soon 🙂

Revamped PipelineResources

A lot of work went into cleaning up the existing PipelineResource subsystem, including the interface exposed to PipelineResource types and the types themselves. Getting these both solid will form the basis for the larger Re-resources effort, which is currently underway. This project will make the resource types extensible, allowing anyone to add and use their own types. It will also hopefully leave us with some embeddable components, so that other systems can make use of Tekton PipelineResources and the coming catalog.

API Versioning

One of the most important steps in shipping a stable API is figuring out how to make changes in a backwards compatible way. No API is perfect, so the ability to upgrade one is paramount. Vincent Demeester and his colleagues at Red Hat have been hard at work designing and implementing an API versioning system that will allow users to upgrade Tekton API versions without breaking existing workloads. This will be key to the coming beta release.

Wrapping Up

The Tekton project has been amazing to watch grow. This post only details the changes in the Tekton Pipelines release, but there has also been some awesome work done in the Triggers, CLI and Dashboard projects. Triggers now support out-of-the-box Github and Gitlab validation. The CLI has improved support for creating PipelineResources and starting Tasks interactively. Visualization is coming soon to the Dashboard! I’d like to thank everyone that has made Tekton what it is today.

The Tekton community has been hard at work shipping the right APIs and components to build cloud-native software delivery systems. If you’re using Tekton, or interested in learning more about Tekton, we’d love to hear from you. Please consider joining the community, becoming a Tekton Friend or contributing directly

Fujitsu Joins Continuous Delivery Foundation As Premier Member

By Announcement, Blog

Japanese Global 500 IT services provider committed to providing leadership, helping to further accelerate development of open source CI/CD tools and methodologies

San Francisco, December 4, 2019 – The Continuous Delivery Foundation (CDF), the vendor-neutral home for many of the fastest-growing projects for continuous delivery, today announced that Fujitsu has joined the CDF as a premier member.

Fujitsu joins CDF premier members such as Cloudbees, IBM, Google, CapitalOne, CircleCI, jFrog, Huawei, Netflix, and Salesforce in working together to make continuous delivery tools and processes as accessible and reliable as possible and to grow the overall ecosystem.

“We are pleased to join the CD Foundation. We have been involved in the development and deployment of CI/CD technologies for many years, and believe strengthening an overall structure for CI/CD governance and management directly benefits the overall industry, software developers, and Fujitsu customers worldwide,” said Katsuhisa Ohta, Director of SOFTWARE BUSINESS UNIT, Fujitsu. “The CD Foundation is the right type of organization to help steer the course of development in the continuous delivery space. We look forward to participating actively.”

Open source technologies such as Jenkins, JenkinsX, Spinnaker and Tekton, which are hosted by the CDF, help development teams from companies of all sizes and industries improve their speed and productivity when creating cloud-native, legacy infrastructure, mobile, IoT, and bare metal applications.

 “We’re thrilled to be working with Fujitsu as we aim to help enterprises worldwide accelerate the adoption of continuous delivery technologies and best practices as quickly and easily as possible,” said Dan Lopez, CDF program manager. “With containers, microservices and Kubernetes on the rise, Fujitsu and other CDF members have a key role to play in growing and sustaining the CI/CD ecosystem.”

Fujitsu is the leading Japanese information and communication technology (ICT) company, offering a full range of technology products, solutions, and services. Fujitsu is also an established leader in implementing continuous delivery practices and tools to empower development teams to achieve faster, more frequent release cycles. Fujitsu will help build industry specifications and guidance around pipelines, workflows and other CI/CD areas, as well as provide foundational support for CI/CD tools.

CDF members have hosted multiple Continuous Delivery events this year, including events co-located with KubeCon + CloudNativeCon + Open Source Summit China and the Continuous Delivery Summit, co-located during KubeCon + CloudNativeCon North America 2019.

Additional CDF Resources

About the Continuous Delivery Foundation

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. The Continuous Delivery Foundation (CDF) serves as the vendor-neutral home of many of the fastest-growing projects for continuous delivery, including Jenkins, Jenkins X, Tekton, and Spinnaker, as well as fosters collaboration between the industry’s top developers, end users and vendors to further continuous delivery best practices. The CDF is part of the Linux Foundation, a nonprofit organization. For more information about the CDF, please visit https://cd.foundation.

###

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

A View from CD Summit and KubeCon: The CD Foundation Begins to Build a Community

By Blog

By Tracy Ragan, CEO DeployHub, CD Foundation Board Member, November 21st, 2019

CD Summit and KubeCon are over. As I sit here at our booth on the last day of KubeCon 2019, I reflect on the great work the CD Foundation (CDF) has done to begin building a community of Continuous Delivery experts and users. We have had an amazing week and must give a shout out of thanks to our ‘big brother’ the CNCF for providing a co-located even for our first North American CD Summit.

In case you were not able to attend this truly amazing conference, let me update you on the week of work and fun. 

We started Monday morning with the first North American CD Summit. We released a press announcement that covered our current progress around building community and adding new members. From there we began to see our conference room begin to fill-up. At one point during the morning, Tracy Miranda, conference MC, had to ask us to shift seats to make sure everyone had a place to sit down as there were so many people standing in the back of the room. As I was the front row, I had no idea what was occurring behind me. Our first North American CD Summit had sold out.

Sweeeeet!

So facing a sold out day everyone knew they had to bring their ‘A-game’ to the show. We had some truly amazing presentations by end users, member companies, CDF Board members and experts. After a full day of presentations, the room was still full with only a few empty seats. In other words, everyone stayed for the full CD Summit. 

We ended the evening with a party hosted by JFRog, WhiteSoure, DeployHub and Puppet. And what a great time we had. Open bar, table topics to stimulate conversation, cheese board and raffle prizes. CD Summit attendees like to party. 

And then we got to work. The Budget Committee, Strategy Committee and the Outreach Committee had their first face-to-face working sessions. We got to meet the new Director of Ecosystems, Jacqueline Salinas. A focus around interoperability was reinforced as a primary talking point. We have started to further clarify and implement the CD Foundation’s Governing Board 9 Strategic Goals for 2020.

Overall, it was a powerful CD Summit and a great way to end 2019, even though there is yet one more event to attend, DevOps World in Lisbon Portugal. Have a fun week in Lisbon if you lucky enough to attend that event. And we will see the rest of you at your next local CD Foundation Meetup.

Broader Scope for Meetups, More Opportunities for You to Get Involved!

By Blog

By Jacqueline Salinas, Director of Ecosystem

The CD Foundation (CDF) and premier member Cloudbees are announcing the transition of Jenkins Area Meetups (JAMs) to CI/CD Meetups. This is an important change. Under the CDF umbrella, the CI/CD community will be able to cover a broader range of topics and technologies that will include Spinnaker, Tekton, or general CI/CD. Our goal for this transition is to grow and foster collaboration within the CI/CD community.

How Do I Get Involved?

Want to join an existing meetup? There are over 106 groups in 39 countries with a total of over 34,000 members, find one near you: https://www.meetup.com/pro/cicd-cdf

Want to start a meetup? Drop me a line, I’d love to hear your idea: jsalinas@contractor.linuxfoundation.org

Thank you!

I just want to express my gratitude to the open source community. The Continuous Delivery Foundation (CDF) would not be here about to host our first North America CD Summit on November 18th at Kubecon 2019 San Diego without your contributions. 

Since the launch of the CD Foundation in March of 2019 our charter has been to serve as the vendor-neutral home for the most important open source projects for continuous delivery and specifications to expedite the release pipeline process. The first projects to be hosted by the CDF include Jenkins, Jenkins X, Spinnaker, and Tekton. Our goal at the CDF is to help facilitate an open governance model that encourages participation and technical contribution from the community. The CDF will provide a framework for long-term stewardship and sustainability for CI/CD tools part of the foundation. 

Our first step towards this was to ask the existing JAMs organizers to work with us to transition the Jenkins Meetup Pro account to CDF. This means each meetup organizer has more tools and options within meetup.com for organizing meetups and connecting with their local community. You can create customized mailing lists, integrate with Mailchimp, and track the growth of members and RSVPs over time. The overall Meetup Pro account has been rebranded to CDF. JAM organizers are welcomed to transition their meetup to CI/CD to include all four projects, but by no means are they under any obligation to do so. 

We cannot wait to see our community grow and what 2020 has to offer!

Thanks!

Jacqueline Salinas, Director of Ecosystem

A Year of Tekton

By Blog

Author: Dan Lorenc (dlorenc@google.com, twitter.com/lorenc_dan, github.com/dlorenc)

Last year at Kubecon Seattle, Tekton was just an idea in the heads of a few people, and a bit of code inside knative/build-pipeline. Fast forward to today, and we have a thriving community, independent governance inside a great foundation, and we’re quickly approaching our beta release! This year has flown by, so I wanted to highlight some of the original goals of the Tekton project, and some of the milestones we’ve hit toward them.

The Start

When Christie, Jason and I started sketching out the original Tekton APIs on a whiteboard in San Francisco, we had a straightforward goal in mind: make the hard parts of building CI/CD systems easy. There are already dozens of CI/CD systems designed to run on kubernetes, and for the most part they all have to build the same basic infrastructure before they can start solving customer problems. Kubernetes makes scheduling, orchestration and infrastructure management easier than anyone could have imagined, but it still leaves users with a few pieces to assemble before they can use it as an application delivery platform.

These were some of the original whiteboard sketches on what later became the Tekton Pipeline CRD.

Things like basic DAG orchestration, artifact management, and even reliable log storage are outside the bounds of the core Kubernetes APIs. Our plan was to use the new Custom Resource Definition feature to try to define a few more “nouns”, on top of the existing Kubernetes primitives, that were better suited for Continuous Delivery workloads. In doing so, we would make it easier for people and trans to create delivery systems designed for their exact use cases, while making sure the underlying primitives allowed for some degree of compatibility.

Vague ideas are great, but it’s much more productive to collaborate with others when you have something concrete to share and get feedback on. So in August of 2018, we released the sketch and principles we used to design it on knative-dev and to a few other interested parties. The feedback was amazing. The core pipeline team on Jenkins at Cloudbees jumped in with some hard earned lessons from their experience working on the most widely used orchestration system in history. The Concourse team at Pivotal helped redesign our extensibility system based on what they learned from the successful Concourse resource model.

Then we got to work building it all out! Our goal must have really resonated with others, because we could really feel the power of open source from day one. Even when there were only a few of us working together at Google, we were part of a much larger effort. We really wouldn’t be here today without the help of our contributors, maintainers and governing committee members.

A New Home

Around the time we prepared for our first release, it started to become obvious that Tekton (then called knative/build-pipeline) needed its own home. The knative brand and community helped immensely, but Tekton was meant to provide CI/CD for everyone – not just serverless or even kubernetes users. So in February of 2019, we decided to split out the project, name it “Tekton” and donate it to the newly-forming Continuous Delivery Foundation just in time for the 0.1.0 release. 

Kim Lewandowski announcing Tekton at the Open Source Leadership Summit

Open source, governance, and communities are hard. The move out of knative and into a new foundation was a big change for the project, but has proven worth the effort! Tekton still works great with other knative components, but has had the chance to grow its own community and evolve to a spot that its users need. Thanks to the community, Tekton has expanded into multiple projects like the Dashboard and CLI, and in Tekton Pipelines we have been so lucky to gain the expertise of folks like Vincent Demeester and Andrea Frittoli.

The rest of this year has felt like a blur, but I wanted to call out some major milestones we hit:

  • March – The first Tekton Pipelines release (v0.2.0) using Tekton itself!
  • June – First release of the Tekton CLI!
  • July – The first Tekton Pipelines release (v0.5.0) by a community member not at Google!
  • July – Tekton Friends repo created! 
  • August – First release of the Tekton Dashboard!
  • September – First Triggers release!
  • October – Tekton passed 100 contributors in October!

What’s Coming Next?

We’re rapidly approaching the first Tekton beta release! As part of this effort, we evaluated our API surface and identified quite a few areas that need hardening. This includes finishing up the table-stakes requirements for a CI/CD platform – things like triggers, metadata storage and building up our catalog. The Triggers v0.1.0 release has made Tekton usable in so many new ways, and we’re just getting started there still! 

Scott Seaward has has just started work on refactoring PipelineResources into an extensible system that will form the basis for the Tekton catalog, and Jason Hall is working on a metadata storage system that will help power some new ideas around software supply chain management.

If you’d like to get involved in the Tekton project, you can find us on Github, Slack or our email list . We’ll also be at Kubecon next week! Come attend one of the many sessions or the CD Summit. Here’s to Tekton in 2020!

How do we measure the growth of CD Foundation projects and their communities?

By Blog

Written by Tracy Miranda, CloudBees director of open source community and member of the CDF governing board

The CD Foundation (CDF) recently shared its 9 Strategic Goals. The second on the list is “Cultivate Growth of Projects.” This goal naturally leads us to ask ourselves the question: how do we measure the growth of our projects to know we are being successful?

There are many dimensions to open source projects. In order to sustain a project much more than code is required. The CDF helps with multiple essential services for project growth and sustenance. One of my favourite services is the CDF devstats site, which provides a wealth of data around the projects. CDF devstats, which is based on the CNCF devstats, gives indicators on community health and contributor statistics. 

Example from Tekton, one of many dashboards and data sets available:

Sometimes we have distorted views of how well projects are doing – this can be down to a few things such as hype or public sentiment around a project. Sometimes newer projects are viewed as doing better than older projects. It is important to have a sense of how well your project is doing. While there are lots of different ways to do it, one method I really like is looking at the number of individual developers contributing to a project. 

With CDF devstats I am able to take a snapshot of that data, and then see how the CDF projects stacked up against CNCF graduated projects. 

The chart here shows a visualization of average developer contributions to each project based on data from the past one year. There are many caveats with the data. E.g. Which repos are included for each project may not be strictly equivalent. But what I like about it is that at a high level it gives an indication of the size of project contributions and how projects compare relatively. 

I also like that it is all open – so you can verify the data and process  for yourself, plus do your own analysis. 

Kubernetes, as you might expect,  is a powerhouse of a project with thousands of contributors. But actually Jenkins stacks up nicely in comparison with a healthy number of contributions – which is all the more significant considering it is a 15 year old project. Sustaining and growing community contributions year-on-year for 15 years is an incredible achievement. The other CDF projects, Spinnaker, Jenkins X and Tekton, are much newer but also coming along quite nicely. See this repo for links to data. 

For me this is a nice snapshot to say we’re off to a good start here at CDF. Individual project growth will come down to each project’s community – but CDF will be working to provide key services and some of the less fun grunt stuff so project leaders can better focus on the important efforts of community building.

The CD Interactive Landscape is Live

By Blog

By Tracy Ragan, CEO DeployHub, Inc. and CDF Board Member

Good news!  The CD Interactive Landscape has been made public by the CD Foundation. You can find it at https://landscape.cd.foundation/.

What is an interactive landscape? The concept started when the CNCF began the process of cataloging different types of tools for building out a cloud native architecture. This led to the creation of the CNCF Interactive Landscape.  Turns out this tool became very helpful to all of us sorting out this new and exciting modern architecture. In the interest of providing a similar reference, the CD Foundation defined their own version of the interactive landscape to help clarify the tools needed to adopt a fully automated CD process.

Who is the CD Foundation?  The CD Foundation (CDF) serves as the vendor-neutral home for many of the fastest-growing projects for continuous integration and continuous delivery. The concept of the CDF was started by CloudBees and quickly accepted by thought leadership companies such as Google, CapitalOne, CircleCI, JFrog, IBM, Netflix, Salesforce, Huawei, DeployHub, Armory, WhiteSource, GitLab and others. 

Why is the CD Interactive Landscape important?  In today’s hybrid environment of both legacy and modern development platforms, there are hundreds of tools that help streamline the movement of code from development through production. There is a misconception that there is such a thing as a continuous delivery solution.  However, according to the CDF, CD is defined as:

“CD is a software engineering approach in which teams produce software in short cycles, ensuring that it can be reliably released at any time. The rise of microservices and cloud native architectures has caused a corollary rise in continuous delivery practices. This is related to CI/CD that includes Continuous Integration (CI) — the practice of merging all developer working copies to a shared mainline several times a day.”

One of the primary goals of the CDF is to help drive the adoption of this practice. The practice relies on a set of tools to orchestrate, automate, configure, track and secure the Continuous Delivery approach. The CD Interactive Landscape is a tool for understanding the roles of each solution as defined by their core competency.

The CD Interactive Landscape is not a static document.  It is intended to be expanded upon by the community of open source projects and commercial solutions that make continuous delivery possible.

This first version of the Landscape was created by members of the CDF and reviewed by the CDF Technical Oversight Committee (TOC) led by Kohsuke Kawaguchi – the creator of Jenkins and JenkinsX. This is not the end of our story. We are asking that the broader community, members and non-members of the CDF, begin updating the CD Interactive Landscape with new sections and tools, or even correct where a solution fits in – we could have gotten this wrong and apologize in advance if we did.

The guidelines and directions for updating the landscape can be found at: https://github.com/cdfoundation/cdf-landscape.

For a deeper dive on the landscape, view my presentation from CD Summit/KubeCon2019

CD Foundation’s Governing Board Unveils 9 Strategic Goals

By Blog

Written by Tracy Miranda, CloudBees director of open source community and member of the CDF governing board

The CD Foundation is about 6 months old and many of the early days have been spent discussing where we will as a community focus our efforts over the next year. CDF is in a unique position as a vendor-neutral body at the heart of an industry rapidly figuring out how to deliver software better and faster. With that in mind it was important to the governing board to come up with specific goals where we should focus our efforts. 

The CD Foundation governing board went through a very collaborative process to figure out what these should be. This included speaking to those who already have a lot of experience in the CI/CD space. A personal highlight of the process for me was a face-to-face at DevOps World where we had the honor of getting feedback from Jez Humble, co-author of the Continuous Delivery Book itself and Jayne Groll, Head of the DevOps Institute.

jenkins world
CDF Board Brainstorm session at DevOps World | Jenkins World August 2019 (Photo credit: Tara Hernandez)

After many discussions, the Governing Board agreed and ratified the goals in early October. Here is the list of the 9 strategic goals that will map to specific initiatives in our program plan for 2019/2020.

  1. Drive continuous delivery adoption
  2. Cultivate growth & adoption of CDF projects
  3. Foster tool interoperability
  4. Champion diversity & inclusion in our communities
  5. Foster community relations
  6. Grow the membership base
  7. Create value for all members
  8. Promote security as a first class citizen
  9. Expand into emerging technology areas

These goals are shared in no particular order or ranking. These goals are also not static every year and meant to evolve over time with input from the community. There is a lot to say about each goal including why each one matters, not just to the foundation but also to the wider CI/CD community. Over the next few weeks I will share a post on each goal and go into the why, what, how, where & who. Plus I’ll also share details of how you can join in to help us meet those goals! 

Get involved with the CD Foundation!

Memberships:
Membership Inquiries

Project Questions:
info@cd.foundation

PR/Events:
pr@cd.foundation

Newsletter:
Stay Connected

Twitter:
@CDeliveryFdn

CD Foundation is participating in Outreachy!

By Blog

Outreachy is a program for open source internships that specifically targets people in demographics that are underrepresented in tech. Since 2010 Outreachy has had over 400 participants making contributions to open source projects. Outreachy is one of the most effective programs for improving the diversity of open source communities. For those familiar with Google Summer of Code, Outreachy follows a very similar format. 

The Continuous Delivery Foundation is a neutral home for the next generation of continuous delivery collaboration. We know that the greater number of diverse voices we have collaborating, the more effective we are as a community. Which is why we are thrilled to be participating in Outreachy for this upcoming round. 

Three of the CD Foundation projects: Jenkins, Jenkins X and Tekton are offering Outreachy internship projects. The Jenkins project has participated in the previous 2 rounds of Outreachy, having a total of 4 Outreachy interns working with the community on the Jenkins Audit Log Plugin. Jenkins mentor Matt Sicker shares in this post “Outreachy has helped open my eyes to the struggles that developers from around the world are dealing with which can be improved upon to help expand our communities. For example, many countries do not have reliable internet or electricity, so the use of synchronous videoconferencing and other heavyweight, synchronous processes common to more corporate-style development are inadequate in this international context.”

In that way Outreachy is also beneficial to the mentors participating. The actual tech contributions are a bonus side effect. Jenkins participates in the program with no expectation that the interns remain part of the community – but takes a wider, long term view that this generally improves open source and tech communities as a whole. Tracy Miranda, Outreachy coordinator for the Jenkins project says “As of this year I know of 2 Outreachy alumni (non-Jenkins projects) who were hired by my employer and both mention the Outreachy program as an important stepping stone in their career journeys.”

Here are the details of this round’s CD Foundation projects which we are looking for interns for. Please help us spread the word. 

Jenkins

Jenkins X

Tekton

Kara de la Marck, the Jenkins X Outreachy coordinator can personally speak to the benefits of the program: “Outreachy is a fantastic mentoring program that helps to onboard new contributors to a project and to open source more generally. Many participants go on to become long term contributors to open source. As an alumna, I have carried forward a deep appreciation of open source as an enabler of global collaboration, technological innovation, and community. I’m incredibly happy to welcome Outreachy participants to Jenkins X.”

Please help us spread the word, and we look forward to working with Outreachy interns and welcoming them into our community.

Announcing the CDF Security SIG

By Blog

By Kay Williams

Security SIG Chair

10/4/2019

Hey everyone, I am excited to announce the formation of the Security SIG –  the CD Foundation’s first Special Interest Group (SIG)! The Security SIG began as a lightning talk at the first CD Summit in Barcelona this past May, and progressed to a formal proposal in August. In September it was adopted by the Technical Operating Committee (TOC).

The charter for the Security SIG is to provide a neutral home for discussion around designs, specifications, code and processes to enable security across the software supply chain. Topics of interest include the following:

  • Observability – enabling actions performed while writing code, compiling, testing, and distributing software to be manifest and verifiable.
  • Policy – enabling consumers of software to specify and implement policy over consumed software.
  • Inventory – enabling administrators to inventory and audit software used within their organizations.
  • Runtime Security– enabling detection and prevention of software tampering at runtime.
  • Vulnerability Communication – providing mechanisms for breaches in the integrity of software to be communicated and remediated.
  • Vulnerability Recovery – providing mechanisms for consumers to recover from compromised or untrusted software.

Membership in the Security SIG is open to the public. Here are some details:

Communication

Meetings

All are welcome to join the mailing list and attend meetings. We look forward to building a more secure future together!

Sincerely,

Kay