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

GSoC 2024 contributor application ended. What happens next?

April 5, 2024, 12:43 am
$
0
0

Jenkins GSoC

The Google Summer of Code 2024 contributor application period has ended, and we are excited to have received several more than 75 valid applications from potential contributors interested in contributing to Jenkins via this program. We are grateful to all the students who applied and look forward to reviewing their applications over the next few weeks.

Over the past month or so, between March 18 2024 when the contributor application period opened and the end of the application period on April 2nd, 2024, the Jenkins project has been busy fielding candidate questions about the program, as well as reviewing some 40 odd draft proposals for GSoC hopefuls who have expressed interest in applying for the program. While due to privacy reasons we cannot share every detail about the ranking process that is done at Jenkins, we can share some insights into the process in general. Normally, all potential mentors are invited to grade each of the submitted proposals on a scale of 1 to 5, with 1 being a strong rejection and 5 being a strong acceptance. The Jenkins GSoC org admins then take the average of all the scores for each proposal and use that to rank the proposals. The top ranked proposals are then nominated by Jenkins to Google for further consideration. There might be some slight variations in this process, in that we also consider how each applicant interacts with fellow applicants during (and maybe even beyond) the application period, as well as how they interact with the Jenkins community in general. All-in-all, the ideal applicant would be something with an excellent proposal, usually one with a global grade of between 4 and 5, who has shown a willingness to engage with the Jenkins community, and who has shown a willingness to learn and grow as a contributor. Essentially, we would like to select the proposals that will have a high likelihood of succeeding.

We would like to take this opportunity to thank all applicants who have expressed an interest in applying for GSoC 2024 with Jenkins this year. Your contributions to the project are invaluable and have enhanced the community in many ways. We are looking forward to reviewing your proposals and working with the selected contributors over the summer.

We would also like to thank all the mentors who have volunteered to help with the program this year. We are grateful for your time and dedication to the Jenkins project. We are also grateful to the Jenkins community for their support and encouragement of the program.

↧
Search

Jenkins 2024 Community Award Winners

April 19, 2024, 7:43 am
$
0
0

cdCon 2024 just wrapped up in Seattle and this included announcing the winners of the Continuous Delivery Foundation and Jenkins Community Awards. The CD Foundation provides awards for the Top CDF ambassador, contributor, documenter, and end user. Anyone that is part of the CD Foundation can be nominated for these. Additionally, as a graduated project, Jenkins has three of its own awards:

  • Most Valuable Jenkins Advocate

  • Most Valuable Jenkins Contributor

  • Jenkins Security MVP

Thanks to everyone who nominated candidates and voted for the awards, these would not be possible without your participation. Furthermore, thanks to all the nominees for their work in Jenkins. The project thrives on the work of the community, and the award winners definitely represent this idea.

The 2024 Jenkins award winners are:

imageSecurity MVP: Yaniv Nizry

Yaniv reported two critical vulnerabilities towards the end of 2023 that the security team was able to utilize and publish fixes for. Yaniv’s reporting, response, and collaboration was exemplary for the Security team in addressing the issues and ensuring the fixes were complete and thoroughly tested. Without Yaniv’s work, these vulnerabilities could have lingered around longer than we would have liked. However, thanks to the efforts of both the Jenkins Security team and Yaniv, we were able to address and reassure users of the resolution.

imageMost Valuable Contributor: Stefan Spieker

Stefan has been a fantastic contributor to the Jenkins project and wonderful member of the Jenkins community for quite some time now. His contributions are numerous and can be felt through the performance and reliability Jenkins provides users. He has also worked to clean up older/deprecated code warnings, even helping Jenkins get to zero open SpotBugs issues. Stefan was also recently featured as part of the Contributor Spotlight, providing some further background on who he is and his work in the project.

imageMost Valuable Advocate: Darin Pope

Darin has provided hundreds of video tutorials for Jenkins users, with his Jenkins tutorials playlist on CloudBees TV covering over 300 topics of interest to Jenkins users. Many of the videos have been included in Jenkins documentation, including Installing on Red Hat Enterprise Linux, Installing on Microsoft Windows, Why Pipeline?, Extending Pipelines with Shared Libraries, and Pipeline best practices. Darin is the co-author of the Improve a plugin tutorial for Jenkins maintainers, which has been used to modernize many Jenkins plugins. Darin also hosts the "What’s new in Jenkins LTS" series that introduces the key features in each Jenkins long term support release.

imageCDF Continuous Enthusiast: Alyssa Tong

Finally, we want to announce that Alyssa Tong has won the CDF Community Award for Continuous Enthusiast. Alyssa has been attending the CDF Outreach meetings for years and helps drive important initiatives like Google Summer of Code for Jenkins, while also taking the time to share that knowledge with the rest of the CDF community. Alyssa is always advocating for and supporting the open-source community, representing the enthusiasm for CI/CD that pushes open source and Jenkins forward.

↧
↧

Congrats and Welcome to Jenkins in Google Summer of Code 2024 Contributors

May 2, 2024, 12:43 am
$
0
0

Congratulations and welcome GSoc 2024 Contributors

This year, we received numerous outstanding Google Summer of Code (GSoC) proposals for Jenkins with just as many compelling ideas. Many thanks to all who submitted their proposal(s) previously. Due to a very limited number of mentors available, we could only accept a small number of submissions. Congratulations go out to Danyang Zhao, Sridhar S, Shlomo Dahan, Nour Almulhem, and Phillipp Glanz for having been selected for Jenkins in GSoC 2024. It is now time to roll up our sleeves and get to the heart of why we’re doing this: to help make Jenkins a better project for all users.

In the next few weeks, contributors and project mentors will begin the “Bonding Period” to establish connections with the Jenkins community and to lay out the plans and framework for what is to come in the next 12 weeks. We are excited to have them on board and can’t wait to see their progress!

The 2024 Jenkins in GSoC projects are:

1) Manage Jenkinsci GitHub Permissions as Code - Automating the management of GitHub permissions for the Jenkinsci organization.

Mentors: Alexander Brandes, Bruno Verachten

GSoC contributor: Danyang Zhao

2) Using OpenRewrite Recipes for Plugin Modernization - Explore the ways OpenRewrite recipes can be used for Jenkins plugin modernization or automation of plugin build metadata updates.

Mentors: Valentin Delaye, Bruno Verachten, Bervianto Leo Pratama, Rajiv Singh

GSoC contributor: Sridhar S

3) Implementing UI for Jenkins Infra Statistics - To build upon the current GitHub Pages based UI into a user-friendly and full-featured website for showcasing Jenkins Infra statistics.

Mentors: Kris Stern, Vandit Signh, Herve Le Meur

GSoC contributor: Shlomo Dahan

4) Enhancing an Existing LLM Model with Domain-specific Jenkins Knowledge - To develop an app using an existing open-source LLM model with data collected for domain-specific Jenkins knowledge that can be fine-tuned locally and set up with a proper UI for the user to interact with.

