[uberconf 2023] Jenkins vs GitHub Actions

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).

[kcdc 2022] building rugged devops pipelines with github

Speaker: Brian Gorman @blgorman

Repo: https://github.com/blgorman/codemash-rugged-devops

For more, see theĀ table of contents

DevOps

  • Process, not product
  • Can’t buy tool (but can buy an existing team)
  • Goal: reduce cycle time form idea to production with minimal error
  • Automated testing
  • Gates – automated and human, quality, release
  • Avoid 2am support calls. Or at least only have to push a button to recover

Shift left

  • Less cost if find bug early
  • Reusable processes
  • Push quality upstream
  • Dev machine is as far left as can go
  • Build scanning tools into process
  • Sell the vision

Prereq

  • Cloud env exists
  • Templates

Actions

  • .github/workflows – folder
  • Actions tab to see result

YAML

  • on: the triggers (ex: push, pull_request)
  • env: (ex: branch)
  • jobs: want you want to do
  • with: trigger another job

Infrastructure as Code

  • Declarative
  • Repeatable Results
  • Ensures no configuration drift
  • Azure has imperative and complete options for ARM templates – complete is destructive and dangerous. Anything added outside code deleted.
  • Tools – ARM templates (Bicep) , Terraform, Ansible, Puppet/Chef, Pulumi

Security

  • App registration so github actions get access to Azure and add credential
  • Setup github token

SonarCloud Scanner

  • Most popular
  • Not free
  • Can choose whether to require fixing of warnings

Dependabot

  • Brining in dependencies without knowing
  • Alerts on insecure package
  • Options for security updates

OWASP

  • Zap Scan
  • Baseline (lightweight) scan for pull requests
  • Full scan overnight
  • For penetration test, provide valid URL so can try to hit it
  • WhiteSource – GP Security Scan

Q&A

  • Azure DevOps pipelines easier if new team
  • Azure DevOps has better gating
  • GitHub getting better.

My take

The room was full. When I walked in, Brian was talking. I was worried he started early, but did not. He was just talking to the audience who arrived early separate from the session. It was a good intro to github actions. Also if it has been a while (more features now.) I’m glad the code was in a repo so I could read it on my screen. I’m sitting in the back (because my talk is right after this and I need to leave early) and can’t read the code from here. It’s also nice to have as a reference. I also like that he covered integrations like Sonar.