Weeknotes 56

I woke up at 7am this morning and stumbled through a fair chunk of my weekday routine before I realised it was Sunday. It was a lovely feeling when my half-awake brain understood that it could stop what it was doing and go back for another couple of hours’ sleep.

Another massive bag of flour arrived. I also treated myself to a flour scoop so I can refill the flour jar without the indignity of using a ladle.

I’ve spent a month doing daily stretches in an attempt to improve my flexibility to the point where I can touch my toes. I was initially very sceptical because I could only comfortably touch my knees with a straight back and it seemed impossible that I’d ever be able to reach so much further.

But yeah, it turns out that stretching works, and my progress has been satisfyingly steady:

(Sorry about, I dunno, the existence of my legs or whatever.)

I can now easily touch my toes if I cheat, so I feel more confident that I’ll be able to do it properly if I keep this up for another month.

I’m accidentally also improving my ability to put both a camera and myself in roughly the same position every day.

Over the years I’ve written a few educational Git repos where each commit demonstrates the next step of an incremental explanation. To prevent bit rot I periodically go back and amend their histories to update dependencies or fix new deprecation warnings. For these changes it’s unusually important to check that the tests still pass on every commit, not only the most recent one, because each step of the explanation needs to work properly for it to remain usable.

I usually do this by either running the tests manually for each commit or (more often) forgetting that it needs to be done, neither of which is a great strategy. This weekend I needed to make some changes for the newly-released Ruby 3.0 while maintaining compatibility with Ruby 2.7, and this extra dimension of hassle pushed me over the edge into figuring out how to automate the testing process.

I took this as an opportunity to properly learn how GitHub Actions work so that I could set up GitHub to do everything for me. It turns out it wasn’t hard to write a workflow to do what I wanted:

on: push
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        ruby-version: ['2.7', '3.0']
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: ${{ matrix.ruby-version }}
          bundler-cache: true
      - name: Run tests
        run: |
          status=0
          for sha in $(git rev-list --reverse ${{ github.sha }}); do
            git restore --source $sha .
            if [ -d "spec" ]; then
              git show --quiet --oneline $sha
              if
                bundle install --quiet &&
                bundle exec rspec --force-color --format documentation
              then
                state="success"
              else
                status=$?
                state="failure"
              fi
              curl \
                --silent \
                --output /dev/null \
                --request POST \
                --url "${{ github.api_url }}/repos/${{ github.repository }}/statuses/$sha" \
                --header "Authorization: Bearer ${{ github.token }}" \
                --header "Accept: application/vnd.github.v3+json" \
                --data @- <<DATA
                  {
                    "context": "Ruby ${{ matrix.ruby-version }}",
                    "state": "$state",
                    "target_url": "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"
                  }
          DATA
            fi
          done
          exit $status

The idea is to iterate over all commits with git rev-list and use the status API to mark them individually as success or failure in each of the two Ruby version contexts. It’s hacky but I like being able to see per-Ruby status indicators on every commit, plus the overall workflow status on the branch tip to show whether everything succeeded.

I considered using the status API as a cache — there’s no point re-running the tests for a given commit if a status already exists for its SHA — but I have no incentive to do it unless I run out of free minutes and there’s no danger of that happening soon. It’s also tempting to try to trigger a real workflow run for each commit rather than poking the statuses in directly, but a) that seems pretty wasteful given the setup overhead of each workflow and b) I think you can only trigger a workflow for a ref, not an arbitrary SHA, in which case it’s not possible anyway.

While it’s impressive that GitHub Actions is usable by someone who doesn’t really understand what they’re doing, I would still like to hear advice from anybody who can tell me how to use it properly.

If I hadn’t bothered setting up the above, I probably wouldn’t have noticed a Ruby 3.0 bug in capybara-mechanize.

Arrested Development still hasn’t produced a lol but I’m hanging in there.

One of my favourite music videos on YouTube is i just did a bad thing by bill wurtz and I was sad when it looked like he’d quit in early 2019. But, in a fantastic twist, it turns out he’s spent the last couple of years learning Blender.

The new ContraPoints video about J.K. Rowling is long but worth watching for its insight and compassion. It also reaffirmed my life choices by referencing both Red Letter Media and Arrested Development.