Mentors: Kris Stern, Harsh Pratap Singh, Shivay Lamba, Bruno Verachten, Laura Lopez Real

GSoC contributor: Nour Almulhem

5) Improve Maintainability for the Repository Permission Updater - Automating the management of GitHub permissions to improve maintainability for the Repository Permission Updater for Jenkinsci.

Mentors: Alexander Brandes, Bruno Verachten, Rajiv Singh

GSoC contributor: Phillipp Glanz

↧

Jenkins in Google Summer of Code Community Bonding, Contributors' Takeaways

June 4, 2024, 5:13 pm
$
0
0

The community bonding period is the three weeks between GSoC contributor acceptance and the start of the coding date. This is a vital time for mentors and org admins to engage with GSoC contributors and set them up for success. This is the time to set expectations and milestones, welcome the contributors to the community, and give them access to the tools they need to succeed during the coding period.

Given that May 26, 2024, marked the end of the bonding period, we asked the GSoC contributors to share their key takeaways from this period. Here’s what they had to say:

  • Implementing UI for Jenkins Infra Statistics | contributor: Shlomo Dahan

    1. Establish a communication schedule: Set up regular meetings with mentors early on. Knowing how often to meet and discuss progress will help keep you on track and ensure you are receiving timely feedback.

    2. Understand the codebase: Understanding the project’s codebase and infrastructure is crucial. This will help you make informed decisions when you are planning out your roadmap.

    3. Create a project roadmap: Having a clear roadmap will ensure that you stay organized throughout your coding period. Set specific milestones and deliverables to always have a tangible goal to work towards.

    4. Utilize downtime efficiently: Don’t get stuck waiting for answers. Mentors are often busy and might not always respond immediately. In the meantime, work on other tasks to ensure you always have multiple items to tackle. This approach will keep your project moving forward.

  • Manage Jenkinsci GitHub Permissions as Code | contributor: Danyang Zhao

    1. Use various communication tools: Don’t rely solely on weekly meetings. Keep the dialogue open through emails, Gitter, or other accessible communication platforms.

    2. Seek help: If you encounter a challenging issue, seeking help is a good strategy. Reach out to your mentor, co-mentor, or even other community members. They are all willing to assist.

    3. Communicate schedules clearly: If unexpected commitments arise, such as exams, inform your mentor. Communication is important.

  • Improve Maintainability for the Repository Permission Updater | contributor: Phillipp Glanz

    1. Be aware of scheduling: It is important to communicate in order to be able to plan better in the event of scheduling conflicts or exams.

    2. Communication is key: Open and direct communication is necessary to get feedback at an early stage, as this prevents duplication of work.

    3. Deliberate planning helps organize work: Precise agreement on who does what and precise delimitations make the process much more efficient.

  • Enhancing an Existing LLM Model with Domain-specific Jenkins knowledge | contributor: Nour Ziad Almulhem

    1. Enhanced understanding of project goals and tools: We spent time comprehending the scope and objectives of the project. I learned how to effectively use tools to collect a dataset of Jenkins-specific knowledge provided by stack exchange, community questions, and Jenkins documents. This foundational knowledge is crucial for the successful implementation of the project.

    2. Community engagement and support: I experienced the importance of community interaction. Engaging with mentors and organization admins helped me feel supported. This engagement provided me with the confidence and motivation to tackle the project, discuss my contribution during the final exams, and speak out loud about the help I need at any time.

    3. Preparation and planning: The bonding period allowed me to prepare and plan for the coding phase effectively with mentors and define our goals and milestones. We focused on data collection, processing strategies, and discussing various approaches to achieve the objective of the project.

  • Using OpenRewrite Recipes for Plugin Modernization | contributor: Sridhar Sivakumar

    1. Define expectations and goals: Refine the proposal and prepare clear expectations and goals for the project, such as defining the project’s scope, setting milestones, and outlining the deliveries. This will significantly aid in preparing the roadmap.

    2. Bonding with the community: The bonding period is not only to interact with the mentors but also with other community members. It is always good to share your thought process and ideas with other community members via blog posts.

    3. Report your blockers: Communication is the key to a successful project. Discuss any obstacles you encounter, such as exams or other personal issues with the mentors or Org Admins.

↧

Jenkins requires Java 17 or newer

June 11, 2024, 12:13 pm
$
0
0

Summary

Jenkins requires Java 17

Beginning with the Jenkins 2.463 weekly release (scheduled for release on June 18, 2024), Jenkins requires Java 17 or newer. The Jenkins 2.452.x LTS line will continue to require Java 11 or newer, as will the LTS line (possibly 2.462.1) that is scheduled for release on July 24, 2024, whose baseline will be 2.462 (the last weekly release to support Java 11) or earlier. The first LTS release to require Java 17 or newer will ship at the end of October 2024.

The Jenkins core team generally recommends that all users adopt Java 17 or Java 21. In recent months, usage of Java 17 has almost surpassed usage of Java 11, and usage of Java 21 is rapidly increasing:

JVMs by Date

Weekly releases will require Java 17 or newer earlier than a previously announced date. The motivating factor for this change of schedule is the August 31, 2024 EOL of the Spring Framework 5.3.x line. Jenkins relies heavily on Spring Security, and upgrading to the 6.x line necessitates a slew of breaking changes, including migrating to Java 17, Jetty 12, and Jakarta EE 9. In order to mitigate risk, we are beginning the rollout of Java 17 in the June 18, 2024 weekly release. Further details about the migration to Jetty 12 and Jakarta EE 9 are forthcoming.

Upgrading to Java 17 or 21

Beginning with the Jenkins 2.463 weekly release (scheduled for release on June 18, 2024), Jenkins requires Java 17 or newer on both the controller JVM (i.e., the JVM running jenkins.war) and agent JVMs (i.e., JVMs running remoting.jar).

This does not imply that you need to build your application with the same version of Java. You can continue to use any desired JDK to build your application, as long as the JVM used for running Jenkins itself is version 17 or newer. For example, the Global Tool Configuration page can still be used to provide a JDK 8 or 11 installation for building your application. Similarly, you can set up ephemeral or static agents with two installations of Java: Java 17 or newer to run remoting.jar for Jenkins and Java 8 or 11 to build your application.

We have supported running the controller on Java 17 since the Jenkins 2.355 weekly release, and we have supported running the controller on Java 21 since the Jenkins 2.419 weekly release. Prior to the Jenkins 2.463 weekly release, running the controller on Java 17 and agents on Java 11, though not recommended, did not result in errors. Beginning with the Jenkins 2.463 weekly release, running the controller on Java 17 and agents on Java 11 will result in the following error:

java.lang.UnsupportedClassVersionError: hudson/slaves/SlaveComputer$SlaveVersion has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1022)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:883)
	at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:473)
        ... 24 more

Therefore, it is critical to upgrade both the controller and agents to Java 17 or newer prior to upgrading Jenkins to the 2.463 weekly release. Use the Versions Node Monitors plugin to verify that agents are running a compatible version of Java.

