Skip to main content
search
Category

Blog

Apr 21
Love0

New Chair of CD Foundation Governing Board Elected

By Announcement, Blog

Tracy Miranda, Director of Open Source Community at CloudBees, has been elected as chair of the CD Foundation Governing Board. CloudBees is a Premier Member of the CD Foundation, and Tracy has been deeply involved in CD Foundation activities over the past year, serving on the Governing Board, helping craft the 9 Strategic Goals of the foundation, and participating in CD Foundation events around the globe. 

“I’m excited and honoured to be elected chair of the CD Foundation governing board. I join all CDF members in expressing sincere thanks to Kim Lewandowski for great progress in our first 12 months. Recent global events highlight how continuous software delivery is critical to every industry. The CDF will increasingly drive many key initiatives in this space, and I am excited to work with CDF members and the broader CI/CD community to pursue the CDF’s 9 Strategic Goals and move the CDF forward.”

The CD Foundation Governing Board raises, budgets and spends funds in support of CI/CD open source and standards projects. According to the CD Foundation, the Chair is responsible for the overall management of the foundation’s budget, and “will preside over meetings of the Governing Board, manage any day-to-day operational decisions, and will submit minutes for Governing Board approval.” The full charter is available here.

Tracy succeeds Kim Lewandowski, Product Manager at Google, who served as the CD Foundation’s first Governing Board chair.

Tracy Miranda Bio

Tracy is director of open source community at CloudBees, where she works closely with the Jenkins and Jenkins X communities. A developer and open source veteran, besides her work with the CD Foundation, Tracy is on the board of directors for the Eclipse Foundation. Tracy has a background in electronics system design and holds patents for her work on processor architectures. She writes for JAXenter.com and Opensource.com on tech, open source, and diversity.

More CD Foundation Resources

To keep up-to-date, sign up for our newsletter and join us in 2020 as we continue to grow and advance CI/CD in the industry!

Apr 21
Love0

New Chair of CD Foundation Technical Oversight Committee Elected

By Announcement, Blog

We are excited to announce that Dan Lorenc has been elected the CDF Technical Oversight Committee (TOC) Chairperson.

The TOC is responsible for the overall technical management of CDF projects, ultimately managing and guiding project technical infrastructure. Dan’s election to the TOC chairperson role is a recognition of his substantial contributions to the OSS community. These contributions include ongoing TOC leadership, numerous insightful posts on the CDF blog,  active participation in CDF SIGs and general leadership in the community.

Dan Lorenc said, “I’m humbled and excited to be elected as TOC Chair. We have an amazing opportunity to make it easier for the industry to adopt secure, safe and productive Continuous Delivery tools and practices. I look forward to working with the rest of the CDF community this year! I’d like to thank Kohsuke again for his hard work on Jenkins and in the CDF. I wish him the best of luck in his new adventure!”

As the TOC chairperson, Dan will continue to be a strong voice representing the perspectives of the broader CDF technical community, especially to the governing board. The CDF is excited to see him continue to help make CDF the definitive destination for the continuous delivery ecosystem.

For more information on CDF’s TOC leadership, please see here, or reach out to us.

Dan Lorenc Bio

Dan Lorenc is a Staff Software Engineer at Google, where he’s been working in the PAAS-space for 6 years. He currently manages a team focused on building open source tools to improve the container/Kubernetes developer experience. Previously he founded projects such as Minikube, Skaffold and Kaniko.

More CD Foundation Resources

To keep up-to-date, sign up for our newsletter and join us in 2020 as we continue to grow and advance CI/CD in the industry!

Apr 20
Love0

From IBM – Build and Deliver Using Tekton-Enabled Pipelines

By Blog, Member

Originally posted to the IBM blog by Jerh O’Connor

We are delighted to announce the addition of the industry-leading Tekton capability to IBM Cloud Continuous Delivery pipelines.

