Split verification of GitHub

Verify the GitHub setting on config page, there is some data redundancy. Besides, users will reset the verify status when modifying the date, resulting in a bad user experience.

Reduce the granularity of the step of verification and enables a new API for target resource verification.

Through two-stage verification of GitHub tokens, the first stage verifies the validity of the token, and the second stage verifies that the token can read the target branch.

• Request timing

Triggered after clicking GitHub’s verify on the config page.

• Api Design

paths: /api/v1/source-control/{sourceType}/verify
method: post
request: {
  token: "..."
}
responses:
  Status Code: 204

• GitHub Api for verification

paths: "https://api.github.com/octocat"
method: get
header: "Authorization: Bearer YOUR-TOKEN"

• Exception Handler

• Sequence Diagram

• Request timing

Triggered when the user selects a branch in the Pipeline settings module of the Metrics page.

• Api Design

paths: /api/v1/source-control/{sourceType}/repos/branches/verify
method: post
request: {
  repository: "git@github.com:XXXX/XXXX.git",
  token: "...",
  branch: "main"
}
responses:
  Status Code: 204

Note：Since the branch name may contain special characters, which will cause the URL to be unsafe, put it in the request body.

• GitHub Api for verification

paths: https://api.github.com/repos/{owner}/{repo}/branches/{branch}
method: get
header: "Authorization: Bearer <YOUR-TOKEN>"

• Exception Handler

• Sequence Diagram