Docker images

The official Jenkins Docker images for the controller and agents have been based on Java 17 for many months, with Java 11 available as a fallback. Beginning with the Jenkins 2.462 weekly release, the Java 11 images will be retired. (Java 11 images will remain available for the LTS line until October 2024.) Users of the official Jenkins Docker images need not install or configure Java on their own, as it comes preinstalled in the image.

If you are using a Docker image to run both the agent Java process (i.e., remoting.jar) and your own application build and your application build still requires Java 8 or 11, you will need to provide a Java 17 or newer runtime for the Jenkins agent process and a Java 8 or 11 environment for your application build.

OS packages

Users of the official Jenkins OS packages for Debian, Red Hat, and SUSE Linux distributions should note that these packages are agnostic to the Java vendor. In other words, you must bring your own Java package. One straightforward way to do this is to install Java 17 from your Linux distribution, as described on the package download site:

Debian

apt-get install fontconfig openjdk-17-jre

Red Hat

yum install fontconfig java-17-openjdk

openSUSE

zypper install dejavu-fonts fontconfig java-17-openjdk

By virtue of not requiring any custom repositories, this is certainly the simplest method (and the one used by the Jenkins project’s packaging tests), but it does not give the user a high degree of control over the Java runtime environment. As mentioned previously, the official Jenkins Docker images use Adoptium/Eclipse Temurin (as does the Jenkins infrastructure project). Enthusiastic users may wish to install Java from Adoptium or another vendor. Since 2021, Adoptium has provided Linux installation packages, as described in a piece by George Adams. Ultimately, the choice of which Java vendor to use is your own, as long as that vendor provides Java 17 or Java 21. Refer to your chosen Java vendor for installation instructions.

Once you have installed a suitable version of Java, configure Jenkins to use that Java runtime. The most straightforward way is to configure that version of Java as the default version of Java at the operating system (OS) level:

Debian

update-alternatives --config java

Red Hat

alternatives --config java

openSUSE

update-alternatives --config java

Alternatively, users who do not wish to change the default version of Java can customize the JAVA_HOME or JENKINS_JAVA_CMD environment variable as part of the Jenkins systemd(1) service unit. Refer to the Managing systemd services section of the Jenkins documentation for more information.

Reporting issues

If you find a regression in a plugin, please file a bug report in Jira:

When reporting an issue, include the following information:

  1. Use the JENKINS-67907 epic.

  2. Provide the output of java -version (e.g., OpenJDK 64-Bit Server VM Temurin-21.0.3+9 build 21.0.3+9-LTS)

  3. Provide the name, version, and architecture of the operating system you are using (e.g., Ubuntu 24.04.1 LTS x86_64).

  4. Provide the complete list of installed plugins as suggested in the bug reporting guidelines.

  5. Provide the complete stack trace, if relevant.

  6. Provide steps to reproduce the issue from scratch on a minimal Jenkins installation; the scenario should fail on Jenkins 2.462 or earlier when the steps are followed on Java 17 or Java 21 and pass when the steps are followed on Java 11.

Conclusion

We expect to see a bit of disruption from the migration to Java 17, Jetty 12, and Jakarta EE 9, but we hope that in the long term these changes will be in the best interests of the Jenkins community. Please reach out on the developers' list with any questions or suggestions.

↧
↧

Thanks to the Jenkins mirror providers

June 14, 2024, 12:13 am
$
0
0

Jenkins downloads are provided by mirror servers of organizations that support the Jenkins project.

You can see the list from the mirror status page.

We’re really grateful for all the support provided by the organizations behind the curtain, namely:

In particular, we are happy to add a new sponsored mirror from Hostico. This new mirror covers Eastern Europe and Russia.

Many thanks to Hostico and to the administrators of the RWTH Aachen University mirror for their great help in the past weeks!

↧

Amazon donates $60,000 to Jenkins

July 25, 2024, 6:43 am
$
0
0

image

Amazon Web Services has donated $60,000 in cloud credits to the Jenkins project. We are especially grateful for their donation and their support of Jenkins.

The Jenkins project has used AWS for many years to provide a wide range of services. AWS provides the central distribution point for Jenkins core and Jenkins plugin downloads through the Jenkins update center. We’ve used AWS Graviton servers (Arm architecture) and AWS Intel servers with the Amazon Elastic Kubernetes Service and as Elastic Compute Cloud virtual machines. AWS has provided consistent, reliable, and scalable services for Jenkins for many years.

We are sincerely grateful for Amazon’s most recent contribution to the Jenkins project and thank them for their support of open source software.

↧

Microsoft donates $60,000 to Jenkins

July 26, 2024, 7:43 am
$
0
0

image

Microsoft Azure has donated $60,000 in cloud credits to the Jenkins project. We thank them most sincerely for their donation and for their continuing support of open source software projects like Jenkins.

The Jenkins project uses Microsoft Azure cloud to provide a wide range of services, including all the Jenkins controllers that build Jenkins core, Jenkins components, and over 1000 Jenkins plugins. Microsoft Azure provides scalable and resilient services for Jenkins continuous integration and continuous delivery processes through Azure Kubernetes Service (AKS) and Azure Container Instances (ACI).

The Jenkins project also uses Microsoft Azure hosted database services including Azure Cache for Redis, Azure Database for PostgreSQL, and Azure Database for MySQL. We use both Intel based servers and Arm based servers and rely on Microsoft premium file storage and multi-zone storage.

We’re sincerely grateful for Microsoft’s most recent contribution to the Jenkins project and thank them for their support of open source software.

↧
Search

Jenkins Board and Officer Elections 2024 - Nominations Open

August 1, 2024, 11:45 am
$
0
0

We are excited to announce the 2024 Jenkins Governance Board and Officer elections!

Nominations

Nominations can be submitted for governance board positions and all officer positions (Security, Events, Release, Infrastructure, and Documentation).

During the registration period, we invite community members to nominate candidates by sending a message to the election-committee group. In your message, please include the name of the nominee, the specific position and your reasons for nominating that person. A tutorial is available that shows the steps to nominate a candidate.

The nomination period ends on September 15. Nominees will be notified and asked to confirm that they are interested in running as a candidate. The list of candidates will be announced on September 16.

Anyone can nominate anyone as a candidate!

Many thanks to Dr. Ullrich Hafner and Alexander Brandes for serving on the Jenkins Governance Board. We also want to thank Damien Duportal as Infrastructure Officer, Wadeck Follonier as Security Officer, Alyssa Tong as Events Officer, Tim Jacomb as Release Officer, and Kevin Martens as Documentation Officer for all of their work over the last term.

The election consists of 4 phases:

  • Nomination of candidates (August 1 - September 15)

  • Voter registration (September 16 - October 31)

  • Voting (November 1 - November 30)

  • Results announcement (December 1)

Voting

