Tag Archives: github

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

[kcdc 2022] lessons from reviewing a very big pull request

Posted on by
Reply

Speaker: Patrick McVeety-Mill @pmcvtm and @loudandabrasive

For more, see the table of contents

PR Principles

PR is to merge code. Typically involves gate checks and review

  • well organized – code resonably grouped, scope is defined and right sized, mostly related changes (not so small that annoying, not so big it is difficult to review. keep side stuff to a minimum)
  • well documented – high level description, story of the approach, issue/ticket/doc reference
  • well considered – planned before opening, open for discussion pragmatic not dogmatic
  • well reviewed – thorough (high and low level), ode efficient and matches style, tested (functionality over all else)
  • have empathy – for author, reviewers, future readers of code, users of product

Context

  • Open source software provider
  • This PR came from a partner – large changes in the past with reasonable success. Semi-rotating cast of devs
  • This change wasn’t made by the same people who learned how to do things first ti
  • Semi-collaborative – weekly syncs, shared chat room
  • Initial plan was for smaller chunks but hard to enforce
  • Doing free work for company because partner
  • Wound up being 900 lines

How approach looking at

  • Accept your fate – mentally prepare
  • Assess the scene
    • look at high evel and plan process
    • web UI doesn’t help with hundreds of files git diff —name-status main gives a list of the files and status. Redirecting to a file gives all of them
    • Dump into a spreadsheet – can sort by change type (add/modify/delete/rename, project or file name)
  • Translate into a checklist – track as go through files. Can do in markdown or Excel. Markdown lets you copy/paste into the response later
  • Look for smells – need to look at closely
    • R100 – means rename an no differences. (100% same.) Can be irectory rename or file name refactoring
    • Add/delete with similar names. Changed a lot.
    • Big chunks of adds – new features
    • ”C” s for copcying a file
    • At this point, leave feedback and ask to rename back to cut down the diff and can restore them in a follow up. This will make PR smaller
    • This got 900 file PR down to a 600 file PR
  • Disappear and review – look at each project/file. add/delete then changes.
    • git difftool -d main MyDir
    • Used BeyondCompare to see visual
    • Looking for critical differences
    • Quicky note format/style issues
    • Manually test related features before moving on
    • Don’t get stuck viewing diffs – want to understand big picture
    • Use diff tool most familiar with so not learning new tool while doing this. Your IDE may have a useful tool
    • If multiple commits, read comments to see journey
    • Use an IDE or tool that can highlight warnings – ex: unused code
    • track and note comments in your checklist
  • Give feedback
    • Be incremental – don’t wait til the end. Give feedback file by file/project by project. Can do in description with multiple posts.
    • Be specific and actionable list files/line numbers, allow author to indicate resolution, explain reasoning where can
    • For small PRs, comment inline during review (ex: GitHub). For super large PRs, crashed tab because so large. Gives top evel coment but reference the specific file names locations.
    • Prioritize with MoSCow – MUST do before merging, SHOULD do or create debt (task for later), COULD do to be nice, WON’T do even i we like (maybe an epic later). Also questions and comments.
    • Indicate nits. Still fix but clear what it is.
    • Compare against your notes to mae sure done
    • Saw ”when” – give tricky issues back to internal team. Can use epic/release branch. Can merge into there so not in main until fix everything.
    • Be diplomatic – remember everyone can see and don’t want to scare contributors away (free work, want to keep)
    • Don’t close PRs without comment

Timing

  • 1 month to merge to feature branch (1-2 weeks for first pass)
  • 2 months to finish all follow up issues

Preventative Measures

  • Formatting
    • pick a format and stick with it
    • setup auto-formatting
    • if strong arm, know it is annoying
    • report early rather than every instance
    • decide how important it is
    • .editorconfig files are cross language and cross-IDE
    • githooks
  • Repository Templates – placeholder text for PRs and issues to show what want
  • Automate checks and report back. Builds are for when code changes. Bots check things as time passes

Communication channels

  • PR interface good for tracking progress, leaving artifacts for others to look at, the original comments from squashing comits
  • PR interface not good for feature details, complex scenarios, brainstorming
  • Use shared issue tracking – just knowing the github issue is in progress for months isn’t helpful. Use a github board or trello
  • Get agreement on what PR will be
  • DIscuss offine and post result
  • Alternatives – Frequent pairing (still do PR at end), periodic review (ex: review monthly ”state of the union on the repo”), trust/testing/recovery (everyone merge to main)

My take

This was fun. It was very information heavy, but easy to follow. And I learned a few new techiques.

[kcdc 2022] level up with co-pilot

Posted on by
1

Speaker: Rizel Scarlett @blackgirlbytes

For more, see the table of contents

Notes

  • AI pair programmer
  • Not magic
  • Compare to Gmail smart compose – suggests continuations
  • Draws context from comments/code
  • Suggests lines/functions

Open AI

  • Powered by Open AI Codex – translates natural language into code
  • GPT-3 – generative pre-trained tranformer 3 – deep learning to produce human like text
  • Duolingo GPT-3 uses for grammar correction
  • Codex code based
  • Played with https://beta.openai.com/examples – Movie to Emoji and Mood to Color (many others).
  • There is also https://beta.openai.com/playground (if you login) where it can generate code from a comment. Even lets you specify a language
  • Also learned you can paste a hex code into google and have it show you the color

Copilot Labs

  • Hover over suggestion to get more
  • Experimental feature to include an explanation of what code does
  • Plugins – VS Code, JetBrains, Neovim
  • Can choose not to include public code
  • Can do some (human) language translation

Benefits

  • Code faster and clear – good at patterns, syntax (ex: regex) so don’t need to google, write better comments so copilot can give good suggestions
  • Write good docs – in markup
  • Be a better mentor – avoids nervousness of someone watching you type because don’t have to worry about syntax, helps mentor people in languages don’t know
  • Gain context for new concepts – studying for interviews (leetcode), explain new code base, create short demos in new languages as dev advocate

Tips

  • Turn off when writing initial structure. Turn on once have pattern going. Comments not useful at first.
  • Good when writing unit tests.

Cost

  • $10/month
  • Free if open source or student

My take

Rizel has a lot of energy and is very relatable. She also did “group play” with openai early. All of that helped engage the audience. I’ve read about co-pilot but it was really cool to see it and the features/benefits/use cases. I enjoyed seeing her passion for the tool and the examples. I also liked how she avoided it from devolving into an argument about the ethics of co-pilot. Rizel didn’t let the wifi problem throw her. It was unfortunate that the demo didn’t work even though other internet stuff did. [block? too bandwidth heavy?] The code to tweet was cool

For co-pilot, some looks cool. Some of the comments were longer than the code. So in real life, I imagine you wouldn’t use it for everything.