Jenkinsfile Runner for GitHub Actions Project in GSoC-2022 needs your advice

Contributing GSoC
1

Hi all,

My name is Yiming and I’m the contributor of Jenkinsfile Runner for GitHub Actions Project in GSoC-2022. As my project begins, I need the advice from the Jenkins community to make it more useful to the users.

The Jenkinsfile Runner for GitHub Actions Project in GSoC-2022 intends to build useful GitHub Actions for Jenkinsfile-runner and Plugin Installation Manager Tool. The users can utilize these GitHub Actions for their own workflow definitions. Therefore, running the Jenkins pipeline inside the GitHub Actions becomes available.

You can find our project plan, POC project and demo project here. The POC project and project plan doc are still in update so it can be different by day:

  1. Proof of concept about these Jenkins Actions: GitHub - Cr1t-GYM/jenkins-action-poc: This is the POC of Jenkinsfile Runner Action for GitHub Actions in GSoC 2022.
  2. A demo about applying these Jenkins Actions in a small SpringBoot project: GitHub - Cr1t-GYM/JekinsTest: Jenkinsfile Runner Action for GitHub Actions Test
  3. A demo action log for these Jenkins Actions: Java CI · Cr1t-GYM/JekinsTest@a16791f · GitHub
  4. Project Plan: GSoC2022_YimingGong_Project_Plan - Google Docs
  5. Original idea about Jenkins Actions: GitHub - jenkinsci/jenkinsfile-runner-github-actions: Jenkins single-shot pipeline execution in a GitHub Action POC
  6. Jenkinsfile-runner project: GitHub - jenkinsci/jenkinsfile-runner: A command line tool to run Jenkinsfile as a function
  7. An example workflow definition about how to use these actions: JekinsTest/ci.yml at cfd7c9def6459649ff96a8baa4ba4903fc381610 · Cr1t-GYM/JekinsTest · GitHub

We give three common cases about how to play with these actions:

  1. jenkins-plugin-installation-action + jenkinsfile-runner-action: Download all the dependencies and run the pipeline at the runtime.
  2. jfr-container-action: Use the jenkinsfile-runner vanilla distribution in the jenkins/jenkinsfile-runner repository. All the actions will be run in this container.
  3. jfr-static-image-action: Create a Docker action for Jenkins pipeline. This action has its own working environment. It won’t have an extra environment relationship with the on demand VM outside unless the user mounts other directories to the container (For example, checkout action if it exists). After the docker action ends, this container will be deleted.

Although we didn’t release these actions yet, you can reference these actions URI in your workflow definitions:

  1. Cr1t-GYM/jenkins-action-poc/jenkins-plugin-installation-action@master
  2. Cr1t-GYM/jenkins-action-poc/jenkinsfile-runner-action@master
  3. Cr1t-GYM/jenkins-action-poc/jfr-container-action@master
  4. Cr1t-GYM/jenkins-action-poc/jfr-static-image-action@master

We appreciate any feedback on this proposal along the lines of the following questions:

  1. Which actions do you prefer and why?
  2. Do the current actions meet your project needs?
  3. What kind of enhanced functionality do you look for in these actions?
  4. Etc.

Your opinions about our project are valuable. Thanks for your prompt attention!

Sincerely,
Yiming Gong
GSoC 2022 Contributor

4 Likes
2

Who do you see as the target use for this? I already have Jenkins running so why do I need this running via GitHub actions?

I don’t really use GitHub actions at all, so I can’t comment there but from my experiences with docker and k8s. I’d want all my plugins in an image so a jenkins.io outage never breaks my builds.

2 Likes
3

Thanks for your advice! I think Jenkinsfile-runner plus GitHub Actions can be an alternative for the users who don’t want to configure/maintain the Jenkins instance. The on demand VMs from GitHub Actions stop running after the workflows end. These advantages are only from my speculation.

Yes, using container is safer in this case to protect your pipeline.

4

Running one CI agent to invoke yet another CI agent? That’s why arctic melts…

I would really like to hear a usecase first why someone would like to do this - otherwise I think it should not be encouraged and should be hard by design.

I read the Description of the project and it did not convince me unfortunately.
If I understood correctly, the issue stated there could be solved by docker-compose, ansible script, Dockerfile or a bash script - definitely not by another CI tool.

1 Like
5

Thanks for your advice. I think this project is a simple user case of Jenkinsfile-runner which uses GitHub Actions as a FaaS context. The possibility of serverless building is not enabled by this project but enabled by Jenkinsfile-runner. If the users have such a need, they can deploy it to any FaaS contexts for only one time such as AWS Function and Azure Function.

The classic Jenkins master is a permanent server. But what if it is an on demand server? I guess some users might want to use it to trigger other on demand agents building.

2 Likes