octoscope 0.35.0 — your activity, in the right order

Your activity, now in --json and --plain

octoscope has two halves. There is the dashboard you sit in front of, and there is the quiet half — --json and --plain — which exists so you can pipe octoscope into something else: a status bar, a cron job, a script that nudges you when something needs attention.

Until now that quiet half could tell you everything about your repositories and nothing about you. The Activity tab was screen-only.

--activity changes that. Same events, same fields, in both output formats.

octoscope --json --activity

One small decision that will matter if you build on it: when you do not ask for the feed, the recent_activity key is absent, not empty. An empty list would be a claim — "we looked, there was nothing" — and that claim would be false. A missing key lets your script tell did not fetch from nothing happened. And when you do ask and the fetch fails, that is an error, not silence.

The feed was never in chronological order

Here is the part nobody went looking for.

While wiring the feed into the reports, we checked the order. It was wrong. Not occasionally — 27 of 99 adjacent events came back out of sequence, then 28 in the next feed, then 25 in the one after that.

The events endpoint is not documented as returning a sorted feed, and it does not. octoscope had been trusting the order it was handed, which means the Activity tab has been showing you an almost sorted list this whole time. That is worse than an obviously unsorted one, because it reads as correct.

It is sorted now, at the point where events are parsed — so the tab and the reports are fixed by the same change. If you have ever glanced at Activity and thought "hang on, didn't I do that after the other thing?", you were right.

The scan reads the repository's own settings

The supply-chain scan watches for workflows triggered by things outsiders can send: issues, discussions, discussion comments, forks. It now checks whether the repository actually allows those things.

A workflow reacting to discussions on a repository with discussions turned off is not an exposure. Neither is issues on a repository only your collaborators can open one on.

This moves scores in both directions, which is worth saying plainly rather than selling as an improvement: you will see fewer findings where a repository's settings make a trigger unreachable, and more on private and internal repositories, where the axis used to stay quiet — which is exactly the case where someone with read access is the supplier worth worrying about.

Also in this release

The What's new tab had a bug where a long title ran off the edge of the pane instead of wrapping. Fixing the renderer also repairs the entries that shipped back in 0.34.1, not just this release's.

And on macOS, a release is now verified before it becomes downloadable rather than after: the signature, the hardened runtime and Apple's notarization are all checked against the files that were actually uploaded, and only then does the release go public.

Upgrade

brew upgrade gfazioli/tap/octoscope

Site: https://gfazioli.github.io/octoscope

Newsletter: https://octoscope.substack.com

Mastodon: https://hachyderm.io/@undolog