Quantcast
Channel: Jenkins Blog
Viewing all 1088 articles
Browse latest View live
↧

DigitalOcean and Jenkins partnership continues to grow!

April 12, 2023, 6:43 pm
$
0
0

DO horizontal

The Jenkins project wants to acknowledge and share massive thanks to DigitalOcean for their continued sponsorship.

Between August 2022 and March 2023, Jenkins had been using roughly $1,300 credits a month. During March, we encountered a severe increase in our DigitalOcean workloads. This was a result of much heavier reliance on DigitalOcean, as we worked to resolve other infrastructure concerns. In addition to this reliance, there was increased activity on the Jenkins Bill Of Material repository. Unfortunately, the increased activity and reliance combined to push Jenkins over our normal budget.

However, DigitalOcean has provided the Jenkins project with an additional $8,400 credit for the next six months. This ensures that we are able to manage our resources and DigitalOcean workloads, without worry of interruption. Our deepest thanks go out to DigitalOcean, as they continue to show how supportive they are to both Jenkins and the Open Source community.

↧
Search

Jenkins March 2023 Newsletter

April 12, 2023, 6:43 pm
$
0
0

Jenkins March Newsletter

Highlights

  • Jenkins 2.397 and 2.387.2 are both using new Linux repository signing keys.

  • The Pipeline graph view plugin continues to evolve and improve as a Pipeline visualization replacement for Blue Ocean.

  • The number of pull requests merged for jenkins.io crossed into triple digits this month (101).

Governance Update

Contributed by: Mark Waite

Jenkins' installers for Debian and Red Hat have all been signed with new PGP private keys. Refer to the Jenkins blog post for more details. The Jenkins installer for Windows and the Jenkins WAR file have also been signed with a new code signing certificate issued by DigiCert. Thanks to the Continuous Delivery Foundation for their help with the new code signing certificate.

The Chinese translation of the Jenkins documentation has been unmaintained for almost two years. Rather than risk confusing Chinese users that are following outdated instructions, we’ve removed the link to the outdated Chinese site. We invite Chinese users to use the English language documentation.

Jenkins press contacts have been simplified, to invite members of the press with questions about Jenkins to post their questions to the press category on community.jenkins.io. Special thanks to Discourse for hosting the Jenkins community site.

The Jenkins board, members of the Jenkins security team, and several others were involved in resolving an incorrect claim against a repository of the Jenkins GitHub organization. The claim incorrectly asserted that one of the Jenkins GitHub repositories had published private information, copyrighted material, or a password without consent. The issue was resolved through the efforts of Daniel Beck, the company that filed the incorrect report, and the maintainers of the affected plugins. Thanks to all involved for resolving the issue.

Security Update

Contributed by: Kevin Guerroudj

Two security advisories have been published during the month of March:

  • One regarding plugins

    • 13 plugins were impacted

    • 9 without fixes according to our documentation

  • One regarding core and update-center2

    • The most critical being an XSS which we were able to confirm that there was no exploit.

Infrastructure Update Contributed by: Damien Duportal

Over the course of March, the Jenkins infrastructure team has worked to provide several enhancements and updates including:

  • Huge effort on bandwidth reduction for dependencies from JFrog, by switching almost all workloads to the new artifact caching proxy, with a focus on developer UX to allow disabling it when unreliable.

  • All of the controller Azure credentials are managed as code, opening the door for safer identity management.

  • Improved safety and reliability for the releases of both weekly and Jenkins Core, by migrating this process into a new private Kubernetes cluster.

  • Maven 3.9.0 and 3.9.1 were rolled-out to developers.

  • The Ubuntu 22.04 upgrade campaign has been planned and started.

  • A new GPG key rolled-out for signing Jenkins repositories and Core artifacts.

  • Usual maintenance efforts to keep the infrastructure running, including weekly dependency upgrades, support for the 2 security advisories, and migrating pipelines from GitHub actions to our own Jenkins private instances.

User Experience Update

Contributed by: Mark Waite

The Jenkins user experience continues to improve thanks to the efforts of many contributors, with special thanks to Jan Faracik and the many reviewers involved in the improvements.

The Pipeline graph view plugin continues to evolve and improve as a Pipeline visualization replacement for Blue Ocean. It now includes progressive viewing of log files. Thanks to Tim Brown for the improvements.

The "About Jenkins" page in Jenkins weekly releases now includes a new image and an invitation to "get involved" with the Jenkins project.

The Jenkins icon legend is now a modal dialog in Jenkins weekly releases. The modal dialog does not move the user away from the current page. Expect to see more modal dialogs in Jenkins in the future.

More Jenkins messages have been translated into Turkish thanks to Mustafa Ulu. They have been released in Jenkins weekly releases in March.

Support for user experimental flags ("feature flags") has been added to Jenkins core. Developers can deliver new features and allow users to enable or disable those features for their own account. Thanks to Wadeck Follonier for the implementation and thanks to all those who reviewed and helped with the pull request.

Documentation Update Contributed by: Kevin Martens

Over the course of March, there were 7 blog posts published, featuring several different authors. Bruno Verachten has shared his experiences using Jenkins in intriguing ways, as well as starting a new series of posts regarding Android and Jenkins. We also crossed into triple digits (101) for the number of pull requests merged this month for jenkins.io alone. Along with recent UI updates, the Jenkins documentation is being updated to reflect the simplified Manage Jenkins settings names. Thanks to all of the continuing and new contributors, all of your work helps support both the Jenkins project and the Open-Source community.

Platform Modernization Update

Contributed by: Bruno Verachten

Over the course of March, the Jenkins platform team provided several updates and improvements. These improvements include:

  • Jenkins 2.397 and 2.387.2 both using new Linux repository signing keys.

    • There is a great article by Mark Waite to explain why the keys have changed and how to update accordingly.

    • Nothing has to be done for Jenkins Docker installation, because the key is not required for container installations, as we manage the service ourselves in the container.

  • Docker end of open source software images (Docker announcement with later changes)

    • The old jenkinsci handle could have gone away, as it was not protected by OSS organization, before Docker changed their mind.

    • Jenkins4Eval may go, as it is dangerous and not really needed.

      • At this time, it is for a very niche use.

  • PowerPC 64: has made some nice progress. Thank you so much for your contribution Kenneth!

    • docker-agent: PR reviewed, checks have passed.

    • docker-ssh-agent: PR reviewed, checks have passed too.

    • Inbound-agent: PR reviewed, checks will pass once the docker-agent PR will be accepted.

    • Controller: PR is done as well, checks have passed too. It shouldn’t be long until all of these PRs make it into the next release.

    • Welcome to the community Kenneth, we’re delighted to have you onboard!

  • Alpine aarch64 images issue:

    • We’ve been following the progress for a few months now, and it looks like it won’t be solved soon. Temurin needs help to get this back on track. In the meantime, we have other Debian based images that can do the job.

  • Windows MSI installer code signing certificate updated (also signs jar file):

    • Windows users expect their installers to be signed/secured (because of malware and so on). The previous certificate expired March 30, 2023. Fortunately, Mark Waite and other members of the community managed to get a new one, so the latest weekly release is signed.

    • Lawyers had to be involved, but the process is now complete.

    • The MSI installer is signed with the new key.

  • Latest updates on the agent images:

    • Ssh-agent release 4.13.0

      • chore(deps): bump debian from bullseye-20230208 to bullseye-20230320 in /8/11/17bullseye (#222)

    • Docker-agent release 3107.v665000b_51092-6

      • chore(deps): bump archlinux from base-20230226 to base-20230319.0.135218 in /11/archlinux (#393)

      • chore(deps): bump debian from bullseye-20230227 to bullseye-20230320 in /11/17/bullseye (#394)

  • Experiments with RISC-V have progressed.

Outreach and advocacy Update

Contributed by: Alyssa Tong

SCALE 20X#

So thrilled to have been back at the usual spot (Pasadena Convention Center, CA) for SCALE this year, an added bonus were visits from special friends 🥰, Kohsuke Kawaguchi & Arun Gupta 🎉!

Many thanks to the Jenkins fans for stopping by the booth to let us know how much they love Jenkins! Special thanks to the SCALE committee for being a wonderful host! 🚀

imageimageimageimage

Jenkins in Google Summer of Code (GSoC)

If you lurk on the Jenkins GSoC Gitter channel, you will be quite surprised at the level of engagement…​ It is anything but quiet. The hustle and bustle indicates the level of interest in Jenkins in GSoC. Here’s where we currently stand:

  • We’ve received over 50 proposals via the Google Summer of Code portal.

  • Organization administrators and mentoring are reviewing and ranking the proposals.

Jenkins Awards

image

The list of nominations for the Jenkins Contributor Awards is quite impressive this year, with more people being nominated than ever before. We want to thank and congratulate all nominees, your contributions are seen, recognized and appreciated!

We also had more people voting this year than in previous years. Thank you to everyone who took the time to vote! Voting is now closed, and the results will be announced on May 8-9 at cdCon.

↧
↧

Meet with Jenkins Community at cdCon + GitOpsCon 2023

April 13, 2023, 5:53 am
$
0
0

cdCon + GitOpsCon 2023 Visual with Jenkins

The Continuous Delivery Foundation (CDF) is happy to host its fourth flagship event, cdCon, taking place on May 8–9, 2023 in Vancouver, Canada as cdCon + GitOpsCon, co-organized with the Cloud Native Computing Foundation (CNCF), making it the must-attend event for anyone who is involved in CD, DevOps, and GitOps.

By combining the two events, cdCon + GitOpsCon aims to bring their communities together to collaborate and build the future of GitOps and CD. The program committees reviewed more than 250 submissions and selected over 60 sessions that will span topics from technical challenges and deep dives, to end-user stories and introductory content.

The cdCon + GitOpsCon program contains sessions from the most widely used CI/CD and GitOps technologies. The Jenkins Community will be there with project updates and various talks from our community members and users. Here are some of the sessions you don’t want to miss.

In addition to these sessions, Mark Waite of CloudBees, a member of the Jenkins Governance Board and a long-time Jenkins user and contributor will take part in the Graduated Projects Keynote Panel, discussing Jenkins Community’s experiences with graduation and sharing his thoughts on why graduation matters for the community and users of Jenkins.

We look forward to an awesome event and we hope to see you there!

↧

Building Android apps with Jenkins: release management

May 2, 2023, 9:13 am
$
0
0

The previous blog post of this series discusses what I think makes CI/CD for mobile app development a unique kind of animal, and my first steps in building Android apps with Jenkins. We were left with a working declarative pipeline per branch, one Docker image per branch too, and an application binary ready to be deployed. Ready?

Release management

I was able to find the binaries in the workspace in a matter of seconds, but there is no release available, only binaries. This means there are some manual steps required to create a versioned release that we can deliver to test users, for example.

We can manually create a release within GitHub and then copy-paste the binaries from Jenkins' artifact archives to the GitHub release page. We can also do the same for the Google Play Store. However, this approach is neither efficient nor error-proof.

In regards to having a release on the Github repository at the same time as on Google Play, it really depends on the app and its audience. For the purposes of this article, let’s assume it’s okay.

Prerequisites

To automate the release process, we need to determine the criteria for a version number, how to update the version number, and what constitutes a release. We can use the "Semantic Version" Gradle plugin, which has a strict set of rules to guide us. This plugin allows us to increment the patch, minor, or major version using Gradle commands. We can also use classifiers such as snapshot, beta, alpha, or any other version classifier to define a version name.

version="1.1.11"applyplugin:"com.dipien.android.semantic-version"

I then searched for a Jenkins plugin that would create a GitHub release. As the saying goes,

There’s a plugin for that

but unfortunately, I couldn’t find one that meets my needs. While there is a plugin called Git Changelog that can merge commit messages to produce a readable version of the changes, it doesn’t create the release.

GitHub release

If you want to stay on the Jenkins side, there isn’t a plugin this time. However, there are various ways to create a release. You can use the GitHub REST API or the gh command, which can handle all the heavy lifting for us. Therefore, let’s go back to the drawing board and add the command to our Docker image.

# Install GitHub command line toolENV GITHUB_TOKEN $GITHUB_TOKENRUN curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg &&\
chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg &&\
echo"deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | tee /etc/apt/sources.list.d/github-cli.list > /dev/null &&\
    apt update && apt install-y--no-install-recommends gh

Once that’s done, we need to use GitHub App authentication to enable gh to use our credentials. To do this, we have to install the GitHub Branch Source plugin and then create a GitHub Application.

The existting documentation on GitHub is exactly what we need, so a link to this should suffice. The only fields you need to prepare and fill out at this stage are:

  • Github App name - i.e. Jenkins-<team name>

  • Homepage URL - your company’s domain or a GitHub repository

  • Webhook URL - your jenkins instance, for example, https://<jenkins-host>/github-webhook/

At that moment, I queried GitHub using gh to determine whether the release already existed, and create it if not.

My choice of how to create the release was entirely arbitrary: I decided to create a release when the version ended with "RELEASE", a draft release when there was no suffix, and a pre-release when the version ended with "ALPHA" or "BETA".

suffix=$(echo$versionName | sed's/.*-//')case$suffixin
    ALPHA|BETA)echo"Time to do a prerelease"GH_OPTS="$GH_OPTS-p";;
    SNAPSHOT)echo"This is a snapshot, we won't release anything"GH_OPTS="$GH_OPTS DO_NOT_RELEASE";;
    RELEASE)echo"This a real release, so no need to use -d or -p";;*)echo"Unknown suffix \"$suffix\", so we'll do a draft release"GH_OPTS="$GH_OPTS-d";;esac

