posts: Add GSoC posts from Marcelo Spessoto

_posts/2024-05-15-first-gsoc.md

@@ -0,0 +1,52 @@
+---
+layout: post
+title:  "[GSoC] I was accepted into Google Summer of Code!"
+date:   2024-05-15
+author: Marcelo Mendes Spessoto Junior
+author_website: https://marcelospessoto.github.io/
+tags: [jenkins, ci, kcov, code coverage]
+---
+
+# My first steps of community bonding in Google Summer of Code
+I've been accepted into GSoC program for the kworkflow project this year! My proposal is to implement a self-owned server that will host a CI pipeline in Jenkins (replacing the actual GitHub Actions pipeline) and manage data telemetry. Let's see what I've done in the first two weeks.
+
+## Studying the Jenkins capabilities
+Jenkins is an open-sourced tool for providing automation, especially for Continuous Integration and other DevOps practices. It is a very solid and consolidated project that offers a variety of different plugins, allowing easier integration with different automation infrastructures. It is meant to be structured as a distributed system with a central Jenkins controller, which will manage the automation requests and schedule them to its different computing nodes (known as agents).
+
+Therefore, one of the most important first tasks is to implement a first Jenkins agent to deal with the CI tasks. I've gone through the [official Jenkins agent tutorial](https://www.jenkins.io/doc/book/using/using-agents/). The agent worked fine, but a bit more refining will be done next days.
+
+![Image]({{site.url}}/images/post_1_nodes.png)
+
+Another major aspect of the initial Jenkins setup is the integration of the Jenkins pipeline with [the GitHub repository](https://github.com/kworkflow/kworkflow), so it can receive webhooks and build the Pull Requests and commits into the pipeline accordingly. I've already done this before the start of the Community Bonding period, but I will expand on that next section.
+
+## The GitHub Branch Source Plugin
+
+One of the most used Jenkins plugins is the GitHub Branch Source Plugin. It is responsible for abstracting in Jenkins the process of setting the controller to listen for webhooks sent from GitHub.
+
+To correctly use the plugin and implement the functionality, one needs to first set up a GitHub App in GitHub. It will be responsible for receiving subscriptions from other services (in our case, Jenkins), conceding them chosen permissions in a repository, and sending them webhooks for certain events in the given repository.
+
+It is a simple process once you get it. Create the GitHub App, select permissions regarding Checks and Pull Requests, and set the webhook URL. It is also very important to generate the App's private key and download it, so it can be given to Jenkins and used by it to authenticate with the GitHub App.
+
+In Jenkins, create the Multibranch pipeline. With the Branch Source Plugin, VCS hosts integration options will be displayed on the pipeline settings. Then, give the appropriate branch required information, including the private key.
+
+I've done these steps in a kworkflow's fork of mine. Then, following the suggestions of the maintainers, I implemented the first required task for the pipeline: The code coverage.
+
+## Implementing a code coverage stage for the pipeline
+
+When the Jenkins pipeline got associated with the repository, it didn't detect many branches at first. It is because the pipeline was set to interact only with branches containing a **Jenkinsfile** in the root directory. It is the file containing all the pipeline steps to be executed. This way, the CI pipeline is on the project repository itself, open to the general public.
+
+![Image](assets/images/post_1/post_1_branches.png)
+
+This is the starting point for developing the basic pipeline for code coverage generation. 
+
+I've started by understanding how kworkflow initially generated their code coverage using GitHub Actions. It appears that the [kcov](https://github.com/SimonKagstrom/kcov) software is used, and the output is then integrated with CodeCov. By reading their documentation, I've found out that kcov also generates output in XML Cobertura format, which can then be parsed by Jenkins by using the Cobertura Plugin. Finding out how to use the cobertura command in the Groovy-scripted Jenkinsfile was not that hard, since Jenkins offers a Snippet Generator.
+
+![Image](assets/images/post_1/post_1_codecoverage.png)
+
+[The initial Jenkinsfile](https://github.com/MarceloSpessoto/kworkflow/commit/36b7b40ea32d5c09fbb5246839af459032b43fa4) was then finished. It resolved the code coverage problem in general.
+
+There are still some problems that need to be addressed soon. First, I will ensure that the docker agent is set in the most efficient and scalable way possible.  Then, I will also improve the modularization of the pipeline steps for the code coverage job. 
+
+Another important fix to be addressed is related to the vm_test and signal_manager_test, which failed in the pipeline and had to be "suspended" to validate the overall pipeline. I highly suspect it is caused by some dependency missing in the pipeline environment, and I hope I can fix it this month.
+
+This is what I did in the first two GSoC weeks. In my first proposed schedule, I had a bigger emphasis on studying/setting virtual and physical hosts. However, after some discussions with the maintainers, we've decided to focus on replicating the actual GitHub Actions pipeline and validating it as a primary focus.

_posts/2024-05-19-implementing-jenkins-as-code.md

@@ -0,0 +1,64 @@
+---
+layout: post
+title:  "[GSoC] Implementing Jenkins as Code"
+date:   2024-05-19
+author: Marcelo Mendes Spessoto Junior
+author_website: https://marcelospessoto.github.io/
+tags: [jenkins, ci, CaC]
+---
+
+# Applying the Jenkins as Code paradigm
+
+On my first two GSoC weeks, I've dealt with a basic Code Coverage pipeline and implemented it on a 
+bare-metal infrastructure. My next expected steps, according to my project schedule, were to start 
+implementing the virtual machine and physical device agents. Turns out, however, that this task may be
+delayed a little bit more, so I can focus on polishing the Jenkins pipeline foundation.
+
+As I've immersed myself in the Community Bonding period, the proper port of the complete actual GitHub 
+Actions CI to Jenkins has emerged as a more important task. From that, we will have a nicer environment
+to plan and develop the new testing workflow. Also, the dummy implementations could be seamlessly packed
+into the development period, where I will direct all my efforts on this specific issue.
+
+## Applying CaC
+
+Configuration as Code (CaC) is a paradigm where the configuration of an application is described in "code",
+such as yaml scripts. This way, one can easily automate the deployment of such infrastructure by using the
+code instead of setting things up manually.
+
+Doing that for the kworkflow Jenkins pipeline would bring many benefits. Most of the CI configurations
+and plugin settings could be saved on a VCS host server, keeping all the DevOps work preserved and ready
+for deployment on any bare-metal network.
+
+### First step: setting a Docker Compose environment
+
+First of all, it will be interesting to replace the actual Jenkins bare-metal install with a containerized
+service. It makes the service deployment easier and also enables one to set up a specific configuration for
+Jenkins as Code Plugin (we'll come into that really soon) and plugin set.
+
+Also, this enables the use of Docker Compose to orchestrate the automated deployment of the Jenkins servers
+alongside its Jenkins agent container. 
+
+The only important configuration I needed to set on the Dockerfile was to install the necessary Jenkins plugins.
+
+The full setup can be found [here](https://github.com/MarceloSpessoto/jenkins-kw-infra). 
+
+### Using Jenkins plugins for CaC deployment
+
+After setting up the basic docker environment, my next steps would be to configure Jenkins as Code for immediate configuration of newly deployed Jenkins containers.
+
+The core Jenkins for CaC is JCaC (Jenkins Configuration as Code). It lets you write on a simple yaml file the configuration settings of your Jenkins server.
+
+It is very simple to figure out how to write the configuration file. You can access their [example configuration samples](https://github.com/jenkinsci/configuration-as-code-plugin/tree/master/demos). You can also export yaml from a Jenkins server.
+
+By using their example configuration as a reference and by exporting the configuration from a Jenkins server I've previously set before, I was able to deliver a basic Jenkins configuration for kworkflow's needs.
+
+The most important configuration, however, was to allow the automated setup of the Jenkins credentials. I've managed to achieve that by mounting the credentials files (private keys, etc.) into the docker containers, and loading the mounted credential files directly from the JCaC configuration file.
+
+### Job DSL plugin
+
+For the kworkflow pipeline, it is also very important to setup the pipelines automatically. The kworkflow's CI workflow actually executes 5 different jobs, and thus, we need to easily configure 5 different pipelines in Jenkins, each having the same credentials configuration and executing their unique pipeline jobs. 
+
+This can be achieved by using the Job DSL plugin. It is called by JCaC plugin to create jobs in an automated way. We set a groovy file, declare an array with 5 different job names. For each job, create a Jenkins multibranch pipeline, and set it to execute the job from a Jenkinsfile with the job's name.
+
+The Jenkinsfile with the job to be executed is expected to remain in the kworkflow repository.
+

_posts/2024-07-20-jenkins-intro.md

@@ -0,0 +1,124 @@
+---
+layout: post
+title:  "[Jenkins] Introduction to Jenkins"
+date:   2024-07-20
+author: Marcelo Mendes Spessoto Junior
+author_website: https://marcelospessoto.github.io/
+tags: [jenkins, ci]
+---
+
+# Exploring Jenkins 
+
+This the very first post from my Jenkins series. The idea of this series is to
+register valuable information about the Jenkins tool but also to track different aspects
+of it that I've explored during Google Summer of Code.
+
+These blog posts will try to explain core concepts/practices regarding Jenkins in a succint way.
+Of course, you can always dive into official documentation for more detailed explanations.
+
+## Summary
++ [Introduction to Jenkins](#intro)
+    + [The Pipeline](#pipeline)
+        + [Nodes and Distributed CI](#nodes)
+        + [The Jenkinsfile](#jenkinsfile)
+        + [Plugins](#plugins)
++ [Glossary](#glossary)
++ [Resources](#resources)
+
+<a name="intro" />
+
+## Introduction to Jenkins
+
+Jenkins is a Java-based tool used for providing a self-hosted automation server. 
+
+It is quite useful for CI/CD infrastructures, since it provides the necessary automations for
+building and deploying code in a self-owned server.
+
+Since Jenkins is open source software, there are many good reasons to
+choose Jenkins over other CI/CD alternatives, such as:
++ Althought it requires from the user the management of their own server, it is a completely free tool.
++ There are plenty of plugins to extend Jenkins functionalities, making it very versatile.
++ The open source model is good for improving overall security.
+
+Let's take a look on some key concepts to understand how to effectively use Jenkins for a CI/CD context...
+
+<a name="pipeline" />
+
+### The Pipeline
+
+The Jenkins Pipeline is the heart of every Jenkins automation. It is basically the automation pipeline 
+to be executed itself.
+
+<a name="nodes" />
+
+#### Nodes and Distributed CI
+
+In Jenkin, it is very important to distribute the CI/CD tasks between different computing nodes. You can
+assign Jenkins agents (which can be an entire physical computer, a VM, a container, etc.) to execute specific
+tasks.
+
+<a name="jenkinsfile" />
+
+#### The Jenkinsfile
+
+The Jenkinsfile is the "as code" definition of the instructions to be executed by a pipeline, usually placed
+in the root of the project. It is basically a groovy script describing each **step** (i.e., task) to be executed 
+by the CI/CD pipeline. These steps can be conceptually separated in different **stages**.
+
+The Jenkinsfile also enables the definition of which **agent** (i.e., nodes) will run the pipeline or specific stage or step.
+
+Here's an example of a Jenkinsfile, in a kworkflow fork root, which installs kworkflow and prints some content.:
+
+```
+pipeline {
+    agent any
+    stages {
+        stage('Install kworkflow'){
+            agent {
+                label 'kw-installer'
+            }
+            steps {
+                sh './setup.sh --install --force'
+            }
+        }
+        stage('Echo Something'){
+            steps {
+                echo 'kworkflow has been installed'
+                echo 'Now I will print some statements'
+            }
+        }
+    }
+}
+```
+
+The Jenkinsfile above assings any agents to execute the pipeline. Then it executes the first stage, "Install kworkflow",
+which will use exclusively the agents labeled as "kw-installer". This stage has a single step: execute the sh command 
+"./setup.sh --install --force".
+
+Then, it reaches the second stage, "Echo Something", which doesn't assign any specific agent, so the agents any from the 
+outer scope are applied. It executes two steps, each `echo`ing a different statement.
+
+<a name="plugins" />
+
+#### Plugins
+
+Plugins are one of the most important features of Jenkins. They extend Jenkins functionalities, and this
+applies to the Pipeline as well. With plugins, one can, for example, extend the Pipeline Syntax for Jenkinsfile,
+and, for example, use a new `junit` command in a step, or define the use of a dynamic `docker` agent in the Pipeline.
+
+<a name="glossary">
+
+## Glossary
+
++ CI/CD: Continuous Integration and Continuous Delivery, i.e., the automation of the process of developing and
+delivering code.
++ Groovy: A dynamic scripting language that can be compiled to bytecode for JVM (Java Virtual Machine). This
+enables Groovy to work pretty well with Java applications, such as Jenkins.
++ kworkflow: Open source project for eliminating manual overhead on the context of kernel development.
+
+<a name="resources">
+
+## Resources
+
++ [Jenkins Handbook](https://www.jenkins.io/doc/book/)
+