Skip to main content
You configure repositories, applications-live reviewers, and pull request rules in self-service.tfvars. Every change follows the same pull request flow. For more information, see Self-service.

​
Add a repository

To add a repository, add an entry to the repositories section of self-service.tfvars. The entry key is the repository name. The following example creates a repository from a Backbase template ZIP:
The following options are the ones you use most often:
  • repository_init_from_zip: initializes the repository from a template ZIP, identified by name and version. Only ZIPs from the Backbase accelerators repository are accepted. The ZIP applies only if nobody has pushed commits to the repository yet.
  • default_branch: the default branch. The default is develop. You can set it only when the repository is created.
  • enable_branch_protection: applies default branch protection, such as one required approval and code owner review. The default is true.
  • protected_branches: the branches that branch protection applies to. The default is ["main", "develop"].
  • required_status_checks: the status checks that must pass before a merge. The default is an empty list.
  • repository_archived: archives the repository when set to true.
For complete repository examples, see Create a custom API and Get started.

​
Archive a repository

When you no longer need a repository, set repository_archived = true instead of deleting it. Only a development-admin team member can delete a repository, in the repository settings on GitHub. After a deletion, remove the repository entry from self-service.tfvars.

​
Set applications-live reviewers

By default, every member of the applications-live GitHub team reviews pull requests to the applications-live repository. You can change this per runtime in one of two ways:
  • runtime_codeowners_override: sets the reviewers for a runtime, for example production deployments.
  • auto_approve_runtimes: a bot approves pull requests for the listed runtimes, so you can merge after the checks pass.
The two options don’t combine. Choose one approach. The following example sets the reviewers for the prd runtime:
The following example turns on automatic approval for the dev runtime:
If a pull request changes an auto-approved runtime and another runtime, the bot approves it. The merge stays blocked until the review rules for the other runtime are met.

​
Require pull request title scopes

You can require pull request titles in applications-live to follow the Conventional Commits format, with a Jira project key in the scope. To set the valid scopes, use pr_title_scopes:
A valid title then looks like feat(PROJECT_KEY-1234): Update connector values. Set PROJECT_KEY to a scope your installation uses.

​
Manage secrets

Store connector secrets as SOPS-encrypted files in the applications-live repository, under runtimes/{runtime}/secrets/. Encrypt each file with SOPS before you commit it. Don’t edit the encrypted file by hand, because that breaks the secret. To encrypt a file or change a secret, follow the secrets README in that folder.