With this new type of Continuous Delivery Pipeline, you define your pipeline as code using Tekton resource YAML stored in a Git repository. This lets you version and share your pipeline definitions while allowing you to configure, run, and view pipeline output in the familiar IBM Cloud Continuous Delivery DevOps experience.

Tekton Pipelines is an open source project, born out of Knative Build, that you can use to configure and run continuous integration/continuous delivery (CI/CD) pipelines within a Kubernetes cluster.

Tekton Pipelines are cloud native and run on Kubernetes using custom resource definitions specialized for executing CI/CD workflows. The Tekton Pipelines project is new and evolving and has support and active commitment from leading technology companies, including IBM, Red Hat, Google, and CloudBees. 

For a closer look at Tekton, see our video “What is Tekton?”:06:49

What is Tekton?

In addition to the benefits of Tekton, this new capability in IBM Continuous Delivery provides the following unique features:

  • A dashboard to easily view in-flight and completed Pipeline Run information
  • Manual and Git triggering support
  • Integration into the rich Open Toolchain ecosystem of integrations
Delivery Pipeline Tekton Dashboard

How to get started

Getting started with CD Tekton-enabled pipelines requires a little setup. You will need the following:

Once you have these pieces in place, you need to configure the Tekton Pipeline to enable the running of your pipeline.

Click on the Tekton Pipeline tile on your toolchain dashboard to be taken to the configuration screen, where you will see notifications on what remains to be configured to use this new pipeline technology:

Click on the Tekton Pipeline tile on your toolchain dashboard to be taken to the configuration screen, where you will see notifications on what remains to be configured to use this new pipeline technology:

Select the required values in the Definitions tab, select your private worker in the Worker tab, and click Save.

You now need to set some trigger mappings via the Triggers tab so you can run the pipeline.

The simplest trigger is a manual trigger where you kick off a run yourself from the dashboard. You can also create Git triggers that fire based on git push and pull events as needed.

CD Tekton-enabled pipelines also provide a means of externalising reusable properties and provide a simple, secure method for storing sensitive information like apikeys via the Environment Properties tab.

Once the setup has been completed, the new Tekton Dashboard automatically updates to show information on in-flight and completed Pipeline Runs, showing the status of these runs and allowing the cancellation and deletion of runs.

In all cases, you can dig deeper into the logs and see the output of each Tekton Task and Step in the selected Pipeline run.

dp4

Caution: The Tekton Pipelines project is still in alpha and being actively developed. It is very likely that you will need to make changes to your pipeline definitions as the project continues to evolve

Watch the demo

Watch this short companion video for a demo of using our sample Tekton pipeline in IBM Cloud.

Contact

Now you can try it out yourself. For more information, see our documentation. If you have questions, engage our team via Slack by registering here and join the discussion in the #ask-your-question channel on our public Cloud DevOps @ IBM Slack.

We’d love to hear your feedback.

Learn more about Tekton by reading “Tekton: A Modern Approach to Continuous Delivery.”

Apr 20
Love0

From Jenkins X – Asking and Finding Help: Outreachy

By Blog, Project

Originally posted on the Jenkinx X blog by Neha Gupta

Neha Gupta is adding support for Kustomize in Jenkins X, to enable Kubernetes native configuration management, while participating in Outreachy from December 2019 to March 2020.

Outreachy open-source contribution for applicants — Asking/Finding help

