Skip to main content
Code Authoring is SGP’s built-in version control and CI/CD surface. Every SGP deployment can run its own git server (powered by Gitea) inside the same cluster as the rest of the platform, with CI runners colocated alongside it. You get a normal git experience: clone over HTTPS, push branches, open pull requests, review diffs, and watch CI run. What is different is that there is nothing to set up. No external git host, no runner to provision, no network path to negotiate between a CI runner and your cluster, and no second set of credentials: your existing SGP API key and SGP login are the only credentials involved.
Your git server lives at https://gitea.<your-sgp-domain> and never leaves your SGP deployment. Source code, build history, and CI logs stay inside your environment’s trust boundary.

​
Why it exists

Standing up version control used to be the slowest part of a new deployment. It meant creating a repository on a vendor-managed host, wiring up mirroring, copying CI workflow files by hand, provisioning a runner, and then opening a network path from that runner into the target cluster. That last step was usually the blocker, because corporate security policy rarely allows an external runner to reach an internal cluster. Code Authoring removes the problem by construction. The git server and its CI runners are colocated with the workloads they build, so the “runner reaches the cluster” question never comes up.

​
What you get out of the box

When Code Authoring is enabled on your deployment, SGP provisions: Access is governed by your existing SGP account roles: there are no separate git accounts, passwords, or SSH keys to manage.

​
Getting started

1

Get your credentials

You need two things:
  • Your SGP API key, from the SGP UI under Settings → API Keys
  • Network access to https://gitea.<your-sgp-domain>, the same way you reach the SGP UI
2

Clone a repository

Your SGP API key is used as the git password. The username field is ignored, but it is conventional to use your SGP user ID or email.
To avoid pasting the key on every operation, store it with a standard git credential helper, the same way you would a personal access token:
3

Browse in the web UI

Open https://gitea.<your-sgp-domain> in a browser. If you already have an SGP session you are signed in automatically; otherwise choose Sign in with Scale SSO and authenticate with your normal identity provider.From there you can review pull requests, read diffs, inspect CI runs, and manage repository settings.

​
How it works

Every request (git, REST, or browser) passes through the same SGP authentication layer before it reaches the git server: The auth layer validates your credential against SGP’s identity service, creates your git account the first time it sees you, and then forwards the request. You never create a git account, and there is no separate password to rotate. Workflows are ordinary GitHub Actions-compatible YAML in .gitea/workflows/, triggered by the events you would expect: pushes, pull requests, comments, schedules, and manual dispatch. Because the runners sit inside your deployment, a workflow step can call the SGP APIs directly over the in-cluster address. Store your SGP credential as a repository Actions secret and any job can build, deploy, evaluate, or query through the platform:
Secrets and variables are managed per repository under Settings → Actions → Secrets and Settings → Actions → Variables in the web UI.
Treat an SGP API key stored as an Actions secret as a deployment credential. Anyone who can push a workflow to the repository can use it, so keep repository write access aligned with who you would trust with that key.

​
Access control

Repositories are scoped to an SGP account. When a repository is bound to an account, your role on that account determines what you can do with it: Access is evaluated on every request, so revoking someone’s SGP account role revokes their git access immediately. There is nothing to un-share in the git server itself.

​
Working over the API

Anything you can do in the web UI you can do programmatically. The git server exposes a REST API at https://gitea.<your-sgp-domain>/api/v1/..., authenticated with your SGP API key:
Create repositories, open pull requests, list commits, read and write files in batch, and manage branch protection, all with your standard SGP credential. Interactive API documentation for your deployment is served at https://gitea.<your-sgp-domain>/api/swagger, and the raw OpenAPI specification at https://gitea.<your-sgp-domain>/swagger.v1.json. Standard git tooling works too: the tea CLI and the Gitea Go SDK authenticate with your SGP API key in place of a native access token.

​
Current limits

A few things to know before you plan around them:
  • HTTPS only. SSH git access is not offered. Every operation goes over HTTPS with your SGP API key, which covers CLI, CI, and programmatic use.
  • Squash merges only. The default branch is main and squash is the only merge style, so history stays linear across every repository.
  • Brief maintenance windows. The git server runs as a single instance, so platform upgrades involve roughly thirty seconds of unavailability. Running workloads are unaffected; only git operations pause.