Tag Archives: jenkins

[uberconf 2023] Jenkins vs GitHub Actions

Posted on by
Reply

Speaker: Brent Laster

@BrentCLaster

For more, see the table of contents

GitHub Actions

  • Several years old
  • Actions = framework, actions – building block (ex: checkout code)
  • Automated workflows, call actions
  • Based on repository operations – ex: push, pull, issues comment
  • Can combine/share
  • Migration tool from other CI providers
  • Repository dispatch events – for things not in github. Good for while migrating.
  • Workflows contain jobs, jobs contain steps
  • All public actions: https://github.com/marketplace?type=actions. Anyone could have submitted. See who created. ex; verified creator. Can see source code of any action ex: last updated date, how many creators
  • Can create Docker, JavaScript or composite (multiple workflow steps) as custom actions
  • workflow_dispatch – can start interactively

Cost

  • Free for public repos or self hosted runners (aka running on your servers)
  • For private repos, 2K free minutes per month and 500MB of storage. Minutes restart each month. Storage includes github packages
  • Multiplier if using github hosted runners – linux x1, windows x2, mac x10

Directory

  • .github directory
  • .github/workflows/*.yml

Key differences from Jenkins

  • GitHub Actions run in parallel by default; Jenkins runs serially by default.
  • GitHub Action jobs like Jenkins stages
  • GitHub Action actions are like Jenkins plugins
  • Less config for GItHub Action
  • GitHub Action can have any name; only yaml extension matters. (action.yaml needed for metadata for reuse though)
  • GitHub Action always in github
  • GitHub Action can have different workflows for different events
  • Jenkins supports othe reports
  • Jenkins pipeline stages can run on different nodes
  • GitHub uses reusable workflow where Jenkins uses pipeline libraries. Use workflow_call trigger to call.

Structure

  • on
  • — jobs
    • —- job
      • —— runner
      • —— steps

Code

  • runs-on – what runner to use. Can be custom runner or a GitHub provided/hosted runner. Steps in a job run on the same runner. Fresh VM per job. Docker runners are self hosted.
  • uses – the code as a relative path to the repo. After path to action can have @label for tag/version #/etc
  • on.schedule to run on a schedule – can use cron
  • needs – set dependency to invoke sequentially
  • if: success(), always(), cancelled(), failure()

UI

  • Actions tab lists workflow. Can see runs over time.
  • Like stage view of Jenkins
  • Don’t know of a way to aggregate reporting on an org level [me neither; but worth asking]

Bonus: Online IDE

  • Going to your repo and pressing the period, changes your URL from github.com to github.dev. This shows your repo in VS Code.

Migration

  • Code – move to GitHub if not there – all code/projects, history? branches? Easy to move from one git to another
  • Automation – all projects? Do people know what the Jenkinsfiles do? Custom scripting/kludges? Old versions?
  • Infrastructure – custom setup/config/os versions? Can you switch from Mac/Windows to Linux?
  • Users – what are appropriate permissions? Informed? Trained?
  • Tips – delete outdated/unneeded, standardize where can/make reusable workflow, allow enough time to migrate, require training, do a test conversion
  • Don’t want to migrate unicorns
  • GitHub Actions Importer – tool for bootstrapping migrations, not complete solutions. Attempts to read AzDO/Bamboo/CircleCI/GitLab/Jenkins/Travis. Migrate what can and access what can’t. Docker container runs as extension to GitHub CLI. Has commands: update (to latest version), version, configure (interactive prompt to configure credentials), audit (looks at current footprint), forecast (predicts Actions usages), dry-run, migration (create initial files). Good for insights. Can be more trouble than it’s worth to use in full. Can write custom transformer in Ruby if need something not built in

My take

I’ve used GitHub actions only a tiny bit, but lots of Jenkins. The phrase “like in Jenkins” came up a lot which was helpful in comparing them and learning faster. As were the tables and the code comparisons. The shortcut of “.” is cool (not about actions, but still useful).

jenkins convert to pipeline plugin

Posted on by
Reply

I needed to convert a freestyle job to a pipeline job for “Automating your Ci/CD Stack with Java and Groovy” Hands On Lab at Oracle Code One. It’s a really simple project, but it is still a pain to convert by hand.

I had read about the Convert to Pipeline plugin so decide to give it a shot. It’s easy enough to install a plugin.

Generated Pipeline

Below is what got generated. While I’d like to assume that credentials binding isn’t in wide use, that one didn’t surprise me. In hindsight, it makes sense because the credentials binding would need to wrap the Gradle block. I was surprised that Gradle wasn’t supported.

I am glad that the tool leaves comments for what you need to do by hand.

// Powered by Infostretch 

timestamps {

node () {

	stage ('osprey - Checkout') {
 	 checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '', url: 'https://github.com/boyarsky/OracleCodeOne2018-HOL-Automating-Stack-Groovy.git']]]) 
	}
	stage ('osprey - Build') {
 	
// Unable to convert a build step referring to "org.jenkinsci.plugins.credentialsbinding.impl.SecretBuildWrapper". Please verify and convert manually if required.
// Unable to convert a build step referring to "hudson.plugins.gradle.Gradle". Please verify and convert manually if required.
		// JUnit Results
		junit 'osprey-project/build/test-results/test/*.xml' 
	}
}
}

Using the pipeline generator

On the pipeline job, you can click the “pipeline syntax” link. It opens a new browser tab with a pull down for common pipeline operations.

Credentials

I choose “withCredentials”, entered the variable names and selected the credential from the pull down. Then I clicked “Generate Pipeline Script” and got:


withCredentials([usernamePassword(credentialsId: 'nexus', passwordVariable: 'nexusPassword', usernameVariable: 'nexusUserName')]) {
// some block
}

Gradle

That brings us to Gradle. As far as I can tell, there are only objects for Gradle if you are using Artifactory. I am using the gradle wrapper though, so I followed the advice of this Stack Overflow post and just called gradlew.


withCredentials([usernamePassword(credentialsId: 'nexus', passwordVariable: 'nexusPassword', usernameVariable: 'nexusUserName')]) {
  sh "./osprey-project/gradlew clean build -b osprey-project/build.gradle -PnexusBaseUrl=http://nexus:8081 -PnexusUserName=${nexusUserName} -PnexusPassword=${nexusPassword}"
}

I decided to separate the publish step into a different stage and rename the stages as well.  Resulting in:


// Powered by Infostretch 

timestamps {

node () {

	stage ('Checkout') {
 	 checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '', url: 'https://github.com/boyarsky/OracleCodeOne2018-HOL-Automating-Stack-Groovy.git']]]) 
	}
	stage ('Build') {
	    
	   withCredentials([usernamePassword(credentialsId: 'nexus', passwordVariable: 'nexusPassword', usernameVariable: 'nexusUserName')]) {
          sh "./osprey-project/gradlew clean build -b osprey-project/build.gradle -PnexusBaseUrl=http://nexus:8081 -PnexusUserName=${nexusUserName} -PnexusPassword=${nexusPassword}"
       }

		// JUnit Results
		junit 'osprey-project/build/test-results/test/*.xml' 
	}
	
	stage ('Publish') {
	    
	   withCredentials([usernamePassword(credentialsId: 'nexus', passwordVariable: 'nexusPassword', usernameVariable: 'nexusUserName')]) {
          sh "./osprey-project/gradlew publish -b osprey-project/build.gradle -PnexusBaseUrl=http://nexus:8081 -PnexusUserName=${nexusUserName} -PnexusPassword=${nexusPassword}"
       }
	}
}
}

Note: My actual build file was bigger. The parts outside the pipeline (ex: project security settings) got preserved.

a rant about jenkins script security

Posted on by
Reply

I’m working on the lab for my Automating Your CI/CD Stack with Java and Groovy Oracle Code One session. And of course I tripped over Jenkins Script Security plugin.

I don’t need script security. I’m running a lab. But you can’t turn off that feature. Sigh.

I can run this code from the scripting console as an admin. I can also run it from within a job using the embedded Groovy console option. If I try to pull the same code from GitHub and run it from the same job as a Groovy script, I can’t. Script security views the SAME script to be more dangerous because I put it in source control.

import jenkins.model.Jenkins

def instance = Jenkins.getInstance()
def realm = Jenkins.getInstance().securityRealm

I can think of three ways to “solve” the problem that Cloudbees created.

Option 1: Deal with script security

I can configure script security to allow these signatures. However, this does not make things more secure. I want these to be available to admins not for general use. So approving them or whitelisting them is the wrong decision. (Ok. It doesn’t matter here since this is just a lab. But in this hypothetical use case…)

Option 2: Authorized Build plugin

There’s an authorize project plugin that lets you run the build as an admin. I didn’t try it, but it appears to provide a decent workaround to this problem. (I’m trying to minimize setup)

Option 3: Just run the code through the Groovy console

I’m going with this. Up to 50 people are going to be doing this manually in a lab. Copy/paste is the easiest solution.