This blog might be helpful for beginners who are fear-stricken or I would say hesitant to ASK, to get lost in the new world while trying to understand any open source project, fear of asking questions that may sound stupid later on or are very obvious! First of all.. Relax!

  • Everyone starts from somewhere and has a learning curve!..
  • There are some pre-requisites that may help you get into open-source development better..
  • Learn basics of git operations. (https://learngitbranching.js.org , I find this easy and helpful).
  • Try to find an open-source project (remember : you’re going to contribute to a part of it, so it’s okay if some/many things doesn’t make sense in the beginning, because it’s easier to write code than to understand someone else’s code).
  • For selecting a project you may also look for Google-Summer-of-Code, Outreachy, Google-Code-In, RSoC and other open-source programs and their organisations that helps people/students/aspiring developers to find your best interest communities and projects.

NOTE : Beware! seeing too many organisations and projects will only confuse you, so start with only one or max 2 projects, try to deep-dive and focus on them.

After selecting the project :

  • Connect with the community through their communication channels for both developers and users (example : Slack, IRC-Cloud, Zulip, Riot etc )
  • Try to read the documentation and understand the overall structure and purpose of the project you’re starting to work on.
  • If you don’t understand something functionality wise — just ask! Ask on the communication channel.
  • If you are facing any error — Google search it, or try to look into the existing issues, if you’re not able to move forward and you’re stuck on the same error for more than 45 mins, just ask! Trust me! There’s no harm. In-fact, people of open-source communities appreciate it, feels motivated when there are users asking them about something that they’re passionately building. It also sometimes, helps the community to re-define and re-align the product and some features.

Happy learning! 🙂

Apr 20
Love0

From Jenkins X – Outreachy: Motivation to apply!

By Blog, Project

Originally posted on the Jenkins X blog by Neha Gupta

Neha Gupta is adding support for Kustomize in Jenkins X, to enable Kubernetes native configuration management, while participating in Outreachy from December 2019 to March 2020.

Motivation to apply to Outreachy:

In my graduation class of fifty people we were three girls struggling to set up our space and comfort with the weird reactions we got from fellow students for trying to understand technology. When my professor asked us to make an autonomous drone. I couldn’t make one, I was shattered, until a friend from computer science batch helped me make one. He showed me some of the cool apps he made, that sparked an interest, and I started building apps, realising that computer science is beyond just coding, it’s more about solving real life problems.

I’ve transitioned from mobile to web apps, server-end development, robotics, cloud architecting, and also cofounding a startup. I’ve been focusing on using AI to make smarter apps, and help students think beyond, and see the bigger picture. I’m hoping to start an accelerator, regulating the perception about technology, focusing especially on hidden potential behind fear-stricken girls.

When I heard about Outreachy program and I liked how women and other minority communities are being supported and motivated. It felt something similar to what I’m trying to do with the young girls around me (breaking the stereotypical phenomenon of “girls can’t code”). I felt participating in Outreachy will not only boost my but other girls motivation too! and it’ll also definitely help me grow technologically, socially and mentally.

Why excited about Outreachy?

To me it feels really cool to work with a team remotely. The interactions, networking and feel is completely different, especially when it’s open-source (Like ..I get anxious before asking questions on public channels, if the question is too logical and stupid). Also, I’m a fan of open-source contributions, so… (here was the chance).

Another reason was to interact with the minority community (people who are facing similar issues in STEM like me) and share some instances with them, be on the same page, enlighten and get enlightened (all that networking sounds fun..). I am also excited about the trip. Why Jenkins-X?

The Cloud Storage backed Helm repository idea seemed interesting, so I started exploring it. The project was also quite different from other listed (maybe because it was meant for me 😀 ), I only contributed to it and focused on it.

Also the community was very welcoming and communications with my mentor were good. He helped me making contributions to the project, he guided me to some good first issues, helped me correct my PR’s. Jenkins-X looked as an interesting open-source project so I’m glad I tried to be a part of it and got selected.

What would I tell someone who is worried about applying to Outreachy?

If you are someone who has just started open source contributions and are fear stricken on how is it gonna work? These all things seems so confusing and you’re overwhelmed.

Don’t worry! ..

I was too! Every one is.. and this is just step — 1. Anyone who’s going to pick up a new project which is production ready and thousands/millions of people are using it, is going to be confused! This is normal and natural (the initial learning curve), but once you overcome it. Things become so normal and understanding, people are here to help you out.

If you think you can’t make it because of the competition, how does matter? If not this time, next time (I myself got selected after 3 years of trying), you anyway has to start one day, so let it be today. But the learnings you take away from the process, are insanely valuable and every-time it’s gonna become easier.. Feel free to reach me if you are facing any issues regarding starting with open-source contributions or if you have question saying — shall I apply to Outreachy this time?

Good Luck! 🙂

Apr 17
Love0

From Jenkins – WebSocket

By Blog, Project

Originally posted on the Jenkins blog by Jesse Glick

I am happy to report that JEP-222 has landed in Jenkins weeklies, starting in 2.217. This improvement brings experimental WebSocket support to Jenkins, available when connecting inbound agents or when running the CLI. The WebSocket protocol allows bidirectional, streaming communication over an HTTP(S) port.

While many users of Jenkins could benefit, implementing this system was particularly important for CloudBees because of how CloudBees Core on modern cloud platforms (i.e., running on Kubernetes) configures networking. When an administrator wishes to connect an inbound (formerly known as “JNLP”) external agent to a Jenkins master, such as a Windows virtual machine running outside the cluster and using the agent service wrapper, until now the only option was to use a special TCP port. This port needed to be opened to external traffic using low-level network configuration. For example, users of the nginx ingress controller would need to proxy a separate external port for each Jenkins service in the cluster. The instructions to do this are complex and hard to troubleshoot.

Using WebSocket, inbound agents can now be connected much more simply when a reverse proxy is present: if the HTTP(S) port is already serving traffic, most proxies will allow WebSocket connections with no additional configuration. The WebSocket mode can be enabled in agent configuration, and support for pod-based agents in the Kubernetes plugin is coming soon. You will need an agent version 4.0 or later, which is bundled with Jenkins in the usual way (Docker images with this version are coming soon).

Another part of Jenkins that was troublesome for reverse proxy users was the CLI. Besides the SSH protocol on port 22, which again was a hassle to open from the outside, the CLI already had the ability to use HTTP(S) transport. Unfortunately the trick used to implement that confused some proxies and was not very portable. Jenkins 2.217 offers a new -webSocket CLI mode which should avoid these issues; again you will need to download a new version of jenkins-cli.jar to use this mode.

The WebSocket code has been tested against a sample of Kubernetes implementations (including OpenShift), but it is likely that some bugs and limitations remain, and scalability of agents under heavy build loads has not yet been tested. Treat this feature as beta quality for now and let us know how it works!

Apr 17
Love0

From Jenkins – Atlassian’s new Bitbucket Server integration for Jenkins

By Blog, Project

Originally posted on the Jenkins blog by Daniel Kjellin

We know that for many of our customers Jenkins is incredibly important and its integration with Bitbucket Server is a key part of their development workflow. Unfortunately, we also know that integrating Bitbucket Server with Jenkins wasn’t always easy – it may have required multiple plugins and considerable time. That’s why earlier this year we set out to change this. We began building our own integration, and we’re proud to announce that v1.0 is out.

The new Bitbucket Server integration for Jenkins plugin, which is built and supported by Atlassian, is the easiest way to link Jenkins with Bitbucket Server. It streamlines the entire set-up process, from creating a webhook to trigger builds in Jenkins, to posting build statuses back to Bitbucket Server. It also supports smart mirroring and lets Jenkins clone from mirrors to free up valuable resources on your primary server.

Our plugin is available to install through Jenkins now. Watch this video to find out how, or read the BitBucket Server solution page to learn more about it.

Once you’ve tried it out we’d love to hear any feedback you have. To share it with us, visit https://issues.jenkins-ci.org and create an issue using the component atlassian-bitbucket-server-integration-plugin.

Apr 16
Love0

Introducing our newest CDF Ambassador – Marky Jackson

By Blog, Staff

Hello friends! I am Marky Jackson and I am so thrilled to be one of the newest CDF ambassadors.

I have been involved in open source for many years but my start in the world was rather rocky. I had a difficult childhood. I was shuffled from one boys’ home to another and had little control over my life. But I was tough and smart, and I emancipated at an early age, which allowed me to start living the way I wanted while I was still in my teens.

I studied computer science at UCLA and MIT and then spent 14 months as an intern at Jasmine Multimedia Publishing before joining companies such as Yahoo, AT&T, HP, Symantec and more.

I am extremely excited to be a part of this program because I get to make people smile by mentoring and being positive. I love public speaking, doing a meetup in person or virtual and helping people online. I get joy when a person gets involved in the open-source community.

The open source community is all about inclusion. We welcome people to contribute, and we try to express our gratitude for their hard work. The sense of unity and belonging is second to none with developers, coders, and engineers from around the world collaborating to advance our industry.

It takes a lot of time and effort to keep the open-source community going. Most of us are working after-hours to get things done, and we need help—lots of help. People think that you have to be an expert coder to join us, but that’s not true. There are plenty of ways to take part in. You can contribute error reports, write technical documentation, or even sponsor an application. There are plenty of ways to offer support. Just ask what you can do.

I look forward to meeting everyone and collaborating! You can find me at
@markyjackson5 on Twitter.

Apr 09
Love0

Screwdriver: Introducing Queue Service

By Blog, Project
Introducing Queue Service

Pritam Paul, Software Engineer, Verizon Media

We have recently made changes to the underlying Screwdriver Architecture for build processing. Previously, the executor-queue was tightly-coupled to the SD API and worked by constantly polling for messages at specific intervals. Due to this design, the queue would block API requests. Furthermore, if the API crashed, scheduled jobs might not be added to the queue, causing cascading failures.

Hence, keeping the principles of isolation-of-concerns and abstraction in mind, we designed a more resilient REST-API-based queueing system: the Queue Service. This new service reads, writes and deletes messages from the queue after processing. It also encompasses the former capability of the queue-worker and acts as a scheduler.

Authentication

The SD API and Queue Service communicate bidirectionally using signed JWT tokens sent via auth headers of each request.

Build Sequence
image
Design Document

For more details, check out our design spec.

Using Queue Service

As a cluster admin, to configure using the queue as an executor, you can deploy the queue-service as a REST API using a screwdriver.yaml and update configuration in SD API to point to the new service endpoint:

# config/default.yaml
ecosystem:
    # Externally routable URL for the User Interface
    ui: https://cd.screwdriver.cd

    # Externally routable URL for the Artifact Store
    store: https://store.screwdriver.cd

    # Badge service (needs to add a status and color)
    badges: https://img.shields.io/badge/build–.svg

    # Internally routable FQDNS of the queue service
    queue: http://sdqueuesvc.screwdriver.svc.cluster.local

executor:
    plugin: queue
    queue: “

For more configuration options, see the queue-service documentation.

Compatibility List

In order to use the new workflow features, you will need these minimum versions:

  • UI – v1.0.502
  • API – v0.5.887
  • Launcher – v6.0.56
  • Queue-Service – v1.0.11
Contributors

Thanks to the following contributors for making this feature possible:

Questions and Suggestions

We’d love to hear from you. If you have any questions, please feel free to reach out here. You can also visit us on Github and Slack.

Apr 09
Love0

Screwdriver : Recent Enhancements and Bug Fixes

By Blog, Project

Recent Enhancements and Bug Fixes

Screwdriver Team from Verizon Media

UI

Previously, users could not start builds during a freeze window unless they made changes to the freeze window setting in the screwdriver.yaml configuration. Now, you can start a build by entering a reason in the confirmation modal. This can be useful for users needing to push out an urgent patch or hotfix during a freeze window.

image
image

Store

  • Feature: Build cache now supports local disk-based cache in addition to S3 cache.

Queue Worker

  • Bugfix: Periodic build timeout check
  • Enhancement: Prevent re-enqueue of builds from same event.

Compatibility List

In order to have these improvements, you will need these minimum versions:

  • UI – v1.0.479
  • API – v0.5.835
  • Store – v3.10.3
  • Launcher – v6.0.42
  • Queue-Worker – v2.9.0

Contributors

Thanks to the following contributors for making this feature possible:

Questions and Suggestions

We’d love to hear from you. If you have any questions, please feel free to reach out here. You can also visit us on Github and Slack.

Close Menu