GitHub and SLAtech Vantage: commits and failed runs

SLAtech Vantage pulls two things from GitHub: the repository's commits, which are linked to the project, and failed GitHub Actions runs, which go into the error stream. The integration is read-only and uses a personal access token. When the token is fine-grained, SLAtech Vantage knows when it expires and warns two weeks ahead.

What is pulled from each commit

Commits are pulled every hour, and only new ones: a commit does not change, so a commit already stored is never pulled again. For each commit SLAtech Vantage keeps:

• the identifier (sha), message, author and date;
• the list of changed files, with the number of lines added and removed;
• the change itself in each file, when GitHub returns it. For a very large change GitHub does not return it, and then it is missing.

A commit is linked to the project and the repository, not to a particular task. A project can have more than one repository connected, for example a front end and a back end.

What commits do inside SLAtech Vantage

Two uses, and both save searching:

• Next to an error. When the error's stack trace identifies the class where it failed, the error screen shows the latest commits that touched that class's file. The answer to "what changed there recently" sits next to the error.
• In the knowledge base. Commit messages and their files go into search, so you can ask in Hebrew about a change described in English. Personal identifiers in the text are masked before it is sent for translation.

Matching by class name is rough: two classes with the same name in different places can show an unrelated commit.

Failed GitHub Actions runs

This is a separate integration from commits, and it needs a token with read access to Actions. Only runs that ended in failure, cancellation or a timeout are pulled. A successful run is not stored, and a run still in progress waits for its outcome.

• Each such run enters the project's error stream, next to the server errors.
• Grouping is by repository, workflow name, outcome and branch. "Deploy failed for the fourteenth time this week" shows as one group with a counter, not as fourteen rows.
• A run cancelled by hand is recorded as noise, not as an error: someone stopped it on purpose.

What the customer sees

The customer sees neither a list of commits nor the error stream. In the portal there is one tile: how many groups of real errors are active right now, or that everything is fine.

A question the customer asks in the portal chat can get an answer that relies on a commit message from their project, but without a link to the repository.

A failed CI run is not shown to them as a row either. If a task was opened from it, the task reaches them like any other task.

How to connect, and when the token expires

The connection form asks for a repository in the form owner/repo and a personal access token (PAT). The token is stored encrypted and never shown again. The check pulls the latest commits right then, so it proves read access to the repository itself. The project sources screen is open today to the system operator only, so the connection is made through us.

• With a fine-grained token, GitHub attaches the expiry date to its responses. Two weeks before, the connections screen flags it and an email goes to the system operator.
• When GitHub's request quota runs out, pulling stops and resumes next time from the same point, without losing commits.
• SLAtech Vantage does not open issues, comment or push code.

GitLab is supported too, including self-hosted servers: commits and, as a separate integration, failed GitLab CI pipelines. Bitbucket is supported for commits only, with a username and an app password.

Frequently asked questions