This is good enough for my use case.

The gh command does a nice job of preparing a release change log, so I’m relying on it. If we’re not building on the main branch, the release is not finalized, so I can still tidy it up later. It’s great to be able to create a release as soon as it’s required, even when it’s not necessary…

Too many releases

It looks like I may have gone a little too far with the automatic release creation, don’t you think?

Now, what about using that workflow to create a release on the Play Store?

Google Play Store release

The version is already handled by the semantic plugin, and the release notes are almost ready to go. Now, we just need to find the right plugin to push our app to the Google Play Store. Luckily, we have a plugin for that, called com.github.triplet.play. This time, it’s a Gradle plugin instead of a Jenkins plugin.

The first step to getting your app on the Play Store is to pay the $25 developer account fee. After that, you need to register your app, import the EULA (there are free websites to generate that), upload the required paperwork, and then upload the signed app. Since the app is not signed yet, we’ll need to do that first.

Signing the app from the command line

There are different ways to sign your app - from the command line using apksigner for APKs, jarsigner for app bundles, or you can configure Gradle to sign it during the build. In any case, you need to generate a private key using keytool before signing the app.

 keytool -genkey-v-keystore my-release-key.jks -keyalg RSA -validity 10000 -alias my-alias

Let’s quickly review how to sign an apk:

  1. Align the unsigned APK using zipalign:

    zipalign -v-p 4 my-app-unsigned.apk my-app-unsigned-aligned.apk

    zipalign ensures that all uncompressed data starts with a particular byte alignment relative to the start of the file, which may reduce the amount of RAM consumed by an app.

  2. Sign your APK with your previously generated private key using apksigner:

    apksigner sign --ks my-release-key.jks --out my-app-release.apk my-app-unsigned-aligned.apk

    This example outputs the signed APK at my-app-release.apk after signing it with a private key and certificate, that are stored in a single KeyStore file: my-release-key.jks.

Now, let’s discuss how to sign an application bundle (located in app/build/outputs/bundle/debug) thanks to Gradle.

jarsigner -verbose-sigalg SHA256withRSA -keystore ../../../../../my-release-key.jks app-debug.aab my-alias

Signing the app from Gradle

Open the module-level build.gradle file and add the signingConfigs {} block with entries for storeFile, storePassword, keyAlias and keyPassword. Then, pass that object to the signingConfig property in your build type. For example:

signingConfigs{release{// You need to specify either an absolute path or include the// keystore file in the same directory as the build.gradle file.storeFilefile("my-release-key.jks")storePassword"password"keyAlias"my-alias"keyPassword"password"}}buildTypes{release{minifyEnabledfalseproguardFilesgetDefaultProguardFile('proguard-android-optimize.txt'),'proguard-rules.pro'signingConfigsigningConfigs.release}}

From now on, when you create the bundle with Gradle, it will be signed, self-signed, which is not what we’re aiming for. We still need to upload the icon, a summary, screenshots, banners, and other boilerplate content… The next step is to create a GCP project.

Creating a GCP project

You have to enable the Android Publisher API for that project.

Then, you have to link your Google Play developer account to the GCP project.

After this, you need to create a service account.

Then create a key.

To set up the necessary credentials for publishing our app to the Play Store, we’ll need to create an environment variable in Jenkins. To do this, we first need to install the Environment Injector plugin. Once that’s done, we can grant the necessary permissions to our service account so that it can publish the app on our behalf.

And we’re finally ready to publish our app thanks to Gradle on Jenkins.

Publishing the app

The gradlew tasks group publishing tells us we have a publishBundle task that uploads App Bundle for all variants.

./gradlew tasks --group publishing

> Task :tasks

------------------------------------------------------------
Tasks runnable from root project 'My First Built by Jenkins Applications'------------------------------------------------------------

Publishing tasks
----------------[...]
publishBundle - Uploads App Bundle for all variants.
   See https://github.com/Triple-T/gradle-play-publisher#publishing-an-app-bundle
[...]
BUILD SUCCESSFUL in 1s
1 actionable task: 1 executed

As we did not store the generated jks file in the repo, we have to use a variable to hold the value. On your machine, it would work with something like:

export ANDROID_PUBLISHER_CREDENTIALS=`cat*json`

On Jenkins, we will create a secret.

The secret is now available under the android-publisher-credentials key.

The triplet documentation tells us that we can set up a configuration in the build.gradle file like:

play{// Overrides defaultstrack.set("internal")updatePriority.set(2)releaseStatus.set(ReleaseStatus.DRAFT)// ...}

Gradle Play Publisher supports uploading both the App Bundle and APK, and can promote those artifacts to different tracks. You can customize how your artifacts are published using several options:

  • track: The target stage for an artifact, such as internal/alpha/beta/production or any custom track.

    • Defaults to internal

  • releaseStatus: The type of release, such as ReleaseStatus.COMPLETED, ReleaseStatus.DRAFT, ReleaseStatus.HALTED, or ReleaseStatus.IN_PROGRESS.

    • Defaults to ReleaseStatus.COMPLETED

  • userFraction: The percentage of users who will receive a staged release.

    • This is only applicable where releaseStatus=[IN_PROGRESS/HALTED].

    • defaults to 0.1 (10%)

  • updatePriority: Sets the update priority for a new release. Refer to Google’s documentation for more information.

    • Defaults to the API value

Furthermore, according to the documentation, you need to supply a release notes file. To do so, you need to add a file under src/[sourceSet]/play/release-notes/[language]/[track].txt.
Here, sourceSet is a full variant name, language is one of the Play Store supported codes, and track is the channel you want these release notes to apply to. If no channel is specified, the default channel will be used.

As an example, let’s assume you have these two different release notes:

src/main/play/release-notes/en-US/default.txt
.../beta.txt

When you publish to the beta channel, the beta.txt release notes will be uploaded. For any other channel, default.txt will be uploaded.

For our use case, we’ll use the internal track, and start from the release notes generated via the gh tool to produce a shorter version, limited to 500 characters as specified by Google.

gh release view v${versionName} | grep-A 500 "\-\-" | grep-v"\-\-" | sed's/http.*[/]/#/'>$releaseNotesDir/internal.txt
    content=$(cat< "$releaseNotesDir/internal.txt"&&echo .)&&content=${content%.}&&printf %s "${content:0:500}">"$releaseNotesDir/internal.txt"

Have we completed all the necessary steps?

We now have an Android application that builds, has undergone static analysis, and is automatically pushed to both GitHub and the Google Play Store. However, there is still much left to cover, which we will explore in upcoming episodes.

↧

Welcome Google Summer of Code 2023 Contributors!

May 4, 2023, 11:13 pm
$
0
0

Jenkins GSoC

On behalf of the Jenkins GSoC org admin team and mentors, we would like to welcome Harsh Pratap Singh, Jagruti Tiwari, Vandit Singh, and Ashutosh Saxena. They will be working on Google Summer of Code projects in the Jenkins organization, and they have already done some contributions.

This year we have the following projects:

  • GitLab Plugin modernisation - Cleaning and modernizing the extensively used GitLab plugin.
    Contributor: Harsh Pratap Singh from India.
    Mentors: Mark Waite, Kris Stern, and Freyam Mehta.

  • Adding probes to Plugin Health Score - The first iteration of the tool provided a limited set of probes. To improve the effectiveness of the scoring system, more probes are needed.
    Contributor: Jagruti Tiwari from India.
    Mentors: Adrien Lecharpentier, Dheeraj Singh Jodha, and Mostafa Ashraf Mohamed.

  • Building jenkins.io with alternative tools - Using alternative tooling (i.e., Antora) to build the Jenkins static site and provide documentation per Jenkins version.
    Contributor: Vandit Singh from India.
    Mentors: Kris Stern, Rajiv Ranjan Singh, Yiming Gong, and Mark Waite.

  • Docker-based Jenkins quickstart examples - Provide examples, sample code, and documentation on how to start a local Jenkins instance.
    Contributor: Ashutosh Saxena from India.
    Mentors: Bruno Verachten, Bervianto Leo Pratama, and Saeid Bostandoust.

    • As part of the "GSoC Community Bonding Period" over the next few weeks, project teams will be reaching out to potential stakeholders. The purpose is to establish connections with the community to get comments regarding their project designs. If you are interested in the projects, please join discussions in the GSoC SIG and project Gitter channels, the Developer mailing lists, and project meetings once they get scheduled. Also, expect more detailed blogposts about the projects soon.

    If you are interested to know more about GSoC in Jenkins, you can find information, timelines, and communication channels here.

↧
↧

Jenkins April 2023 Newsletter

May 11, 2023, 12:15 am
$
0
0

Jenkins April Newsletter

Key Takeaways

  • There was one security advisory this month announcing vulnerabilities regarding Jenkins plugins.

  • Cloud Cost Controls with improved resource cleanups and VM usage optimization to face the increased rate of builds on ci.jenkins.io.

  • Thanks to DigitalOcean for their continued support and ($8,400 credit) sponsorship of Jenkins.

  • Ppc64le docker agent images are now available.

  • Jenkins at cdCon + GitOpsCon!

Security Update

Contributed by: Wadeck Follonier

In April, there was one advisory regarding plugins published on April 12:

  • One coordinated effort related to improper masking of credentials.

  • 14 plugins were impacted.

  • 12 without fixes according to our documentation.

Governance Update

Contributed by: Mark Waite

The Chinese language Jenkins website is being retired. Translation updates have not been made in two years and users are perplexed when the installation instructions and other instructions are no longer correct. The Chinese localization of Jenkins continues to be available, but the links to the Chinese website have been removed.

Infrastructure Update Contributed by: Damien Duportal

  • Cloud Cost Controls with improved resource cleanups and VM usage optimization to face the increased rate of builds on ci.jenkins.io:

    • Decreased the AWS bill from $19,000 to $14,000, resulting in savings of $5,000.

    • Decreased the Azure bill by $2,000.

  • DigitalOcean gave $8,400 additional credits to the Jenkins project, for the infrastructure to sustain ci.jenkins.io increased build rate. Thanks to DigitalOcean for their continued support!

  • ci.jenkins.io performance improved by getting rid of the JobConfigHistory plugin.

  • The Ubuntu 22.04 upgrade campaign (18.04 is end-of-life in May 2023) is in progress.

  • Jenkins LTS 2.387.2 was deployed everywhere less than 48h after its release.

  • General availability of JDK 8u372-b07, 11.0.19+7, and 17.0.7+7.

  • Prototyping Azure arm64 build agents is done, we can move forward to production for our internal usages first.

User Experience Update

Contributed by: Mark Waite

An accessibility assessment of Jenkins has been provided by Deutsche Telekom. The assessment is being used by Cristina Pizzagalli and others to improve the Jenkins user experience for users with disabilities. Contributors that are interested in helping with the accessibility improvements should include their comments on JENKINS-71153.

Mobile users of Jenkins will now see a card layout of the Jenkins user interface, thanks to work done by Jan Faracik.

The Prototype.js JavaScript library that is widely used in Jenkins core and Jenkins plugins is being replaced. Special thanks to Tim Jacomb, Basil Crow, Alexander Brandes, and several others for their work replacing that library. Contributors that would like to help with the JavaScript work are invited to assign themselves one of the issues listed in JENKINS-70906.

Platform Modernization Update

Contributed by: Bruno Verachten

Over the course of April, the Jenkins platform saw several updates and improvements. These improvements include:

  • The Digicert code signing for MSI installer and jar file was updated.

  • The PGP signing key was updated for RPM and DEB packages.

  • Ppc64le: we’re almost at the end. Thank you so much for your contributions Kenneth!

    • docker-agent: PR merged.

    • docker-ssh-agent: PR merged.

    • Inbound-agent: PR merged.

    • The Controller PR is also done, but not merged yet.

  • Latest updates on the agent images:

    • Ssh-agent release 4.15.0

      • This includes updating Debian to bullseye-20230411 in /17/8/11/bullseye. (#234).

      • Adding ppc64le support back into the Jenkins CI SSH agent Docker build. (#220) @ksalerno99

      • Now using Java 11.0.18 (#231) @MarkEWaite

    • Docker-agent release 3107.v665000b_51092-8

      • Upgrade of Arch Linux from base-20230319.0.135218 to base-20230409.0.141585 in /11/archlinux. (#402)

      • Upgrade of Debian from bullseye-20230320 to bullseye-20230411 in 11/17/bullseye. (#403)

      • Added ppc64le support back into the Jenkins CI agent Docker build. (#391) @ksalerno99

      • Exposing the default image user to the environment variable user. (#400) @dduportal

  • Mark Waite is working on a system that would warn when operating system end-of-life is approaching.

Documentation Update Contributed by: Kevin Martens

Over the course of April, there were 4 blog posts published, featuring seven different authors. Bruno Verachten continues his series on building android apps in Jenkins. As Google Summer of Code begins, we want to acknowledge and thank all of the applicants for their efforts. Thanks to all of the continuing and new contributors, all of your work helps support both the Jenkins project and the Open-Source community.

We also want to thank DigitalOcean for their continued support and sponsorship of Jenkins. They have provided us with an additional $8,400 credit as the Infrastructure team works on reducing bandwidth usage further.

Outreach and advocacy Update

Contributed by: Alyssa Tong

Jenkins in Google Summer of Code (GSoC)

We had an unprecedented number of GSoC applicants interested in Jenkins this year. The Jenkins project received over 60 proposals by the close of the application period. Dedicated Jenkins mentors worked overtime and weekends to review and grade proposals within a two weeks period. Many THANKS to the wonderful Jenkins mentors, this program isn’t possible without them.

Best of luck to all GSoC participants!

Jenkins at cdCon + GitOpsCon

April was all about preparations for cdCon, which took place on May 8–9, 2023 in Vancouver, Canada as cdCon + GitOpsCon, co-organized with the Cloud Native Computing Foundation (CNCF). Members of the Jenkins Governance Board, long-time Jenkins users and contributors Mark Waite and Alex Brandes were in attendance. Mark took part in the Graduated Projects Keynote Panel, discussing Jenkins Community’s experiences with graduation and sharing his thoughts on why graduation matters for the community and users of Jenkins. Recordings for the conference will be available in approximately two weeks, on the CDF YouTube channel.

Thanks to everyone who attended!

↧

Removing Prototype from Jenkins

May 12, 2023, 5:44 pm
$
0
0

Summary

Usage of the Prototype JavaScript framework has been deprecated in recent versions of Jenkins core and will be removed completely in the future. Plugin developers should prepare for this transition by removing usages of Prototype and testing with Prototype removed.

Motivation

Prototype was created by Sam Stephenson in February 2005 as part of Ajax support in Ruby on Rails. While it was considered a major advance at the time, it has now fallen out of favor due to its invasive modifications to standard JavaScript functionality. At this point in time, all Prototype features have native equivalents in the Web Platform. Moreover, the very presence of Prototype’s invasive modifications actively causes compatibility problems with modern JavaScript libraries.

Worse, core currently uses a patched version of Prototype 1.7, released on November 15, 2010. The latest version is 1.7.3, released on September 22, 2015. When an attempt was made to upgrade to 1.7.3 in 2018 in JENKINS-49319, the change had to be reverted.

Clearly the status quo is unsustainable. For these reasons, we have been working to remove Prototype from the Jenkins ecosystem in JENKINS-70906.

Testing core and plugins

As of Jenkins 2.404, a user experimental flag has been added to remove Prototype. The flag can be enabled or disabled on a per-user basis and removes Prototype from all Jenkins UI pages. The flag is intended to be used by core and plugin developers to do testing with Prototype removed. To enable the flag, go to the Configure page for your user in 2.404 or later, scroll to the Experiments section at the bottom, and enable the flag.

As of Jenkins 2.404, most usages of Prototype have been removed from core, and even more will be removed by 2.405. We anticipate that all core usages of Prototype will be removed in a forthcoming weekly release. At that point, the focus will shift to removing Prototype usages from plugins.

To test with Prototype removed, enable the user experimental flag and watch the browser console log for error messages as you exercise various pieces of JavaScript code. If an error occurs with Prototype removed but does not occur with Prototype present, you have found code that needs to be adapted.

Adapting plugins

When adapting plugins, first ensure that the plugin is using plugin parent POM 4.58 or greater. This contains an update to support the Fetch API in the HtmlUnit browser used by the test harness. Without this, you will likely see errors concerning the Fetch API in HtmlUnit tests.

The next thing to do is search for common Prototype usages and convert them to native JavaScript APIs. The following command attempts to search for some common usages in views:

$ find .-type f \(-name"*.groovy"-o-name"*.jelly"-o-name"*.js"\)-execgrep-HnE'\.each\(|Object\.toJSON|Prototype\.Selector|\$\$\(|\$A|\$F|\.on\(|\.observe\(|\.fire\(|Form\.getInputs|Element\.stopObserving|\.removeClassName\(|\.addClassName\(|\.hasClassName\(|\.nextSiblings\(|\.firstDescendant\(|\.previous\(|\.up\(|\.down\(|\.next\(|\.childElements\(|\.escapeHTML\(|\.show\(\)|\.hide\(\)|\.setStyle\(|\.setOpacity\(|\.getResponseHeader\(|Ajax\.Request|Ajax\.Updater|Ajax\.PeriodicalUpdater'{}\;

This is neither an exhaustive list, nor is it guaranteed to be free from false positives. But it is a good place to start. Below I will give some examples of common usages and their recommended replacements. When in doubt, consult the Prototype API documentation for information about the old usage, and consult the Web Platform documentation for information about recommended replacements.

Once you have removed the usage of Prototype, test your plugin both with and without the user experimental flag enabled. If the line you have changed works with and without Prototype (as verified by stepping into the line with the browser’s JavaScript debugger), then you are ready to merge and release the change.

Cheat sheet

The following are my rough and unpolished notes from doing this conversion a few dozen times. This is a good place to start, but it is is not an exhaustive list of changes that need to be made.

General changes

Replace any usages of .each with .forEach.

If the argument to the Prototype $ function is a string, then replace it with document.getElementById. For example, replace $("my-id") with document.getElementById("my-id").

If the argument to the Prototype $ function is an Element, then simply remove the call to the Prototype $ function. For example, replace $(element) with element.

The Prototype double dollar-sign function should be replaced with either document.querySelector or document.querySelectorAll, depending on whether the first result or all results are required. Also be on the lookout for usages of Prototype.Selector.find and Prototype.Selector.select, which can also be replaced by query selectors.

The Prototype $A function should be replaced with Array.from.

Class names

The next most common set of issues is regarding class names.

  • Replace e.g. element.hasClassName("my-class") with element.classList.contains("my-class").

  • Similarly, replace e.g. element.removeClassName("my-class") with element.classList.remove("my-class").

  • Similarly, replace e.g. element.addClassName("my-class") with element.classList.add("my-class").

One caveat here is that the Prototype versions of these functions can accept a space-separated string of multiple class names; the native JavaScript versions do not accept this and instead require you to iterate over each class name.

Element manipulation

The next most common set of issues is regarding element manipulation.

  • Replace e.g. element.childElements() with element.children.

  • Replace e.g. element.down() with element.firstElementChild.

  • Replace e.g. element.firstDescendant() with element.firstElementChild.

  • Replace e.g. element.next() with element.nextElementSibling.

  • Replace e.g. element.previous() with element.previousElementSibling.

  • Replace e.g. element.setOpacity(0) with element.style.opacity = 0.

  • Replace e.g. element.setStyle({foo: bar}) with element.style.foo = bar.

  • Replace e.g. element.show() with element.style.display = "" and e.g. element.hide() with element.style.display = "none".

  • Replace e.g. element.up("div") with element.closest("div").

  • Replace e.g. element.up() with element.parentNode.

  • Replace Prototype-based element creation with document.createElement.

Event handling

Another common set of issues is regarding event handling.

  • Replace e.g. Element.observe(element, "event", callback) with element.addEventListener("event", callback).

  • Replace e.g. element.observe("event", callback) with element.addEventListener("event", callback).

  • Replace e.g. Element.on(element, "event", callback) with element.addEventListener("event", callback).

  • Replace e.g. element.on("event", callback) with element.addEventListener("event", callback).

  • Replace e.g. Element.stopObserving with document.removeEventListener.

  • Replace e.g. Event.fire(element, "event") with element.dispatchEvent(new Event("event")).

  • Replace e.g. Event.on(element, "event", callback) with element.addEventListener("event", callback).

JSON strings

Calls to Object.toJSON are problematic. They need to be converted to JSON.stringify when Prototype is not present, but JSON.stringify is actually broken when Prototype is present. The recommendation is to use a conditional during the transition phase:

// TODO simplify when Prototype.js is removedif (Object.toJSON){// Prototype.jsreturnObject.toJSON(obj);}else{// StandardreturnJSON.stringify(obj);}

Ajax requests

Finally, the most difficult set of changes relates to Ajax requests.

Anything that uses Ajax.Request, Ajax.Updater, or Ajax.PeriodicalUpdater should be converted to using the Fetch API. The best way to learn how to do this is to study the examples from recent core pull requests.

Note that Ajax.Request defaults to POST requests, but the Fetch API defaults to GET requests. If the original code did not specify a method, ensure you are still doing a POST request.

Also note that the Jenkins version of Prototype automatically adds a crumb to POST requests; this must be done explicitly when using the Fetch API by adding a Crumb header. Core features a crumb.wrap() method that takes an existing object (which may be empty) and adds the Crumb header to it.

application/x-www-form-urlencoded parameters should be passed to the Fetch API in the body, but beware that HtmlUnit is not compatible with these. Search core for objectToUrlFormEncoded for a workaround.

The Fetch API will return a response object. If the original Prototype code used onSuccess, you will need to check response.ok before doing the action; if the original Prototype code used onCompletion, you can skip this check.

If you are checking the response for a header with .getResponseHeader in Prototype, this will need to be replaced with .headers.get.

If you have read this far, congratulations and good luck!

↧

Jenkins 2023 Contributor Award Winners

May 17, 2023, 8:45 pm
$
0
0

image

At cdCon last week in Vancouver, May 8–9, the Jenkins Contributor Award winners were announced along with fifteen (15) other CDF Award winners. This is an annual award program where Jenkins contributors are nominated and voted by their peers within the Jenkins community.

Thank you to everyone who nominated and voted and to CDF for hosting this program. And special thanks to all of the Jenkins nominees, the project is in a better place because of you!

The Jenkins project has three award categories: Most Valuable Advocate, Security MVP, and Most Valuable Contributor. Congratulations to this year’s winners! Your hard work and leadership are what makes this community thrive and the advancement of the Jenkins project possible.

And the 2023 Jenkins Contributor Award honorees are…

imageSecurity MVP: Daniel Beck

For the Jenkins code scanning tooling project he started and went to GA recently, his never-ending improvements on the security documentation for jenkins.io, 50+ vulnerabilities reported by Daniel that were published during last year. And his continuous effort to ensure the update center is stable and secure.

imageMost Valuable Contributor: Jan Faracik

In honor of the work that he’s done to refine and improve the look and feel of Jenkins. He’s successfully implemented major changes to the Jenkins user interface, removed outdated components, and advanced the state of the Jenkins user experience.

imageMost Valuable Advocate: Mark Waite

For the tremendous work he has done on all the Jenkins media (Gitter, discourse, etc.), the numerous PR reviews, the YouTube videos with Darin Pope, the SIG he runs or attends to… Well, too much to list.

The award ceremony at cdCon was filmed and we will link the video here as soon as it’s available.

↧
Search

Introducing Vandit Singh as the GSoC 2023 Contributor Working on Building Jenkins.io with Alternative Tools

May 18, 2023, 10:14 pm
$
0
0

Jenkins GSoC

Dear Jenkins Community,

I am thrilled to have this opportunity to introduce myself as the Google Summer of Code (GSoC) 2023 contributor who will be working on the exciting project of "Building jenkins.io with alternative tools". I am genuinely excited to join this vibrant community and contribute to the development of Jenkins, a widely adopted and powerful automation server.

Project Description/Motivation:

The project I will be working on aims to generate the existing Jenkins.io website using alternative tools like Antora and Gatsby. The primary goal of this project is to make the Jenkins user documentation Product Version Bound. Both tools are used for site generation however we will be using Antora for most parts of the site as its best fits our current needs.

Introduction:

Let me take a moment to introduce myself. My name is Vandit Singh, and I am an aspiring software developer from India with a passion for automation and continuous integration/continuous delivery (CI/CD) practices. I have a strong interest in Java, DevOps and Web, and I am eager to leverage my skills to have a fruitful summer under Google Summer of Code.

Throughout my academic journey, I have realized the tremendous potential of automation in streamlining software development processes. My exposure to Jenkins, both as a user and an admirer of its capabilities, has inspired me to become an active contributor to its growth and evolution.

Plans for the Near Future:

As I embark on this GSoC journey, I have laid out some plans for the initial phase of the project before the mid-term evaluations. Firstly, I will focus on developing a prototype of jenkins.io with Antora with Versioned User Documentation. After that developer documentation will be non-versioned and at last blogs will be generated with Gatsby. For more details, you can refer to the project page.

In parallel, I will collaborate with the Jenkins community to gather feedback and suggestions on the existing Jenkins.io structure. By understanding the needs and pain points of the community, I aim to enhance the user experience and ensure that the alternative tools project aligns seamlessly with the existing content and architecture and enhances UI/UX in some way.

Technical Details:

From a technical perspective, my work will involve tools that are used to generate static sites. This may include solutions like Antora and Gatsby, with a focus on maintaining the current theme and layout.

Throughout the GSoC period, I am eager to collaborate with the Jenkins community, engage in discussions, and learn from the experienced members who have been instrumental in shaping Jenkins into the remarkable tool it is today. I genuinely believe that this project will be a collective effort, and I am excited to collaborate and contribute in a meaningful way.

In Closing:

As I embark on this incredible journey as a GSoC 2023 contributor, I would like to express my gratitude to the Jenkins community for giving me this opportunity. I am honoured to be part of a community that fosters innovation and promotes open-source collaboration.

I am filled with a sense of enthusiasm and anticipation as I dive into the project and get to know the community better. Together, we can unlock new possibilities and ensure that Jenkins remains at the forefront of continuous integration and delivery.

Please stay tuned for updates and feel free to reach out to me via the Jenkins community channels. Your guidance, feedback, and support are invaluable as I work towards building a more vibrant and resourceful jenkins.io.

Thank you all for your warm welcome, and here’s to an exciting and fruitful GSoC.

↧
↧

Introducing Harsh Pratap Singh as the GSoC 2023 Contributor working on GitLab Plugin Modernization

May 18, 2023, 10:14 pm
$
0
0

Jenkins GSoC

This is Harsh Pratap Singh, an Open source enthusiast, who is currently in his freshman year exploring different technologies related to DevSecOps and Blockchain. I am curious and passionate about automation thus Jenkins is my goto Open Source organization for Google Summer of Code. This is my first time contributing to Open Source and I am already loving it. I am fortunate enough to get selected in Google Summer of Code 2023 and I am looking forward to a thrilling summer.

About the Project

I will be working on GitLab Plugin Modernization project which primarily aims to replace the use of old RESTEasy with modern GitLab4J-API library via the GitLab API Jenkins library plugin. After this migration, the Jenkins Community will experience improved performance, better maintenance and support, and increased functionality and flexibility in the Gitlab-Plugin. I am optimistic and excited to collaborate with the Jenkins community and learn from the experienced mentors and community members for successful completion of the Project.

For more details related to the project, you can refer to the Project Page.

Conclusion

I want to express by gratitude towards my mentors and org admins for their constant guidance and support. I sincerely hope that I will be able to help Jenkins community prosper with my contributions and create a positive impact.

Please feel free to reach out through gitter or community channels for fruitful discussions.

Looking forward to a great Summer!

↧

Introducing Jagruti Tiwari as the GSoC 2023 Contributor Working on Adding Probes to Plugin Health Scoring System

May 23, 2023, 2:45 am
$
0
0

Jenkins GSoC

Background

I started contributing to open-source projects in Jan 2022. I tried setting up well-known projects like Django, Brave browser, and Chromium but failed miserably. I didn’t know that open source is not about projects but about community. Gradually I stumbled upon freeCodeCamp. That’s where I wrote my first test case and fixed minor bugs. I gained the confidence to continue contributing to open source.

Two months later it was time for GSoC. I started late but wanted to make it anyhow. OpenFoodFacts turned out to be the best-suited project for me. I did not make it to GSoC 2022 but built a lifelong relationship with the mentors. They groomed, tutored, and mentored me. They made me the open-source contributor I am today.

Education and Work

I hold a master’s degree in computer application. I work at one of the reputed organizations in India as a Senior Project Engineer. My total work experience is around 4 years.

Why Jenkins?

I have worked for the longest time in Java. I was looking to contribute to Java projects during Hacktoberfest 2022. It was a weekend when the fest started. I decided to give a try to a project that seems difficult from the outside. I commented on different issues and asked for guidance and explanation. That’s when Mark Waite came to the rescue. He was my mentor throughout. After making a couple of documentation fixes I remember writing a simple test to test a constructor. He showed me how it could be done. The next day I remember bragging to my colleagues about contributing to Jenkins.

A few days later Jean-March Meessen set up a call with me. He asked about my experience in open source, contributing to Jenkins, what I do, my future open-source plans, etc. When the call ended I wanted to be a part of a community where there are more people like him.

Why Plugin Health Scoring System?

After Hacktoberfest, I contributed to different plugins. Modernized them, fixed minor bugs, wrote test cases, etc. When Jenkins' ideas list for GSoC 2023 was out, I tried contributing to a couple of projects in the list. Projects required skills like ReactJs, Antora, and Docker. I found I was short of time to pick those skills and make an attempt to write a decent proposal.

I made my first PR to Plugin Health Scoring System. It was merged in 3-4 days. This was my fastest merged PR. I understood Adrien’s instructions and did not stray from the solution. This gave me the confidence to apply to Plugin Health Score for GSoC 2023. Once the PR was merged, I asked the community if I should work on the proposal or make more contributions. Mentors unanimously suggested it’s time I start with the proposal.

I started with the daft proposal in Feb 2023. After multiple rounds of review until the last submission date, I always thought I should add something more to make it slightly better.

How will the community benefit from my GSoC contribution

My project is titled “Adding Probes to Plugin Health Score”. As the title suggests I have proposed to add as many probes as possible to determine a plugin’s health.

What are probes?

Probes are nothing but data that compute the health score of the plugin. The score is computed based on the data collected by the probe. Based on this score, the future contributors and maintainers, adopters decide which plugin they want to invest their time in.

What will I do during this GSoC period?

  1. Designing the probes

    1. Identify the key features and functionality of the plugins.

    2. Define the metrics that would contribute to the Plugin Health Score.

    3. The more probe criteria the plugin meets, the higher the health score of the plugin.

  2. Deciding the probe’s interaction with other probes

    1. Decide the order in which a probe should be executed by the scheduler (Which probe should be executed first, second, and so on).

  3. Determining how the probe would contribute to the score

    1. Give each probe a weightage (coefficient).

    2. If the probe criteria are met with a plugin. Increase the score of the plugin. Otherwise, leave the score as it is.

    3. If a probe weight is negative, adding the negative value will decrease the score; eventually decreasing the health of the plugin.

  4. Adding unit test cases for each probe and scoring implementation. If time permits, I will add some integration test cases too.

  5. Delivering 10 new probes to the Plugin Health Scoring System.

    1. These probes will contribute to calculating the overall health of a plugin.

    2. By the time the project ends, the tool will approximately have 24 probes in all (10 new + 14 existing probes)

Sharing a few links so that everyone is abreast of my progress throughout the GSoC period.

Conclusion

The GSoC Community Bonding period will end next week. I have attended two project meetings until now and am on the threshold of completing my first probe as a GSoC contributor.

In 2022, GSoC opened doors for every interested contributor. Irrespective of the fact whether they are a student, working professional, or a self-learner. I plan to make the best use of the opportunity.

I wish to stay with the community long after GSoC. Hope to have their guidance and support as always.

↧

GitHub sponsors the Jenkins project

May 26, 2023, 3:15 am
$
0
0

The Jenkins project has used GitHub since 2007. GitHub has been our source code hosting and management platform for almost as long as Jenkins has existed. Jenkins core and all its plugins live on GitHub.

GitHub sponsors Jenkins

We are pleased to announce that GitHub sponsors the jenkinsci GitHub organization with enterprise features, such as autolink references.

If you are a Jenkins plugin maintainer, you can now use autolink references to link to Jenkins Jira issues. All you need to do is heading to the "Settings" tab of your GitHub repository and add the following configuration to the "Autolink references" section:

Alphanumeric
Reference prefix: JENKINS-
Target URL: https://issues.jenkins.io/browse/JENKINS-<num>

We’re deeply grateful to GitHub for their support of open source software and especially for their support of the Jenkins project.

The Jenkins project by numbers

The jenkinsci GitHub organization hosts over 2,600 repositories. These repositories are the home of:

  • 1,000,000+ Lines of Code

  • 130,000+ Pull requests

  • 20,000+ Issues

  • 2,500+ organization members

and countless contributors.

We truly thank GitHub for their sponsorship of the Jenkins project.

↧

Introducing Ashutosh Saxena as the GSoC 2023 Contributor Working on Docker Based Jenkins Quickstart Examples

May 27, 2023, 2:13 am
$
0
0

Jenkins GSoC

Hello, Jenkins community! I am really excited to be a GSoC 2023 contributor for Docker-based Jenkins quickstart examples project. In this blog post, I will take you through the details of the project in the following:

Project Description

The Docker-based Jenkins Quickstart Examples project aims to provide a quick and easy way for users to get started with Jenkins using Docker. By providing user-friendly Docker Compose files and updating the documentation, we make it simple for beginners to set up Jenkins and start exploring its features. These files will be regularly tested on ci.jenkins.io to ensure reliability and functionality. The Pipeline Steps doc generator will be used to maintain up-to-date documentation, and Gitpod will facilitate quickstart with a .gitpod.yml file running docker-compose commands, enabling easy preview of Jenkins instances.

Our goal is to enhance the user experience and make it more seamless and efficient for users to become familiar with Jenkins using Docker. The current quickstart process with Jenkins using the existing Docker examples can be complex and challenging for new users, with lots of docker commands to follow and hard-to-understand documentation. This project aims to address these issues and make it easier for users to get started with Jenkins.

More info can be found here.

Introduction

I am an IT undergraduate from India, I just gave my second year exams so I’ll be a third year student after this summer. I have a keen interest in DevOps and Cybersecurity. I heard of open source in my freshman year and loved the Idea of free and open software for all.

Why Jenkins?

I got to know of Jenkins while I was learning DevOps and after learning about Open Source I was eager to start contributing and be a part of a community. And Jenkins was built on Java which was the first language that I have learned. So I started to look into the Jenkins community. In the beginning, I couldn’t understand much about the issues and that’s where Hacktoberfest came into the picture. It was the push that I needed to submit my first PR, and I also got a T-shirt from the participation too. During Hacktoberfest the playlist about modernizing jenkins plugins by Mark Waite and Darin Pope was really helpful. After that I saw a post about Jenkins participating in GSoC 2023. That’s when I started to look into GSoC, and during preparation of the GSoC proposal the community helped me a lot and nudged me in the right direction to learn new things and reviewed my proposal.

Engaging with the community

I plan to give my all this summer to complete GSoC successfully and learn a lot of new things from the community, especially the communication part as I am not that good at it. I’ll give my all. And I hope that my contribution this summer can have a positive impact on the community. How I’d plan to be a part of community after GSoC:

  • I’d like to participate in events like Hacktoberfest to help others become part of the community.

  • I’d like to work on my original goal of improving my Java skills through contributions to the Jenkins core.

  • I’d like to adopt a plugin.

  • I’d like to participate in GSoC as a mentor in the future from Jenkins.

Conclusion

I want to thank the community for selecting me for GSoC 2023 and helping me to prepare for it. And special thanks to my mentors for giving their precious time and mentoring me this summer. I hope my contributions will be a useful addition to Jenkins. I’m looking forward to working with you all this summer!

↧
↧

End of life operating systems

May 31, 2023, 2:13 pm
$
0
0

Beginning with Jenkins 2.407, May 30, 2023, Jenkins administrators running a Jenkins weekly release will be warned if they are running Jenkins on an operating system that is within 6 months of its end of life date. The same warning will be visible to Jenkins administrators running a Jenkins long term support (LTS) release with the next LTS baseline after Jenkins 2.401.x, beginning August 23, 2023.

The warning includes the date when Jenkins will no longer be supported on that operating system version. It advises the administrator to upgrade to a newer version of the operating system.

Operating system end of life warning

Our Linux support policy states that the Jenkins project does not support, test, or accept pull requests for operating systems that are no longer supported by their provider.

Red Hat Enterprise Linux 7 and derivatives

Red Hat maintains Red Hat Enterprise Linux in accordance with the Red Hat Enterprise Linux Life Cycle. Red Hat Enterprise Linux 7 was initially released in 2014. It has been a very popular operating system thanks to its stability and long support life. That support life ends on June 30, 2024. A Red Hat blog post provides more details on the upcoming end of life.

Derivatives of Red Hat Enterprise Linux 7 like CentOS Linux 7, Scientific Linux 7, and Oracle Linux 7 will also no longer be supported after June 30, 2024. A CentOS project blog post shares their announcement of end of life.

The Jenkins project has decided to end its support of Red Hat Enterprise Linux 7 in late 2023 rather than waiting until 2024. After Nov 16, 2023, the Jenkins project will no longer support running Jenkins on Red Hat Enterprise Linux 7 or its derivatives. Jenkins container images based on CentOS 7 will no longer be supported after Nov 16, 2023.

Users should replace their Red Hat Enterprise Linux 7 installations with another operating system. If they prefer to continue with Red Hat or one of its derivatives, they have many alternatives, including:

Fedora Linux 36

The Fedora project maintains releases of Fedora Linux according the their release life cycle. Fedora 36 reached end of life May 16, 2023.

Users should upgrade their Fedora Linux 36 to Fedora Linux 37 or Fedora Linux 38.

Ubuntu Linux 18.04

Canonical maintains Ubuntu Linux in accordance with the Ubuntu lifecycle and release cadence. Ubuntu 18.04 reaches its end of standard support on May 31, 2023. The Ubuntu blog shares more details of the end of life and alternatives for users.

Users should upgrade their Ubuntu Linux 18.04 to Ubuntu Linux 20.04 or Ubuntu Linux 22.04.

Alpine Linux 3.14

Alpine Linux 3.14 reached its end of support on May 1, 2023 The Alpine releases page describes their support policy.

Users should upgrade their Alpine Linux 3.14 to Alpine Linux 3.15, Alpine Linux 3.16, Alpine Linux 3.17, or Alpine Linux 3.18.

↧

Jenkins May 2023 Newsletter

June 20, 2023, 11:13 am
$
0
0

Jenkins May Newsletter

Key Takeaways

  • Jenkins plugin updates released to fix security vulnerabilities, advisory published on May 16.

  • JDK8 support has been dropped in favor of JDK11 as the default for running Jenkins agents.

  • Ssh-agent release 5.0.0 introduces breaking changes.

Security Update

Contributed by: Wadeck Follonier

  • A Security Policy was added for the Docker images of the project.

    • Due to multiple reports about CVEs present in the Docker images the project was publishing, we wanted to clarify the situation.

    • Most CVEs do not impact the final application and do not require publishing justifications about the lack of impact on numerous CVEs every week.

  • One plugin advisory was published on May 16:

    • This included at least one high vulnerability in a very popular plugin.

Governance Update

Contributed by: Mark Waite

Several significant initiatives are already in progress within the Jenkins project.

Thanks to those who are leading the initiatives and thanks to those who are assisting with initiatives like:

  • Prototype.js removal from Jenkins core and Jenkins plugins. Contributing guidelines are in the blog post. Detailed issue reports are available in the JENKINS-70906: Jira epic. Progress reports for affected plugins are available in the tracking sheet.

  • HTMLUnit 3 upgrade in the Jenkins test harness, Jenkins core, and many Jenkins plugins.

  • Guava 32 upgrade

We’re also excited to have additional efforts in:

  • Reducing the core pull request evaluation time (and cost) with Launchable.

  • Using GitHub autolink for easier references to Jenkins Jira tickets.

Infrastructure Update Contributed by: Damien Duportal

  • The Cloud Cost Controls effort has continued by optimizing resource usage, resulting in:

    • Decreased the AWS bill of $ 3,000 (14,000 → 11,000).

    • Decreased the Azure bill of $ 2,000 to (11,000 → 9,000) despite adding resources.

  • Launchable is now generally available for community developers on ci.jenkins.io.

  • Jenkins LTS 2.387.3 was deployed everywhere less than 24 hours after it was released.

  • Ubuntu 22.04 upgrade campaign (18.04 is end of life) continued (6 more VMs, 5 VMs left).

  • Build workload migration to ARM64: internal tools.

User Experience Update

Contributed by: Mark Waite

The user experience SIG continues to improve the look and feel and the accessibility of the Jenkins user interface.

The Prototype.js removal from Jenkins core and Jenkins plugins has already shown us that additional UI capabilities will be available as we remove that old library. Dr. Ullrich Hafner has created a prototype of one of those enhancements in the data tables plugin.

Cristina Pizzagalli and Jan Faracik have both been working on improving accessibility for Jenkins users with disabilities. We particularly thank the usability and accessibility team at Deutsche Telekom IT GmbH for their JENKINS-71153: accessibility assessment report.

Platform Modernization Update

Contributed by: Bruno Verachten

  • Deprecation

    • Red Hat Enterprise Linux 7 (and derivatives) early end of life

      • To ensure a smooth transition, we are implementing several measures to inform users when an operating system is approaching its end of life. These changes will be visible in upcoming releases and container images.

      • Key Dates:

  • Ongoing work

    • Damien Duportal is actively working on code factorization, specifically targeting a single repository for all agent images.

      • This will streamline maintenance tasks, such as fixing CVEs.

      • The first phase for JDK versions has already been completed, resulting in significantly reduced code size.

      • Additionally, efforts are underway to merge two agents, aiming for synchronized release cycles. This change should not impact end users, except for the transition of the repository into an archive.

    • We can provide more frequent updates on the development of Alpine images thanks to the use of updatecli.

    • There is an ongoing discussion in the pull request regarding the switch of the Alma Linux container from version 8 to version 9.

  • What has been done

    • Updates on Docker Images:

      • Significant progress has been made on ppc64le. Thank you, Kenneth, for your valuable contributions!

      • PRs for docker-agent, docker-ssh-agent, inbound-agent, and the controller have been successfully merged.

      • Ssh-agent release 5.0.0 introduces breaking changes.

        • JDK8 support has been dropped in favor of JDK11 as the default for running Jenkins agents.

Documentation Update Contributed by: Mark Waite

We’re pleased to welcome several new documentation contributions, including our Google Summer of Code contributors:

We’re very pleased that these new Jenkins contributors have seen the value of documentation and have submitted documentation improvements.

We also welcomed first-time documentation contributors in May and are pleased to have their additions. Thanks so much to our documentation contributors.

Outreach and advocacy Update

Contributed by: Alyssa Tong

image

Every year, the community nominates and votes for three outstanding difference makers in the Jenkins community: Most Valuable Advocate, Security MVP, and Most Valuable Contributor. Congratulations go to:

Read what makes them outstanding contributors.

Many THANKS and congratulations to all award nominees!

image

The Continuous Delivery Foundation (CDF) hosted its fourth flagship event, cdCon, on May 8 – 9, 2023 in Vancouver, Canada as cdCon + GitOpsCon, co-organized with the Cloud Native Computing Foundation (CNCF).

Sessions from the most widely used CI/CD and GitOps technologies, including the Jenkins community, were there with project updates along with various talks from community members and users.

In case you missed it, below are the recorded Jenkins sessions at cdCon:

image

Jenkins welcomed four Google Summer of Code contributors to the family. Each contributor will be working hand in hand with their dedicated mentors. We’d like to introduce you to the Jenkins in GSoC contributors and the projects they will be making a difference on:

↧
Search

How to remove deprecated plugins from Jenkins while using Docker

June 20, 2023, 7:43 pm
$
0
0

The Jenkins plugin ecosystem is highly active, and it’s not uncommon to come across deprecated plugins. This can be both positive and negative. On the positive side, it signifies that the plugin is no longer necessary since its functionality has been integrated into Jenkins core or rendered obsolete by new features or technologies. On the downside, deprecation could indicate that the plugin is no longer maintained and considered unsafe.

However, removing deprecated plugins from Jenkins when using Docker can be a bit troublesome. This is due to the way the Jenkins Docker container functions. Whether you’re using the default container or a custom one, it runs on an image that comes with a predefined set of plugins. Even if you remove these plugins from the Jenkins UI, they are not completely removed from the container.

Now, you might be wondering how this works. Allow me to explain.

Let’s consider a scenario where we are utilizing a docker-compose.yaml file to define our Jenkins instance. Although there may be numerous services, our focus will be on the Jenkins controller at present.

#  docker compose up -d --build --force-recreateservices:jenkins:build:./controllerrestart:alwaysports:-"8080:8080"-"50000:50000"volumes:-jenkins-data:/var/jenkins_home:rw-./casc.d:/var/jenkins_home/casc.d/:ro-./secrets/id_jenkins.pem:/run/secrets/SSH_AGENT_KEY:roenvironment:-JENKINS_EXT_URL=http://localhost:8080-CASC_JENKINS_CONFIG=/var/jenkins_home/casc.d/-org.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true-PUBLIC_IP[...]

The Dockerfile for the Jenkins controller is as follows:

FROM jenkins/jenkins:2.401.1-lts-jdk17# [...]## Install custom pluginsCOPY --chown=jenkins:jenkins ./plugins.txt /usr/share/jenkins/plugins.txtRUN jenkins-plugin-cli --plugin-file=/usr/share/jenkins/plugins.txt
# [...]

To define the plugins we wish to install, we are utilizing a plugins.txt file. It is worth noting that some of these plugins may become deprecated in the future. For this example, we are utilizing the Bootstrap 4 API plugin, which has a dependency on the Popper API plugin. At the time of writing, both plugins have been deprecated.

At the beginning of the removal process, these two plugins are defined in the plugins.txt file.

[...]
# See https://github.com/jenkinsci/docker#usage-1
[...]
bootstrap4-api
[...]
popper-api
[...]

TL;DR

  1. Remove any references to the deprecated plugins in the plugins.txt file if you are using one.

  2. Rebuild the image.

    docker compose build jenkins

  3. Recreate your container if the rebuild was successful.

    docker compose up -d--build--force-recreate jenkins

  4. Optional: enter in the running container to check if the plugins references are gone.

    docker compose exec jenkins bash
cd /usr/share/jenkins/
cat plugins.txt |grep bootstrap

  5. Remove the plugins in the UI, as described in the next section.

  6. Restart by hitting the /safeRestart endpoint.

  7. Optional: remove the plugins' remnants from the docker volume.

    cd ~/plugins
ls-artl*[...]
-rw-r--r--   1 jenkins jenkins        8 Jun  6 13:05 bootstrap4-api.jpi.version_from_image
-rw-r--r--   1 jenkins jenkins        0 Jun  6 13:05 bootstrap4-api.jpi.pinned
-rw-r--r--   1 jenkins jenkins        9 Jun  6 13:05 popper-api.jpi.version_from_image
-rw-r--r--   1 jenkins jenkins        0 Jun  6 13:05 popper-api.jpi.pinned
drwxr-xr-x   6 jenkins jenkins     4096 Jun  6 13:05 bootstrap4-api
drwxr-xr-x   5 jenkins jenkins     4096 Jun  6 13:05 popper-api
[...]
rm-fr bootstrap4-api* popper-api*

Well done! You have successfully eliminated any deprecated plugins (at least for now). Keep up the good work!

The intuitive (but plenty wrong) approach

You can’t ignore the warning

If your Jenkins instance has deprecated plugins, you’ll notice a notification bell in the top right corner. Selecting it will display a warning message similar to this:

the following plugins are deprecated

It suggests you select Manage Jenkins to remove the deprecated plugins. Once in Manage Jenkins, you can’t ignore the warning:

the following plugins are deprecated once more

It’s a clear indication that we need to take action to address this situation.

Removing deprecated plugins in the UI

Follow these steps to remove the deprecated plugin:

  1. Select Plugins, then select Installed plugins.

  2. In the search box, enter the name of the deprecated plugin (in this case, it’s popper).

popper can t be uninstalled

Unfortunately, we encounter an issue as we are unable to uninstall it. The checkmark is greyed out, and the Uninstall button (red cross) is disabled. Why is that? Some plugins have dependencies on other plugins, which in turn have dependencies on additional plugins, creating a chain of dependencies. When you hover your mouse pointer over the uninstall icon (red cross), you’ll see a tooltip that indicates the parent plugin blocking the uninstallation:

what is the parent plugin blocking the uninstallation?

In this case, popper is a dependency for another plugin called bootstrap4-api. Therefore, we need to remove bootstrap4-api first and then proceed with popper.

Back to the drawing board search box, this time with bootstrap4-api.

bootstrap4 can be uninstalled

This time, we can uninstall it by selecting the uninstall icon (red cross). We will then encounter a warning message saying:

You are about to uninstall the Bootstrap 4 API Plugin plugin. This will remove the plugin binary from your $JENKINS_HOME, but it will leave the configuration files of the plugin untouched.

remove the plugin binary

Really? We’ll check that later. Select Yes to proceed with the uninstallation, and we’re back to the Installed plugins page. Let’s give another chance to popper by searching for it again:

popper can be uninstalled

Same player, shoot again. Follow the same steps as before to uninstall popper. After successfully uninstalling popper, you may notice that the notification icon still displays a message. Furthermore, if we go back to the Installed plugins page, we’ll see that popper is still there.

pending uninstallation

Why is this the case? We asked for an uninstallation, but it didn’t fully happen. Jenkins has to restart in order to complete the process. You can hit the /safeRestart endpoint to restart Jenkins safely and then select Yes. When you return, you will notice that the notification icon has disappeared, and the plugin is no longer listed on the Installed plugins page.

Removing deprecated plugins in the Docker context

However, depending on your Jenkins configuration, you may find that the deprecated plugins have somehow reappeared in your Jenkins instance, sometimes even with an older version. How is this possible? If your Jenkins container instance inherits from the Jenkins official container, it comes with a predefined set of plugins. Most of the time, these plugins won’t be enough for your specific use case. You will need to install additional plugins. When you do so, the new plugins are installed in the $JENKINS_HOME/plugins directory with a command such as:

COPY --chown=jenkins:jenkins ./plugins.txt /usr/share/jenkins/plugins.txtRUN jenkins-plugin-cli --plugin-file=/usr/share/jenkins/plugins.txt

So…​ Whenever you remove a deprecated plugin from the Jenkins UI, remember to remove it from the Docker context as well. Otherwise, it will be reinstalled when you rebuild the container. In my case, I had to remove the following plugins from the plugins.txt file:

# See https://github.com/jenkinsci/docker#usage-1
ant:487.vd79d090d4ea_e
[...]
bootstrap4-api:4.6.0-3
[...]
popper-js:2.9.2-1
[...]
ws-cleanup:0.45

Now you’re safe for the next time you rebuild your Jenkins container. But what about your running container? Is it free of any reference to the deprecated plugins? Let’s find out.

Removing deprecated plugins from the running container

Here is an excerpt of my docker-compose.yml file:

#  docker compose up -d --build --force-recreate
services:
    jenkins:
        build: ./controller
        restart: always
        ports:
            - "8080:8080"
            - "50000:50000"
        volumes:
            - jenkins-data:/var/jenkins_home:rw
            - ./casc.d:/var/jenkins_home/casc.d/:ro
        environment:
            - CASC_JENKINS_CONFIG=/var/jenkins_home/casc.d/
[...]
volumes:
    jenkins-data:

The jenkins-data volume is mounted on the /var/jenkins_home directory of the container. However, the /usr/share/jenkins/plugins.txt file, as we saw earlier in the Dockerfile, is not mounted on a shared volume.

I happen to have installed bash in my container, so I can run the following command to get a shell in the container (jenkins is the name of the service in the docker-compose.yml file):

docker compose exec-it jenkins bash

You can do the same with sh if bash was not installed in your Docker image. Now, let’s search for the plugins definition file. As we’ve seen in the Dockerfile, it’s located in /usr/share/jenkins/plugins.txt:

cd /usr/share/jenkins
cat plugins.txt |grep bootstrap4-api
bootstrap4-api:4.6.0-3

The reference to the deprecated plugin is still there. Is that a problem? No. As the documentation says:

When jenkins container starts, it will check JENKINS_HOME has this reference content, and copy them there if required. It will not override such files, so if you upgraded some plugins from UI they won’t be reverted on the next start.

So it’s there, but it won’t do any harm, it won’t be used…​ unless we restart Jenkins. Let’s leave it there, until the next time we rebuild the container, as we have already cleaned up the plugins.txt file used by the Docker context earlier.

Now what? Let’s have a look at the $JENKINS_HOME directory.

cd$JENKINS_HOME
find .-name plugins.txt

Nothing. We don’t have a plugins.txt file in the $JENKINS_HOME directory. Fine. What else? Can we find any remaining trace of the deprecated plugins? I’m afraid we can.

find .-name bootstrap4*
./plugins/bootstrap4-api
./plugins/bootstrap4-api/META-INF/maven/io.jenkins.plugins/bootstrap4-api
./plugins/bootstrap4-api/WEB-INF/lib/bootstrap4-api.jar
./plugins/bootstrap4-api.bak
./plugins/bootstrap4-api.jpi
./plugins/bootstrap4-api.jpi.version_from_image
./plugins/bootstrap4-api.jpi.pinned

There are still some traces of the bootstrap4-api deprecated plugin in the $JENKINS_HOME/plugins directory. What about the popper-js plugin? It’s there too. It may explain why despite having removed the deprecated plugins from the Jenkins UI, they were still there when we restarted the container. Let’s remove them for real this time:

rm-rf ./plugins/bootstrap4-api*rm-rf ./plugins/popper*

We can now safely exit the container and restart it from the UI by accessing the /safeRestart endpoint. Once we return, we should verify that the deprecated plugins are no longer present.

the following plugins are deprecated

Oh no! It seems like the deprecated plugins have reappeared in the running container. How did that happen? It’s because we only restarted the container without rebuilding it. The configuration still references the deprecated plugins.

Simply restarting the container repeatedly won’t resolve the issue. We need to rebuild the image after removing the deprecated plugins from the Docker context. Then, we can recreate the container and remove the deprecated plugins from the running container using the UI.

As a Jenkins admin, it’s important to go with the flow and avoid swimming upstream like a salmon. By following the proper steps, we can address this issue effectively.

Want to try it by yourself? Just follow the steps of the TL;DR section.

↧

New Public IPv4 for Jenkins Mirrors

June 22, 2023, 10:13 pm
$
0
0

The Jenkins project packages and plugins are hosted through a network of mirror servers (provided by our sponsors) close to your location.

It provides a "HTTP redirector" service hosted behind the get.jenkins.io, mirrors.jenkins.io and mirrors.jenkins-ci.org domains, with a new public IP (20.119.232.75) since the 12th of June 2023. The former redirector service and its previous IPv4 will be decommissioned the 27th of June 2023.

Please update your DNS servers and firewall rules to the new IP 20.119.232.75 if you are in a restricted environment.
More details in https://github.com/jenkins-infra/helpdesk/issues/3351.
↧
↧

Jenkins June 2023 Newsletter

July 11, 2023, 2:45 am
$
0
0

Jenkins June Newsletter

Key Takeaways

  • Red Hat Enterprise Linux 7, and derivatives like CentOS 7, reach early end of life.

  • Upgrades and improvements of Jenkins components continue with significant progress towards the eventual removal of Prototype.js from Jenkins core.

  • Thanks to a kind donation from Launchable, pull requests to Jenkins core now complete their evaluation builds in 2 hours rather than the 6 hours that were previously required.

Security Update

Contributed by: Wadeck Follonier

  • There was one security advisory published on June 14

    • 2023-06-14 Security Advisory

    • The security team discovered a vulnerability that was corrected as a (positive) side effect of a maintenance task. There is no new security release per se for Jenkins Core, but an advisory and associated warnings to let administrators know that an update is recommended.

    • That advisory also included fixes for plugins.

  • Expansion of the security audit scope in Jenkins Core

    • Originally the scope of the audit requirement was only “UI-related” changes.

    • But recently, there were multiple changes in JavaScript / Jelly without a UI impact, mainly for maintenance.

    • More information about this is in the Jenkins UX SIG - Agendas & Notes, for June 21.

  • Special thanks to the GitHub Security Lab for their reports

    • This is the second time in a row that vulnerabilities they reported were corrected in the advisory.

    • Kudos to Alvaro Muñoz and Tony Torralba for their work on this.

    • In collaboration with them, the Jenkins Security team will improve the CodeQL scanning tool.

Governance Update

Contributed by: Mark Waite

The Linux Foundation will upgrade issues.jenkins.io on Thursday, July 6, 2023. Special thanks to the Linux Foundation for their skilled administration of our JIRA instance. More detailed information is available on the status page.

The four Google Summer of Code projects mentored by members of the Jenkins project are preparing midterm presentations and midterm evaluations. The midterm webinar will be Thursday, July 6, 2023. A recording will be available as well along with the presentation slides.

Upgrades and improvements of Jenkins components continue, with significant progress towards the eventual removal of Prototype.js from Jenkins core. We’ve also seen upgrades for Guava, Guice, Apache commons.io, and HTMLUnit. Thanks to the providers of those libraries and special thanks to the Jenkins maintainers that are leading those upgrades.

Thanks to a kind donation from Launchable, pull requests to Jenkins core now complete their evaluation builds in 2 hours, rather than the 6 hours that were previously required. Launchable uses AI techniques to select a time-limited subset of tests, executed as part of pull request evaluation. Special thanks to Basil Crow for implementing Launchable in the Jenkins project.

The CDF Technical Oversight Committee elections have finished. The Jenkins project nominee, Mark Waite, has been elected to serve. We’re pleased that the Jenkins project continues to have representation on the committee.

Infrastructure Update Contributed by: Damien Duportal

  • The Cloud Costs Control effort continued:

    • We kept the AWS bill at $11,000 while the build workload of ci.jenkins.io increased by 15%.

    • We also decreased the Azure bill by $2,000 ($9,000 → $7,000) despite adding (more) resources.

  • For the build workload migration to ARM64: javadoc.jenkins.io is now proudly served by Azure ARM64 instances.

  • Jenkins LTS' 2.401.1 and 2.401.2 were deployed everywhere less than 24 hours after their releases.

  • Ubuntu 18.04 Bionic end of life: All of our VMs are now using Ubuntu 22.04, except the Update Center one.

  • Cloud Control:

    • The trusted.ci.jenkins.io and puppet.jenkins.io systems were migrated to Azure for security.

    • AWS is only used by ci.jenkins.io for container agents. This means no more EC2.

  • IPv6 support for get.jenkins.io and every other public services, thanks to their migration to a brand new AKS cluster with dual stack enabled.

User Experience Update

Contributed by: Mark Waite

User experience improvements continue thanks to the efforts of Markus Winter, Jan Faracik, Jan Meiswinkel, and others.

Markus is improving the look and feel of the delete dialog, so that it will be consistent and will appear within the web page as a modal dialog, rather than appearing outside the page as a browser dialog.

Jan Faracik continues to improve the look and feel of Jenkins pages, including recent improvements to the logs page and improvement in the cascading style sheets.

Platform Modernization Update

Contributed by: Bruno Verachten

Several platform updates occurred throughout June:

  • CentOS 7: Early End of Life announcement.

  • Docker Image Updates

    • Jenkins agent and controller images: Utilizing updatecli for image management. JDK17 version tracking for ssh-agent and Alpine Linux and JDK version tracking for the controller.

    • ssh-agent: Released versions 5.6.0 and 5.4.0 with JDK version tracking and other enhancements.

    • docker-agent: New release 3131.vf2b_b_798b_ce99-2 with updated dependencies and 3.18.2 Alpine Linux version.

    • docker-inbound-agent: Release 3131.vf2b_b_798b_ce99-2 with updated parent image.

    • Docker Controller: Release 2.411 with Jenkins 2.411 and security policy enhancements. Refer to the release notes for more details.

  • Docker Hub Stats

    • Monthly image exports are shared on this spreadsheet.

    • ArchLinux usage is low, but not deprecated.

  • Work in Progress

    • Windows image availability for the controller. The latest version: 2.410.

Documentation Update Contributed by: Kevin Martens

During the month of June, three blog posts were published on the Jenkins blog. This included the May newsletter, an update announcement for Jenkins mirrors, and instructions on removing deprecated plugins from Jenkins when using Docker.

The documentation has also started to transition to using Java 17 in the installation documentation for various platforms. The Linux installation documentation has been updated accordingly and includes a note regarding the Debian 12 release (as it does not deliver OpenJDK 11). This note will be present on any page that is part of the transition so that users are aware of the updates.

As always, we appreciate all the documentation contributions from new and existing users. Thank you for your work and dedication to the open source community!

↧

Post Mortem of the 7th July 2023 Jenkins Infrastructure Outage

July 12, 2023, 12:15 pm
$
0
0

On Friday 7th of July 2023, the Jenkins infrastructure suffered a major outage from 11:05am UTC until 15:25pm UTC with complete downtime of the following public services:

  • accounts.jenkins.io

  • fallback.get.jenkins.io

  • get.jenkins.io

  • incrementals.jenkins.io

  • javadoc.jenkins.io

  • plugin-health.jenkins.io

  • plugin-site-issues.jenkins.io

  • plugins.origin.jenkins.io

  • plugins.jenkins.io

  • rating.jenkins.io

  • repo.azure.jenkins.io

  • reports.jenkins.io

  • stories.jenkins.io

  • uplink.jenkins.io

  • weekly.ci.jenkins.io

  • www.origin.jenkins.io

We also had complete downtime of the following non-public services:

  • ldap.jenkins.io

  • previews of *.jenkins.io pull requests (infra.ci.jenkins.io)

In addition, there was disruption (partial or complete) of the following services:

  • ci.jenkins.io

  • infra.ci.jenkins.io

  • issues.jenkins.io

  • plugins.jenkins.io

  • repo.jenkins-ci.org

  • www.jenkins.io

The public IPs of these services changed (DNS records included) to:

  • 20.7.178.24 (IPv4)

  • 2603:1030:408:5::15a (IPv6)

⚠️ Update your corporate networks (DNS, proxies, firewall) if you need to access these services.

Incident Timeline

  • 10:30am UTC: After a successful upgrade of the public Kubernetes cluster in Azure to 1.25 (as part of help desk ticket 3582), we realized that the LDAP service was not reachable by the services running inside the cluster (such as accounts.jenkins.io). We quickly identified IP restrictions blocking these requests as the pod originating IP was in a different range than before.

  • 10:55am UTC: The fix (Azure PR 431) is deployed to specify a proper set of IP ranges for the pods. It removed all of the node pools (all the virtual machines where the container was running) and failed to re-create them, causing a full outage of all the services running in this cluster:

    • accounts.jenkins.io

    • get.jenkins.io

    • incrementals.jenkins.io

    • javadoc.jenkins.io

    • jenkins-wiki-exporter.jenkins.io

    • ldap.jenkins.io

    • plugins.jenkins.io

    • previews of *.jenkins.io pull requests (infra.ci.jenkins.io)

    • release.ci.jenkins.io

    • repo.azure.jenkins.io

    • reports.jenkins.io

    • stories.jenkins.io

    • uplink.jenkins.io

    • www.jenkins.io

  • 11:16am until 13:16pm UTC: The failure to re-create resources led us to spend the 2 next hours creating the cluster from scratch with a fixed network setup.

  • 15:17pm UTC:This pull request is pushed to persist the manual work we did to recreate the cluster including the IP setup.

  • 15:25pm UTC: All services are back to normal

What Happened?

  • When the cluster was initially created, we selected the 10.244.0.0/16 virtual network IP range (ref. Azure VNets) with a 10.245.0.0/24 sub-network (ref. Azure subnet).

  • But we ignored that the 10.244.0.0/24 range is the default CIDR for the Kubernetes Pods network in Azure when using the "kubenet" network to support IPv6 instead of the default CNI.

  • The node pool re-creation failed because we assumed both ranges were able to communicate and tried to deploy an invalid setup.

  • As soon as we specified a custom Pod CIDR in a distinct range, everything went fine.

  • When the original cluster was deleted it transitively removed the current Public IPs, as it removed the Nodes Resource Group containing the Public IP.

    • These public IPs should change as little as possible to avoid problems with our users running behind a corporate firewall with an allow-list.

What can we do to improve?

  • As per our initial assessment: protect the Public IPs from deletion by adding a Management Lock.

  • As recommended by other contributors: storing the Public IP in a distinct Resource Group and set up the Kubernetes-managed Load Balancers accordingly (annotation service.beta.kubernetes.io/azure-load-balancer-resource-group).

  • Improve our network diagrams and documentation to have better access to the representation and potential overlaps when preparing operations.

  • Avoid changing AKS node pools configurations all at once: we would have caught the issue after the first node pool and could have avoided a full outage (we are working on this topic for the arm64 node pools in PR-3623).

From 0 to production in less than 4 hours!

One of the takeaways of this outage, is that we are able to recover from a full destruction of the cluster hosting almost all public services in less than 4 hours.

It’s a huge collaborative work which allowed this: from defining the architecture, building the infrastructure, backing-up its data, etc.

This huge effort started years ago by R. Tyler Croy, Olivier Vernin and backed by a lot of contributors such as Daniel Beck, Hervé Le Meur, Tim Jacomb, Mark E Waite, Stéphane Merle and many more.

As current Infrastructure Officer, I want to thank them all so that our life is easier when catastrophic events happens!

↧

Third Party Repository Detection Probe

July 20, 2023, 1:24 pm
$
0
0

Introduction

A third-party repository is a repository that is not hosted at https://repo.jenkins-ci.org/.

The Jenkins Infra team was concerned about the dependencies used by third-party repositories. These repositories are a concern, not just for security reasons, but also for reliability.

The third-party repository detection probe ensures that plugins are built only from trusted and reliable Maven repositories.

Importance of the probe

This probe was requested by the community. In the ticket description, one of the plugin developers asked the Jenkins team to include a third-party repository in the plugin build. With the probe in place, the Jenkins team can now identify the plugins they should add to the build process.

Challenges

In a Maven project, all the dependencies are listed in the pom.xml file. A plugin can have multiple pom files, and each module may have its own pom. This means that there can be multiple child poms in the same repository.

A major challenge in this probe was considering the parent and child pom relationship from all angles.

Outcome

During code reviews and test cases, we noticed that there were assumptions made regarding Maven’s project hierarchies.

Furthermore, some edge-case scenarios were not considered while specifying the probe. Due to the number of open questions, this probe was put on hold until further research was completed. The goal of doing this was to adapt the project architecture to tackle the newly identified cases.

Learning

I implemented parameterized test cases to test the probe. Additionally, I extensively read the Maven documentation to understand how to test POM structure, inheritance, and Maven API.

Conclusion

This probe is currently partially completed, with approximately 60% of the code and test cases already implemented.

The objective is to create an efficient pom probe capable of aggregating all the parent-child pom relationships into a single file. By doing so, we can easily list the third-party repositories used in every pom file within the repository.

For more information or to find answers to any questions you might have, please visit the official GSoC 2023 project Adding Probes to "Plugin Health Score" description page.

↧
Viewing all 1088 articles
Browse latest View live
Search