Skip to main content

Source-control integrations

Connect a source-control provider to use its repositories as the source for application components. Once connected, its available repositories can be selected when configuring source-backed components.

Kumoto uses the connection to present repository and revision choices when you configure an application. Your selected repository and branch, tag, or commit then become part of that component's deployable configuration.

Supported providers​

  • GitHub
  • GitLab
  • Bitbucket

In Settings → Integrations, select a provider and complete its connection flow. Use the provider drawer to review repositories, sync changes, or disconnect it.

GitHub supports an app-based integration. GitLab and Bitbucket currently use token-based connections. Kumoto does not expose connection credentials in project configuration.

Connect a provider​

Before connecting a provider, decide which repositories Kumoto should be able to use. Use a dedicated organization or account where appropriate, and grant only the repository access needed for your projects.

Then:

  1. Open Settings → Integrations.
  2. Choose GitHub, GitLab, or Bitbucket.
  3. Complete the provider's authorization flow.
  4. Return to Kumoto and confirm that the expected repositories appear.

If repositories are missing after a connection is created, open the provider drawer and select Sync. Syncing refreshes the repository information Kumoto can show; it is the right first step after changing repository access with your source-control provider.

Use a repository in a component​

After connecting and syncing a provider, open an application component and select:

  • The source-control provider.
  • The repository.
  • The branch, tag, or commit that should be deployed.

Those source settings become part of the project draft. Review them alongside the component's build and runtime settings before deployment, particularly when switching a production component to a different branch or repository.

For a predictable production workflow, prefer an explicit release tag or commit when your team has one. A branch is useful for continuous delivery, but it can advance after you have reviewed a draft; make sure the deployed revision is the one you intend to run.

Keep access current​

Review integrations periodically, especially when team membership, repository ownership, or access policies change. If a repository is moved, made private, or removed from the integration's permissions, an application using it may need a new connection or updated source settings before its next deployment.

If you rotate a token or update GitHub App access, complete the provider flow again as needed and sync the integration before attempting a deployment.

Disconnecting​

Disconnecting removes the connection from your account; it does not change a running application by itself. However, active source-backed components may be unable to fetch their source for a future deployment.

Before disconnecting a provider:

  1. Review all components that use its repositories.
  2. Connect and validate a replacement provider if one is needed.
  3. Update the affected components in a project draft and deploy the source change.
  4. Disconnect the original provider only after the migration is complete.

Use Sync rather than disconnecting when you only need to refresh repository metadata.