Using Cicada

This is Cicada Note #3 . For a background on Cicada and Cicada Notes, read Introducing Cicada.

In the previous two Cicada Notes I started describing Cicada’s architecture. Before I get too bogged down in the “how” of Cicada, I wanted to briefly show what it actually does. So this Note is a quick tour of Cicada’s user interface so far.

Account Screen

Cicada is, for now, a web app. When I visit its home screen I see this:

This is pretty plain - that’s because Cicada only has anything useful if I login. I can do that by clicking the login link, and once I go through GitHub’s login process (Cicada uses GitHub identity for authentication) then I can see something more interesting:

This screen shows the current status of all GitHub Actions Workflows in my GitHub Account, and some summary details of any recently updated repository branches in the account.

A GitHub Account is either a GitHub Organization, or a personal account. I myself am a member of several GitHub Organizations, and I also have my own personal account repositories. However in the example above I only see data for the symphoniacloud Organization. That’s because (at the moment) one deployed instance of Cicada can only access one Account. If I want to see my personal repositories I’d need to go to a different host and login there.

Screenshots in this article are from accessing Cicada with my desktop browser, but Cicada works on a mobile device too.

Account-wide GitHub Actions Status

This screen is immediately useful for anyone used to using GitHub Actions because GitHub Actions only has a native UI on a per-repository basis. Instead Cicada lets me see status across repositories.

Each row in the GitHub Actions Status table corresponds to one GitHub Actions Workflow, and specifically shows data related to the most recent run for each workflow. The color represents the current status - successful / failed - and each field is something interesting about the run.

Notice also that there are a lot of links. Any octocat-icon link is a deep link into GitHub’s web app for that particular element - so I can drill into a repo, workflow, workflow run, user, or commit for each workflow. The regular links target other views in Cicada.

For now Cicada only deals with completed runs. I plan to also show in-progress runs, but things get a little complicated then for workflows that allow concurrent runs.

Account-wide Recent Branch Activity

The Recent Branch Activity table shows any branches that have been active recently, again across the whole account. “Recently” for now means “in the last 2 weeks”. I suspect I’ll have to make that more flexible soon.

The table shows at most one row per branch, and so for each branch I can see the details related to the most recent commit pushed for that branch to GitHub. Like the Actions Status table, there are many deep links into GitHub’s web app, plus I can also jump to Cicada’s repository view.

Aside: Scalability of the UI, and security

If you’re thinking “there’s no way this would work well for my organization of 1000 developers and 10000 repositories” then you’re probably right. 😀 As of today my goal has been to get Cicada working at all, for small organizations and personal accounts. In theory it will still work for larger organizations, but I suspect it won’t be so effective.

Another important point for larger organizations is that Cicada’s security model today is solely based on a user’s membership of an Account - it’s no more granular than that. In other words if I’m a member of a GitHub organization, and someone has setup Cicada for that organization, then I will be able to see all repositories, workflows, and commit summaries for that organization. If you have an organization where read-access is restricted for some repositories then Cicada will make too much information visible to certain members of your organization.

Repository Screen

Whenever I click on a repository name in Cicada I switch to the repository screen. Here’s the repository screen for the repository where I manage this blog:

The top of this screen shows the GitHub Actions Workflow status for workflows that belong to this repository. It’s the same detail as for the account-wide screen, just filtered to this specific repo.

In GitHub Actions all Workflows belong to exactly one repository, even if they read data from multiple repositories.

The second table is the first historical table I’ve shown so far. Instead of having just the latest activity per workflow or branch, this shows all activity, historically, for all workflows and branches in the repository. Green rows are successful workflow runs, red rows are failed workflow runs, blue rows are pushes to branches.

The reason I show both workflow runs and pushes in the same table is that not all repositories will have any, or any active, Actions workflows, but Cicada can still provide some useful data in this case.

Right now this table will only show one “page” of data (ordered by most recent history first) but I hope to add paging controls in the future.

Workflow Screen

Whenever I click on a workflow name in Cicada I switch to the workflow screen. Here’s the workflow screen for Cicada’s own Continuous Integration Actions workflow:

You can see the actual GitHub UI for this workflow here and the definition for this workflow here

This screen is more simple than the other two. For now it just shows history of completed runs, whether they were successful or failures, together with deep links to the relevant GitHub objects.

Subscribing to Push Notifications

On any (logged in) screen I can navigate to Manage Web Push Notifications. This screen has one control where I can subscribe to and unsubscribe from these notifications.

Web Push Notifications are a web standard supported by all main browsers on both desktop and mobile devices. Web Push allows a (trusted!) application to send real-time notifications to a user of a website, and that notification will appear outside of the web page, and instead appear in the device’s regular notification system. This is very like regular mobile application notifications, except it’s driven by a web app and not a full native app.

On an iPhone Cicada notifications look like this:

Web Push notifications aren’t automatically enabled - I allow the user to explicitly opt-in. For Cicada notifications are published for any completed GitHub Actions workflow run. This is likely a little too “chatty” for most accounts, and so I hope to add more fine grained control at a later date.

One other point - Web Push notifications only work on an iOS device for a Personal Web App (PWA) - this is a website that has been “added to the home screen”. So to get notifications on an iPhone or iPad you need to add Cicada to the home screen (via the share icon in Safari), launch Cicada from the home screen, login, and then subscribe.

Summing up

In this Cicada Note I showed the current user interface for Cicada. Primarily it’s useful today for providing GitHub Actions data in a way that GitHub doesn’t give itself, e.g. workflow status across repositories, and device notifications for completed workflows.

Feedback

I value hearing what people think about how I’ve built Cicada, and also my writing in Cicada Notes. If there ends up being enough interest I’ll start some kind of discussion forum, but for now please either email me at mike@symphonia.io, or if you’re on Mastodon then please kick off a discussion there - my user is @mikebroberts@hachyderm.io .