Participation in the election process requires registering an account on the Jenkins community forums and at least one contribution made before September 1, 2024. When registering, you can use an existing GitHub account or create a new account specifically for Jenkins community forums. We ask all community members who are interested in voting and meet the requirements to join the election-voter-2024 group during the registration period. Previous elections utilized their own groups, so joining the election-voter-2024 group is required for participation.

We have made the decision to trust participants and not require that you provide evidence of contribution as part of your voter registration. We reserve the right to ban any account from the election process if we identify abuse. Once registration is over, a list of email addresses will be sent to the Condorcet Internet Voting Service (CIVS).

Contributing

As shown on the Participate and Contribute page, there are many different ways to contribute to Jenkins. You can contribute by:

All contributions to Jenkins and its community are welcome

Election

Candidates will be announced September 16. Voter registration closes on October 31. Voting begins November 1. Registered voters will be notified by email to participate using the Condorcet Internet Voting System. All votes must be submitted by end of day November 30.

Results

Election results will be published December 1. The new term starts on December 1, when the newly elected members will transition to their roles.

Important Dates

Important DatesTime

Nomination of candidates open

August 1

Nomination of candidates closes

September 15

Voter registration opens and candidates announced

September 16

Voter registration closes

October 31

Voting starts

November 1

Voting closes

November 30

Results announced

December 1

Troubleshooting

If you are new to Jenkins elections, unfamiliar with the Condorcet Internet Voting Service (CIVS) or the community forums, or feel overwhelmed with the process, don’t worry, we’ve got you covered. We published a step-by-step guide, outlining how to to join the election-voter-2024, activate your CIVS account and cast your vote.

If you encounter issues still or need assistance, don’t hesitate to contact the election committee.

Thank you, as always, and don’t forget to register to vote by October 31!

↧
↧

Enhancing an Existing LLM Model with Domain-specific Jenkins Knowledge

September 1, 2024, 11:45 am
$
0
0

Jenkins GSoC

Table of Contents

  1. About the Project

  2. Milestones

  3. JenAI as a System

  4. Next Steps

  5. Acknowledgments

  6. Useful Links

About the Project

JenAI is a pioneering chatbot that is trained specifically to answer users' queries about Jenkins technology, which enhances the accessibility and usability of software.

We aim to provide faster and more reliable assistance to our users. The model is integrated with a friendly UI to ensure a better user experience.

The project outcomes are:

  1. Collected datasets from different sources, like Jenkins blogs, community questions, and other external sources.

  2. Preprocessing this dataset to make sure it is clean and not confusing the model.

  3. Fine-tuning llama2 on this data and providing a new open-source fine-tuned model.

  4. Creating a user interface with a small server to interact with the model.

  5. Providing documentation of all the work done and a user guide to use our chatbot locally on your machine.

Why JenAI:

  • Jenkins currently does not have AI-driven assistive technology to help new Jenkins users.

  • This project combines Jenkins knowledge with AI to assist all users with the knowledge that a Jenkins expert usually has, providing a complete solution.

  • We empower users to interact with this knowledge through a smooth UI instead of looking for your answer here and there.

Milestones

This project included several stages that we have gone through:

Stage #1: data collection

Different sources were used to collect Jenkins knowledge, including Jenkins documentation and blog posts, discourse community questions, and many external sources like Stack Overflow, ask Ubuntu, and Stack Exchange.

Stage #2: data preprocessing and refinement

This stage consisted of 3 parts:

  • The first part is utilizing another large language model to help us generate question-answer pairs out of Jenkins documentation.

  • The second part is using Stack Exchange queries to get datasets of questions and correct solutions asked on Stack Overflow and many other platforms. We could define a score threshold for those questions and answers to ensure the reliability of the dataset we are collecting. The dataset generated includes HTML tags like paragraph code and many un-useful blocks or urls, so further processing was done to remove all useless information.

  • The last part of this is utilizing the community questions available on Discourse, where we could use discourse apis to prune Jenkins posts and retrieve ones with approved solutions, then we could do another request to retrieve those posts and their answers.

All those parts are automated, and the notebooks for creating the datasets are provided on our repository. In doing so, we managed to collect around 4100 pairs; a bunch of which were used to fine-tune our model on.

Stage #3: JenAI as a system

This stage was about creating software with a friendly user interface as part of this project to interact with the model. We used ReactJS, Typescript, and MUI components to help us create the interface.

We also used Flask to create a small server with only one endpoint (so far) to interact with the model through Rest API and ensure smooth communication.

Stage #4: Fine-tuning

The core of our project, the effort of fine-tuning, was iterative and repeated until we made sure of its performance. A lot of research is conducted here to ensure the optimal parameters and the best approach to fine-tuning the model and obtaining accurate results.

We were using Colab and Kaggle free resources to fine-tune our model as they provide a T4 GPU with around 16 gigabytes of VRAM, which is powerful enough to load and fine-tune our model.

Details of fine-tuning, the approach, and parameters are provided in our Final Documentation.

Stage #5: Convert the model to GGML format and quantization

In order to achieve our objective, we need users to be able to run the model on their local machines using only CPUs instead of hosting it. To achieve this, we used llama.cpp to convert the model to a GGML binary format (using convert_hf_to_gguf.py) that can be loaded and run on CPU.

Part of the appeal of the GGML library is being able to quantize this binary model into smaller models that can be run even faster. There is a tool called quantize in the Llama.cpp repo that can be used to convert the model to different quantization levels. We used the quantize tool to shrink our model to q8_0.

JenAI as a System

  • JenAI landing page in dark mode

LLM Landing Page Dark Mode

  • JenAI landing page in light mode

LLM Landing Page White Mode

  • JenAI chat page

LLM Chat Page

Next Steps

This idea can be enhanced more, and many approaches are provided to achieve the same goal:

  • Using retrieval-augmented generation (RAG) that combines the strengths of databases or traditional information retrieval systems with the capabilities of large language models.

  • Llama3 that has been pre-trained on over 15 trillion tokens, with a dataset used in training 7 times larger than the one used for training Llama2, which can make it outperform Llama2 when fine-tuning on Jenkins knowledge.

Acknowledgments

I want to take this chance and extend my gratitude to:

  • Google Summer of Code for organizing this and their mentors who provided help throughout the program.

  • Jenkins and GSoC org admins for having me contribute to this challenging problem and thank you for your flexibility along the way.

  • My team mentors Kris Stern(as a lead mentor), Bruno Verachten, Harsh Pratap Singh, and Shivay Lamba for their continuous support and guidance throughout the project, answering my questions, and pointing out some great ideas so we are not left with something incomplete. They were a great reason for making this a success.

Conclusion

In conclusion, being a part of GSoC 2024 was an amazing experience that enabled me to gain new skills and make meaningful contributions to an open-source project. I am excited to continue contributing at Jenkins in the future.

↧

GSOC Manage jenkinsci GitHub permissions as code

September 1, 2024, 11:45 am
$
0
0

This blog showcases all the work done in the Manage jenkinsci GitHub permissions as code project during Google Summer of Code 2024.

About the Project

