A customer told us their code lives on git.cafe, and only there: no GitHub mirror, pull requests reviewed on git.cafe, and CI running on GitCafe Actions. Happo had no way to report back to any of it. So we built git.cafe support, and it's live now, labeled experimental.
If you're on git.cafe and you've been waiting for Happo to show up next to the rest of your checks, you can go connect a repository now.
What does a repo connection do?
Check runs on your commits and pull requests. If Happo can't report back to your pull request, the diff review stops being part of the review. A Happo check that sits right there next to your lint job and your unit tests is the whole reason visual regression testing works. Each Happo project gets its own check, and it goes from in progress to passed or failed as the comparison finishes.
Backtracking through history to find the newest baseline report. When you open a pull request, Happo needs to figure out what to compare against. That's not always the tip of your main branch, because the tip of main might not have a report for that project. So we walk back through the commit history looking for the most recent commit that does have one. To do that, Happo syncs the order of commits on your default branch from git.cafe's API. This is what keeps baselines sensible when Happo doesn't run on every commit, or when your CI makes a shallow clone.
A token that can't read your code
This is the part I'm happiest with. Happo doesn't need your code, and we don't want it. Your CI builds your components and sends Happo what to screenshot; Happo never clones your repository. All it needs from git.cafe is a place to put a check.
When we first built the integration, Happo posted commit statuses, and git.cafe only lets a token do that if it can also write to the repository's contents. Read and write access to your code, just so a bot can put a green check next to it. That's a lot to ask of anyone, and more than we wanted to hold.
So we switched to posting check runs instead. The token Happo needs has one permission, Checks: Write, and you can limit it to just the repositories Happo should post to. It can't read your code, and it can't push to it. It can post checks, and that's it.
Commit history is optional. You can opt into an additional permission that lets Happo sync your history for the baseline lookups above, and chart accessibility issues over time. Without it, Happo still finds baselines from the commits your CI sends. We're hoping to improve this as git.cafe builds out their service.
git.cafe tokens always expire, after a year at most. When yours does, Happo stops posting checks and tells your account admins, at the top of the account's pages, to save a new one, rather than going quiet without saying why.
Setting it up
You'll need to create a personal access token in git.cafe under Settings → Tokens, then fill in the form on the git.cafe integration page with the token and the repository's owner and name. Pasting the repository's URL into either field fills in both.
When you connect, Happo tests the connection before saving it. It checks that the token can post checks to the repository, without leaving a check behind, and warns you if it can't read the commit history. If something is off, it says what: an expired token, a repository the token can't see, a missing permission. Once you're connected, Check now runs the same test whenever you like. Projects that live in other repositories under the same owner can point at their own repository from each project's edit page.
The git.cafe section of the docs at docs.happo.io/docs/continuous-integration#gitcafe walks through each step, if you want to read ahead before you start clicking.
Why it still says "experimental"
We've posted real checks to real git.cafe repositories with real tokens, and the integration works in our testing. But a team has not been running it against a busy repository with real pull requests and real CI concurrency for months. Battle testing tends to surface things nobody thinks to write a test for: the weird branch name, the fork, the pull request that got retargeted, the branch protection rule that was set up around something else.
In other words, there might be some bugs or rough edges hiding. If you hit something that could use our attention, email support@happo.io.
Using something we don't support yet? Tell us!
Happo already supports GitHub, GitHub Enterprise, Bitbucket, Azure DevOps, GitLab, and now git.cafe. If Happo doesn't support what you are using, email support@happo.io, even if you aren't ready to sign up yet. This integration exists because one customer asked.
And if you're on git.cafe and you try this in the next few weeks, I'd love to hear how it goes. Especially if it goes badly. That's how the word "experimental" comes off.
