Week Notes 24#29
21 July 2024 | 8:49 pm

  • Related to a comment on Lobsters about Git history, I posted my own blog post, which then led to a number of sites (including some Telegram groups and Unsupervised Learning issue 441) which has ended up in roughly ~4k hits
  • I remember waking up one day this week knowing that Cookie had been the little spoon, curled up into my arm 🥰
  • At work, I've been writing a lot of docs for our Renovate rollout, and been busy with a few bits of testing
  • Very much been enjoying Subliminal - Fred V + Etherwood and got a lot of good music from the song radio on Spotify
  • Also listened to my "daylist" playlist on Spotify a bit this week which was good
  • One day this week my mind was very busy thinking of names for the (paid) hosted service I could set up for dependency-management-data, and one I thought of - while asleep? - sounded good in my sleepy brain, but does not when you try and say it out loud 😅
  • Had a very nom Rakki Rakkas 😋
  • Had a nice time meeting Dave and Faye and Jasper part way between us at Hopewell Dog Park to intro the doggos for the first time
    • I drove on the way back - after a last minute change on the way, as I was planning on driving there - and did my first proper motorway stretch, and longest journey so far 💪
    • Discovered that - if you and Cookie are sitting in the car at the services, lock the car, and have the ignition / infotainment system off, it'll start the car alarm
    • Also discovered that it takes a while for you to notice it's your car alarm, so you start looking at people who are by their cars like "jeez, don't they know their alarm is going off? Pretty embarrassing"
  • Got an ActivityPub Block through from someone I'm not sure I've ever interacted with, so that's fun
  • Had a lot of Lidl's excellent mango sorbet on Friday, as it was 🥵
  • While parking one day, I got a bit close to the thistles that are growing quite high on the driveway, and the car thought it must've been a child, so did a full emergency stop 😅 good to know that getting close to something - after it flags up on the parking sensors - it'll then take it into its own hands
  • Noticed that I've got a new citation on Google Scholar, in Does code review speed matter for practitioners?
  • A sign that Morph made it into the living room was that he'd vommed on the corner of the rug 🫣
  • ... but he has had some more chances to come in this week which was nice
  • Been toasty this week, especially in the latter half
  • Morph was full on hunt mode the other day by the rock wall in the back garden - we think there be mice 🐭
  • In world news, the botched Crowdstrike upgrade caused a ruckus (not for me) and Biden's pulled out of the presidency

In dependency-management-data:

  • At work, used the DMD + OPA integration with HTTP requests via endoflife.date to flag EOL statuses for some images, which is cool
  • ... but turns out not very performant. I made a little bit of an improvement (with a cache), but there's a few things needed to really make a dent
  • This has led to a more significant overhaul of how policy evaluations work (which is still WIP but so far promising) and:
    • The new model will determine which capabilities you actually use in your policies, only fetching the data that is actually needed
    • It also gave me a lil' overwhelm, as there was a fair few things to change and I was finding it hard (but probably more related to the week)
    • Looking at how to reduce the memory footprint, as right now we load everything into memory, which is significant, so instead we're going to run in batches to keep that low, and insert advisories as we go
    • I was having a particularly painful time with an INSERT INTO ... SELECT ... FROM, before finding that adding an index solved it 👏🏼
    • I'll also be adding support to pre-filter the data that gets used (i.e. where package_name like ...)
  • Had a good chat with Diogo about the usage that Deliveroo are having and some of the possible features to make things better

Played:

  • Apex Legends
  • Ratchet and Clank: Tools of Destruction

Watched:

  • The Acolyte
    • Thought it was a good ending, some very good saber battles, and a shame they had to tease some things that I really hope they can finish off!
  • New Amsterdam
  • Only Murders in the Building
  • Saturday Night Live (on YouTube)
  • Archer
  • The Great British Sewing Bee

Migrating Renovate bots, while keeping existing PRs updated
18 July 2024 | 1:05 pm