This project aims to create a solution that allows the Repository Permission Updater (RPU) to manage jenkinsci GitHub permissions as code. RPU is a vital tool used by Jenkins to manage artifactory permissions, bridge discrepancies between Jira and GitHub issues, and enable automatic releases. Currently, RPU oversees over 2600 GitHub teams, with all team modifications handled manually by the hosting team. Automating these processes aims to significantly enhance productivity by reducing the manual workload.

In Jenkins, there is a strategy of using teams to manage permissions effectively. Teams are categorized into two types:

Repository Teams are directly linked to specific repositories. The names of these teams typically follow the format $repo_name + Developers and they automatically assume the admin role. The developers in these teams are managed within the "permissions" section.

Additional GitHub Teams, in contrast to repository teams, oversee multiple repositories without being attached to any particular one. The roles of these teams can vary, depending on the needs of the repositories they manage. The developers in these teams are organized within the "teams" section.

To enhance the management of these two distinct team types, it is necessary to modify the current YAML structure.

Changes to YAML structure:

Before:

permissions/*.yml

...developers:-"user1"-"user2"...

teams/*.yml

---name:"core"developers:-"user1"-"user2"...

After:

permissions/*.yml

...developers:-ldap:"user1"github:"user1"-ldap:"user2"github:"github_user2"repository_team:"example-repoDevelopers"additional_github_teams:-name:"core_team"role:"admin"...

teams/*.yml

---name:"ux"github_team_name:"sig-ux"developers:-ldap:"user1"github:"user1"-ldap:"user2"github:"github_user2"...

Phase 1

Successfully implemented the foundational goals outlined in the proposal.

YAML structure:

...developers:-"user1"-"user2"github_team:"example-repoDevelopers"

Skills Developed:

  • SnackYAML

  • GitHub API

  • Jenkinsfile

  • Docker

Phase 2

After initial implementations, I engaged in discussions with the hosting team to address real-world challenges and adapt our project accordingly.

YAML structure:

permissions/*.yml

...developers:-"user1"-"user2"repository_team:"example-repoDevelopers"additional_github_teams:-name:"core_team"role:"admin"...

teams/*.yml

---name:"ux"github_team_name:"sig-ux"developers:-"user1"-"user2"...

Skills Developed:

  • GitHub Actions

  • Java GitHub API

  • Testing with Mockito and JUnit

  • Introductory Terraform

Next steps

The development of this project has followed a complex path, shaped by real-world challenges encountered in Phase 2 that diverged from our initial plans. As we progress, several improvements remain to be addressed to ensure that our solutions effectively meet real-world needs.

  1. Due to potential discrepancies between LDAP and GitHub usernames, the YAML structure has been adjusted to include both.

  2. Terraform will be integrated to bolster security and streamline management across GitHub workflows.

  3. A one-off backfill process will be implemented to synchronize data from GitHub with YAML configurations before the initial deployment, ensuring consistency.

Summary

I am grateful for the opportunity to be a part of this project; without it, my amazing journey at Jenkins would not have been possible. Special thanks to my mentor Alexander Brandes for his support throughout the process. I also owe a lot to the org admins, particularly Alyssa Tong, who not only adjusted her schedule to overcome time zone differences but also provided invaluable guidance in project management, Kris Stern was always there to assist with development challenges, offering as much help as she could, and lastly, thanks to Bruno Verachten for his support.

↧

Using OpenRewrite Recipes for Plugin Modernization

September 1, 2024, 11:45 am
$
0
0

This blog showcases the work done on the Plugin Modernizer Tool during the Google Summer of Code 2024. For a detailed description of the project, please refer to the project page.

Jenkins GSoC

Table of Contents

  1. About the Project

  2. Phase 1

  3. Phase 2

  4. Next Steps

  5. Acknowledgments

  6. Useful Links

About the Project

This project aims to build a generic tool to automate the modernization of Jenkins plugins using OpenRewrite.

This tool allows us to apply OpenRewrite recipe transformations across Jenkins plugins, validate the changes, and create pull requests in the respective plugin repositories.

This tool also extracts and stores essential metadata that can be consumed by Plugin-Health-Scoring for building more probes. For example, it can identify transitive dependencies and issue warnings if a plugin doesn’t use an API plugin as recommended.

Phase 1

In this phase, we accomplished following tasks:

  • Developed a CLI module to parse arguments.

  • Created a scanning recipe to extract metadata.

  • Developed a core module using Maven invoker to apply recipes across plugins.

Feel free to watch the demonstration of the tool in the Midterm Presentation.

Phase 2

In this phase, we accomplished the following tasks:

  • Developed a GitHub service for forking, cloning, committing, and creating pull requests.

  • Integrated OpenRewrite recipes to the tool.

  • Added a caching mechanism.

  • Improved the tests and documentation.

Next Steps

  • Integrating more recipes into the tool, allowing us to apply a wide range of changes across the Jenkins ecosystem.

  • Storing the extracted metadata in a common location so that it can be used by other projects, such as Plugin Health Scoring.

Acknowledgments

I extend my sincere thanks to my mentors, Valentin Delaye, Bruno Verachten, Rajiv Ranjan Singh and Bervianto Leo Pratama as well as the organization admins, for their invaluable guidance, support, and patience throughout this journey.

I also want to thank Basil Crow for introducing the initial project idea titled Automating plugin build metadata updates.

↧

See what's next for the Jenkins user interface - DevOps World 2024

September 1, 2024, 11:45 am
$
0
0
This is a speaker blogpost for a DevOps World 2024 talk.

We last gave a talk about the Jenkins user experience at DevOps World 2022. Two short years later, we’re back to showcase what’s new and upcoming in the world of Jenkins UX.

We’ll discuss how we’re bringing the best of BlueOcean back to Jenkins, a redesigned builds widget, a new search experience, and more. Expect to hear about the lessons we’ve learned and the challenges we’re tackling as we update Jenkins for the modern web.

We can’t wait to show you what’s next.

Register online to join us virtually at 1:30pm ET on September 17th, 2024.

If you want to get involved in the UI and UX discussions of Jenkins join the User Experience SIG.

Take advantage of new components and patterns in your plugin via the Design Library.

You can watch our monthly meetings on YouTube and you can view in-progress work on GitHub.

↧
↧

Brownout on Update Center (updates.jenkins.io): 6 and 9 September 2024

September 5, 2024, 6:43 pm
$
0
0

Summary (TL;DR)

The service https://updates.jenkins.io will switch its implementation to a new system during 1 hour twice:

  • Friday 6 September 2024 from 07:00am UTC until 08:00am UTC

  • Monday 9 September 2024 from 02:00pm UTC until 03:00pm UTC

All Jenkins users are impacted but should not see any functional change.

⚠️ Please, check that your organization respects the advertised DNS TTL or you might be stuck in the brownout longer that expected.

Under the hood, any HTTP request made to this service will be redirected to a mirror close to user locations during these brownouts.

What is the "Update Center"?

Jenkins Update Center is a web server at the core of the Jenkins public infrastructure which distributes the plugins, tool installers, and versions index to all Jenkins servers all across the world.

From the Wizard installation to regular plugin updates, if you run Jenkins then you use this service under the hood.

Today, it serves around 50 Tb of data (outbound bandwidth) each month from a single Virtual Machine on AWS, which costs around $6,000 per month.

In order to sustain this service and improve it, the Jenkins infrastructure team has worked relentlessly during the past years to have a new sustainable implementation for this service.

The new Update Center implementation features a highly available system, which redirects user requests to a download mirror close to their location. There is lots of details and additional information that you can read further about in the following GitHub issue.

Why this "Brownout"?

We have reached the point where our functional/performance tests are meeting our expectation:

  • All of our Jenkins controllers are using the new Update Center implementation.

  • We are using the new updates center (with DNS override) in our own networks in different geo-locations.

  • All of our Jenkins Docker image are using the new system.

  • Our initial performance tests

But as the adage says: "No plan survives first contact".

That’s why we are planning these brownouts of one hour each to:

  • Validate our system beyond the tests we already ran to increase trust.

  • Run a real life (production!) workload against the new system while limiting any unforeseen impact due to the short time window.

How

Both current and new Update Centers are updated at the same time and serve the same index.

Starting 4 weeks ago, the Jenkins infrastructure has been using the new Update Center (https://azure.updates.jenkins.io) with a client-side DNS override (updates.jenkins.io hostname points to this new service).

During the brownouts, we’ll simply switch the DNS entry updates.jenkins.io to this new service and watch for the logs and error rate. At the end of each brownout, we’ll switch DNS back to the normal service and then analyze metrics and logs to see how the system behaved.

  • If no major problem is detected then we’ll plan a 24 hours brownout soon.

  • Otherwise we’ll analyze the discovered problem and plan solutions.

The first brownout covers Asia + Europe "activity" timezones while the second covers US + Europe so we can have 2 distinct set of usages.

Please refer to the helpdesk ticket for more information.

↧

Brownout on Update Center (updates.jenkins.io): 11 and 12 September 2024

September 11, 2024, 2:42 am
$
0
0

Summary (TL;DR)

Note: this is a follow up of the 6 and 9 September brownouts.

The service https://updates.jenkins.io will switch its implementation to a new system during 1 day:

  • Wednesday 11 September 2024 from 02:00pm UTC until Thursday 12 September 2024 02:00pm UTC

All Jenkins users are impacted but should not see any functional change.

⚠️ Please, check that your organization respects the advertised DNS TTL or you might be stuck in the brownout longer than expected.

Under the hood, any HTTP request made to this service will be redirected to a mirror close to user locations during these brownouts.

What is the "Update Center"?

Jenkins Update Center is a web server at the core of the Jenkins public infrastructure which distributes the plugins, tool installers, and versions index to all Jenkins servers across the world.

From the installation wizard to regular plugin updates, if you run Jenkins, then you use this service under the hood.

Today, it serves around 50 Tb of data (outbound bandwidth) each month from a single virtual machine on AWS, which costs around $6,000 per month.

In order to sustain this service and improve it, the Jenkins infrastructure team has worked relentlessly during the past years to have a new sustainable implementation for this service.

The new Update Center implementation features a highly available system that redirects user requests to a download mirror close to their location. Additional information is available in the GitHub issue.

Why this "Brownout"?

Our functional tests and performance tests are meeting our expectations:

  • All of our Jenkins controllers are using the new Update Center implementation.

  • We are using the new update center (with DNS override) in our own networks in different geo-locations.

  • All of our Jenkins Docker images are using the new system.

  • Our initial performance tests

  • After 2 successful 1-hour brownouts

How

Both current and new Update Centers are updated at the same time and serve the same index.

Starting 5 weeks ago, the Jenkins infrastructure has been using the new Update Center (link:https://azure.updates.jenkins.io) with a client-side DNS override (updates.jenkins.io hostname points to this new service).

During this brownout, we’ll simply switch the DNS entry updates.jenkins.io to this new service and watch for the logs and error rate. At the end, we’ll switch DNS back to the normal service and then analyze metrics and logs to see how the system behaved.

We are confident the new system will perform as expected. We now want to execute a 1-day brownout.

Please refer to the helpdesk ticket for more information.

↧
Search

Voter Registration for Jenkins Board and Officer Elections 2024

September 26, 2024, 1:42 am
$
0
0

Voter registration has started for the 2024 Jenkins Governance Board and Officer elections!

Voter registration

Nominations for the 2024 Jenkins Governance Board and Officer elections have finished. Voter registration opened September 16, 2024 and closes on October 31, 2024.

Participation in the election process requires registering an account on the Jenkins community forums and at least one contribution made before September 1, 2024. When registering, you can use an existing GitHub account or create a new account specifically for Jenkins community forums.

register button

All community members who meet the requirements and are interested in voting should join the election-voter-2024 group during the registration period. Previous elections utilized their own groups, so joining the election-voter-2024 group is required for participation.

Refer to the voter registration tutorial for detailed registration steps.

We have made the decision to trust participants and not require that you provide evidence of contribution as part of your voter registration. We reserve the right to ban any account from the election process if we identify abuse. Once registration is over, a list of email addresses will be sent to the Condorcet Internet Voting Service (CIVS).

Nominees

We will be electing three members of the Jenkins Governance Board from among six candidates. The six candidates for the Jenkins Governance Board are:

We will be electing the Jenkins Release Officer from among two candidates:

Candidate statements, affiliations, and profile links will be provided later.

The following officer positions are uncontested, so no election is needed for:

Contributing

As shown on the Participate and Contribute page, there are many different ways to contribute to Jenkins.

All contributions to Jenkins and its community are welcome.

Election

Voter registration closes on October 31. Voting begins November 1. Registered voters will be notified by email to participate using the Condorcet Internet Voting System. All votes must be submitted by end of day November 30.

Results

Election results will be published December 1. The new term starts on December 1, when the newly elected members will transition to their roles.

Important Dates

Important DatesTime

Nomination of candidates open

August 1

Nomination of candidates closes

September 15

Voter registration opens and candidates announced

September 16

Voter registration closes

October 31

Voting starts

November 1

Voting closes

November 30

Results announced

December 1

Troubleshooting

If you are new to Jenkins elections, unfamiliar with the Condorcet Internet Voting Service (CIVS) or the community forums, or feel overwhelmed with the process, don’t worry, we’ve got you covered. We published a step-by-step guide, outlining how to to join the election-voter-2024 group, activate your CIVS account and cast your vote.

If you encounter issues still or need assistance, don’t hesitate to contact the election committee.

Thank you, as always, and don’t forget to register to vote by October 31!

↧

Brownout on Update Center (updates.jenkins.io): 26 and 27 September 2024

September 26, 2024, 1:42 am
$
0
0

Summary (TL;DR)

Note: this is a follow up of the 11 and 12 September 24 hours brownout.

The service https://updates.jenkins.io will switch its implementation to a new system during 1 day:

  • From Thursday 26 September 2024 from 07:00am UTC until Friday 27 September 2024 07:00am UTC

All Jenkins users are impacted but should not see any functional change as we removed the HTTP to HTTPS forced redirection which caused disruptions during the previous brownout.

⚠️ Please, check that your organization respects the advertised DNS TTL or you might be stuck in the brownout longer than expected.

Under the hood, any HTTP request made to this service will be redirected to a mirror close to user locations during these brownouts.

What is the "Update Center"?

Jenkins Update Center is a web server at the core of the Jenkins public infrastructure which distributes the plugins, tool installers, and versions index to all Jenkins servers across the world.

From the installation wizard to regular plugin updates, if you run Jenkins, then you use this service under the hood.

Today, it serves around 50 Tb of data (outbound bandwidth) each month from a single virtual machine on AWS, which costs around $6,000 per month.

In order to sustain this service and improve it, the Jenkins infrastructure team has worked relentlessly during the past years to have a new sustainable implementation for this service.

The new Update Center implementation features a highly available system that redirects user requests to a download mirror close to their location. Additional information is available in the GitHub issue.

Why this Fourth "Brownout"?

Our functional tests and performance tests are meeting our expectations as described in "Why this brownout" section of previous blog post.

However the previous brownout taught us that enforcing HTTP to HTTPS redirections caused disruptions for users . We decided to support full HTTP temporarily to avoid bad surprises: users are (and will be) encouraged to use the HTTPS URL in the future but let’s do one step at a time!

As such, the fourth brownout serves to verify we don’t have last minute bad surprises.

How

Both current and new Update Centers are updated at the same time and serve the same index.

Starting 7 weeks ago, the Jenkins infrastructure has been using the new Update Center (link:https://azure.updates.jenkins.io) with a client-side DNS override (updates.jenkins.io hostname points to this new service).

During this brownout, we’ll simply switch the DNS entry updates.jenkins.io to this new service and watch for the logs and error rate. At the end, we’ll switch DNS back to the normal service and then analyze metrics and logs to see how the system behaved.

We are confident the new system will perform as expected

Please refer to the helpdesk ticket for more information.

↧
↧

Hacktoberfest 2024

October 1, 2024, 3:12 pm
$
0
0

Hacktoberfest

Hacktoberfest is back! Join us as we celebrate and support open-source during October. Contributors can earn badges and improve their open source contribution skills.

The Jenkins community will participate once again in the event. We invite you to contribute to Jenkins projects but also, as maintainers, to welcome and help newcomers.

Contributors

This is what contributors need to know to participate and complete Hacktoberfest:

  • Register anytime between September 23 and October 31

  • Pull requests can be made in any jenkinsci or jenkins-infra GitHub project that’s participating in Hacktoberfest (look for the "hacktoberfest" topic)

  • Project maintainers must accept your pull requests for them to count toward your total

  • Have 4 pull requests accepted between October 1 and October 31 to complete Hacktoberfest

Jenkins specific details can be found on the Jenkins Hacktoberfest page.

Some good resources for beginners can be found here:

The improve a plugin tutorial is a video introduction to Jenkins contribution.

Maintainers

Jenkins plugin maintainers can prepare for Hacktoberfest contributions by following these best practices:

  • Add the "hacktoberfest" topic to your repository to OPT-IN TO HACKTOBERFEST and indicate you’re looking for contributions

  • Apply the "good first issue" label to issues you want contributors to help with in your GitHub project

  • Add a CONTRIBUTING.md file with contribution guidelines to your repository

  • Choose issues that have a well-defined scope and are self-contained

  • Be ready to review pull requests, accepting those that are valid by merging them, leaving an overall approving review, or by adding the "hacktoberfest-accepted" label

  • Reject any spammy requests you receive by labeling them as "spam" and any other invalid contributions by closing them or labeling them as "invalid"

↧

2024 Jenkins Election Candidate Statements

October 2, 2024, 3:43 pm
$
0
0

Candidate nominations for the 2024 Jenkins elections are now complete. Thanks to everyone who submitted nominations and to the candidates that have accepted the nominations.

This announcement shares the election candidates and their statements. Nominees for the Jenkins governance board include:

Nominees for the Jenkins release officer include:

As in years past, when a particular role receives only one nomination, an election is not required. Officers that do not require an election include:

Board Candidates

Alex Earl

I have been involved with Jenkins for many years, going back to the Hudson days. I got involved in the great community by making some changes that I needed at my company to one of the plugins. I then became maintainer of that plugin and continued to participate in the IRC channels and discussion forums to help improve Jenkins.

The community of Jenkins is one of the best features, in my opinion. The people are helpful, want to provide a great thing to the world, and are so invested in making Jenkins the best it can be.

As a member of the Jenkins Governance Board, I would love to continue pushing that community and excellence. Getting more people involved in development and helping is something I would like to focus on. A lot of people are intimidated by open source and contributing. I would like to work on that idea and help lower the barriers for others to get involved, learn, and contribute.

Affiliations: Arm Ltd.

Profile pages: GitHub, LinkedIn, Contributor spotlight, Jenkins community

Alexander Brandes

I’ve been a passionate Jenkins user for almost a decade and have had the privilege of contributing to the project since 2020. Since 2022, I’ve been serving as a board member, and I’m also part of the release team, a core maintainer, as well as a maintainer of various plugins. Additionally, I’m involved in the hosting team, where I review and onboard new plugins into the Jenkins ecosystem.

One of my personal highlights this year was participating as a mentor in Google Summer of Code 2024, where I successfully onboarded two students to the Jenkins project. I ensured their projects were a success, further strengthening the future of the Jenkins community.

As a board member, I’ve attended various in-person events to represent the Jenkins project and spread the word about our vibrant community. From FOSDEM 2023 and 2024 to KubeCon 2023, CdCon 2023, and a GSoC meetup in Munich and Sunnyvale, I’ve built strong connections with fellow community members and like-minded individuals.

I firmly believe in the future of Jenkins, especially with the ongoing and upcoming UI/UX rework and the efforts to ensure Jenkins stays ahead of modern technology. One of our key focuses is ensuring Jenkins can run seamlessly out of the box on platforms like Java 22.

Throughout my time on the project, I’ve documented various in-house workflows, including the LTS release process, and introduced numerous automations to reduce human input. These efforts help keep Jenkins agile and efficient as we move forward into the future.

Affiliations: Card4Vend

Profile links: GitHub, LinkedIn, Contributor spotlight, Jenkins community

Stefan Spieker

I started contributing regularly in 2019, with a focus on improving quality. I’m also keeping up with some older plugins that are still really popular, like the Thin Backup plugin and the Job Configuration History plugin. The community helped me to bring these back up to standard and I learned a lot along the way. Furthermore, I use these lessons to make regular improvements to the developer documentation.

In my day job, I’m a solution architect in a central team that provides Jenkins and DevOps consulting within a big automotive and industrial company.

I’m already honored to be nominated, but if elected and allowed to serve on the Jenkins Board, I’d love to bring the perspective of bigger enterprises using Jenkins. I also plan to improve the developer documentation to make it easier for new maintainers to adopt abandoned plugins and keep the Jenkins ecosystem as diverse as it is today.

Affiliations: Schaeffler

Profile Links: GitHub, LinkedIn, Contributor spotlight, Jenkins community, Stackoverflow

Valentin Delaye

I’ve been a Jenkins user since it’s inception in 2011 and contributor since 2018. As of today I maintain more than 35 plugins.

Starting of this year I got even more involved in the Jenkins community, by participating as a mentor for the Google Summer of Code to work on the Jenkins Plugin Modernizer Tool, which is a CLI to update plugins at scale using OpenRewrite.

I’m particularly interested in the "cloud ready" aspect of Jenkins including deployments, packaging (like Jenkinsfile Runner), or distributed storage. A recent contribution on this topic is the Artifactory Artifact Manager plugin that I authored and maintain.

If I’m elected on the Jenkins governance board those will be my subjects of choice.

Affiliations: ELCA Cloud Services

Profile Links: GitHub, LinkedIn, Contributor spotlight, Jenkins community

Kris Stern

I have been a Jenkins contributor since 2021. Currently I am a maintainer of four plugins, have been a GSoC org admin and mentor for Jenkins for three years, and continue to be a Jenkins Release Team member. Academically I have been trained as an observational astrophysicist and obtained my PhD degree from the University of Hong Kong (HKU) in 2021. I have worked professionally as a software engineer since late 2019, currently working in a AiFi startup. Currently I am also a part-time MCIT Online student at UPenn. I am passionate about open source and would like to share my love of open-source software with the others. I feel grateful to be nominated. If elected, I would love to bring with me a startup mindset to help keep Jenkins perpetually youthful and relevant as well as a welcoming community to newcomers.

Affiliations: GAIB.ai

Profile Links: GitHub, LinkedIn, Contributor spotlight, Jenkins community

Oleg Nenashev

I’ve participated in Jenkins since 2012, including being a core maintainer since 2014. I was a governance board member from 2019 for two terms (Dec 2019-2023) and also represented Jenkins on the Continuous Delivery Foundation TOC and the board. During my work on Jenkins, I participated in many projects including JCasC, pluggable storage, and Jenkinsfile Runner. I also created or maintained around 30 plugins for Jenkins. Many community programs, including GSoC and Hacktoberfest participation, were initially started by me. In 2022, I took a sabbatical as a core and plugin maintainer due to the war in Ukraine, but I plan to return to the maintainer roles.

For me, Jenkins has one of the strongest open source communities, and I am proud to be a part of it. Should I be elected to the board, my focus will be community growth via onboarding new contributors, improving contributor/developer experience for Jenkins, and facilitating technical partnerships. The ecosystem evolves and Jenkins should be changing and growing along with that. For me, the priorities would be adopting open standards, integrations with the key projects and services in the cloud-native, CI/CD, and Java space, and continuing Jenkins' evolution as a multi-purpose automation framework.

Affiliations: Gradle Inc., CNCF/CDF, API Neuchatel, Independent

Profile Links: GitHub, LinkedIn, SessionizeJenkins community

Officer Candidates

Release Officer - Alex Earl

I have been involved with Jenkins for many years, going back to the Hudson days. I got involved in the great community by making some changes that I needed at my company to one of the plugins. I then became maintainer of that plugin and continued to participate in the IRC channels and discussion forums to help improve Jenkins.

The community of Jenkins is one of the best features, in my opinion. The people are helpful, want to provide a great thing to the world, and are so invested in making Jenkins the best it can be.

As a member of the Jenkins Governance Board, I would love to continue pushing that community and excellence. Getting more people involved in development and helping is something I would like to focus on. A lot of people are intimidated by open source and contributing. I would like to work on that idea and help lower the barriers for others to get involved, learn and contribute.

Affiliations: Arm Ltd.

Profile pages: GitHub, LinkedIn, Contributor spotlight, Jenkins community

Release Officer - Tim Jacomb

I have been a user of Jenkins for the last 14 years and a regular contributor since 2018. I began with maintaining the Slack plugin, and over the last couple of years, I have expanded my experience with several more plugins and Jenkins core. These are some of the components I maintain when I have time: Slack, Azure Key Vault, Junit, most of the Database plugins, Dark theme, Plugin installation manager, Jenkins Helm chart, and the Configuration as code plugin.

I am a member of the Jenkins infrastructure team. I was involved in the release automation project and the mirrors modernisation effort, along with the day to day support helping people regain access to accounts etc.

As Release Officer, I would like to increase automation, ease onboarding of new contributors to the release team, and ensure that responsibilities rotate among people so that I won’t be a bottleneck for any task.

Affiliations: Kainos

Profile pages: Github, LinkedIn, Contributor spotlight, Jenkins community

↧

Alpha Omega Foundation Content Security Policy Grant

October 5, 2024, 4:13 pm
$
0
0

Alpha-Omega has provided a grant for three months of full-time work to improve the Jenkins implementation of Content Security Policy. The improvements will be implemented in October, November, and December of 2024. Shlomo Dahan is implementing the improvements with technical guidance from Basil Crow and project management support from Bruno Verachten.

Alpha-Omega is an associated project of the OpenSSF, established in February 2022, funded by Microsoft, Google, and Amazon. The mission of Alpha-Omega is to protect society by catalyzing sustainable security improvements to the most critical open-source software projects and ecosystems. Alpha-Omega has funded security improvements in major open-source projects like the Linux Kernel, Rust Foundation, FreeBSD, Node.js, Ruby Central, and the Eclipse Foundation. We are sincerely grateful for this grant to the Jenkins project.

What is Content Security Policy?

From content-security-policy.com:

Content-Security-Policy is the name of a HTTP response header that modern browsers use to enhance the security of the document (or web page). The Content-Security-Policy header allows you to restrict which resources (such as JavaScript, CSS, Images, etc.) can be loaded and the URLs that they can be loaded from.

Using Content-Security-Policy (CSP), injection attacks like cross-site scripting can be prevented.

Why a grant for Jenkins?

Jenkins is the leading open-source automation server. It provides critical capabilities to organizations around the world as they create, test, and deploy software. Improving the security of the Jenkins project aligns very well with the Alpha-Omega mission for "sustainable security improvements to the most critical open source software projects".

We hope that the successful completion of this 3-month project will result in additional funding and an expanded project in 2025.

Who is working on the project?

Basil Crow is the technical lead of the project. He’ll provide guidance, mentoring, and assistance for the implementation.

Bruno Verachten is the project manager. He’ll provide regular progress reports to Alpha-Omega.

Shlomo Dahan is the developer who will implement the improvements.

↧
Viewing all 1088 articles
Browse latest View live
Search