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