In the process of migrating from the Mend-hosted SAAS platform to a Self-Hosted deployment of Mend Renovate Community Edition, we've noticed that PRs raised by the SAAS platform, were not being updated by the Self-Hosted app.

This is down to the way that Renovate tries to not overwrite any changes that (usually a human) has pushed to one of its PRs, and that it naturally can't know that you're in the process of a migration between bots.

Our Dependency Dashboards were full of:

Edited/Blocked These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

This is down to our new Renovate bot internal-renovate[bot] not wanting to step on the toes of the existing bot, renovate[bot].

We didn't want to have to close (+ rename) all the PRs + delete branches to force Renovate to re-run, so started digging through documentation to find an alternative.

Fortunately, we can use the gitIgnoredAuthors configuration to exclude the SAAS GitHub App, by adding the following to our config.js:

module.exports = {
 gitIgnoredAuthors: [
 // the App ID + GitHub email address, via https://www.jvt.me/posts/2023/04/20/github-app-email-address/
 // alternatively, via a commit on an existing repository
 "29139614+renovate[bot]@users.noreply.github.com"
 ],
}

Once this was in place, Renovate was seeing the branches and was happy starting to modify them. However, we then hit:

{
 "level": 20,
 "branch": "renovate/github.com-urfave-cli-v2-2.x",
 "err": {
 "name": "HTTPError",
 "code": "ERR_NON_2XX_3XX_RESPONSE",
 "message": "Response code 422 (Unprocessable Entity)",
 "stack": "HTTPError: Response code 422 (Unprocessable Entity)\n ..."
 },
 "response": {
 "statusCode": 422,
 "statusMessage": "Unprocessable Entity",
 "body": {
 "message": "Validation Failed",
 "errors": [
 {
 "resource": "PullRequest",
 "code": "custom",
 "message": "A pull request already exists for ...:renovate/github.com-urfave-cli-v2-2.x"
 }
 ],
 "documentation_url": "https://docs.github.com/rest/pulls/pulls#create-a-pull-request",
 "status": "422"
 },
 "headers": {
 ...
 },
 "httpVersion": "1.1",
 "retryCount": 0
 }

As expected, there's already a PR from that branch, it just happened to be created by the SAAS bot.

To resolve this, I managed to find this GitHub Discussion which pointed towards ignorePrAuthor, which is used to support the migration between repos, by not performing the pre-optimised search to only find PRs raised by the authenticated bot.

Note that this is likely to cause performance degradation, especially on large repos, as Renovate will look through all PRs in the repo for ones that are Renovate-related.

Therefore, the final config.js you want is:

module.exports = {
 gitIgnoredAuthors: [
 // the App ID + GitHub email address, via https://www.jvt.me/posts/2023/04/20/github-app-email-address/
 // alternatively, via a commit on an existing repository
 "29139614+renovate[bot]@users.noreply.github.com"
 ],

 ignorePrAuthor: true,
}

And that should mean Renovate ✨ just works ✨


Manually triggering a Buildkite pipeline for a fork
16 July 2024 | 5:46 pm

If you're building on Buildkite, sometimes you may encounter a time where you're contributing from a fork, but CI isn't running (often by design).

So how do you get your build to start running, without pushing it to a branch instead?

If you don't have access to the ability to click the New Build button in the Buildkite UI, you're unfortunately out of luck!

However if you do have the ability to trigger a build, then we can take advantage of the way that GitHub prepares a Git ref (more info) for each Pull Request, which means we can now trigger a build of the given PR.

I.e. if we had PR 12, we'd trigger a build of refs/pull/12/head:

A screenshot of the "New Build" dialog in Buildkite, showing the "Branch" set to refs/pull/12/head, indicating the HEAD of PR 12 on the repo, and leaving the "Commit" as the default HEAD

Thanks to my colleague Isaac for the tip!



More News from this Feed See Full Web Site