New repository settings

All repositories in kyma-project and kyma-incubator organizations should be similar in structure, settings, and restrictions. Follow these guidelines to adjust settings of a new repository created in one of these organizations.

NOTE: You have to be an owner of the given organization to create a new repository in it.

Use the repository template

After you create a new repository, copy the basic repository structure from the template folder that is available in the community repository. It contains such files as the obligatory Apache license, the CODEOWNERS file that governs the review and approval flow in the repository, and the Stale Bot that handles inactive issues.

After copying the folder's contents, modify these according to the instructions they contain:

  • CODEOWNERS to define who is responsible for the review and approval of specific repository parts
  • to describe the repository and explain how to use and develop it

Adjust repository options

Under the repository name, choose the Settings tab. The Options view opens as the default one in the left menu.

  1. Scroll down to the Features section and clear these options:
  • Wikis
  • Restrict editing to users in teams with push access only
  • Projects


  1. Go to the Merge button section and clear these options:
  • Allow merge commits
  • Allow rebase merging

Merge button

Leave only the Allow squash merging option selected. This option combines all commits into one before merging the changes into the main branch.

Set branch protection rules

Define branch protection rules that include enforcing obligatory review and approval of pull requests (PRs), and define which Prow jobs need to pass successfully before merging PR changes into the main branch.

To see these settings, go to Branches in the left menu, under repository Settings:

Branch protection rules

In Kyma, the protection rules are defined in the Prow config.yaml file generated from rules defined in the prow-config.yaml file and handled by a Prow component called Branch Protector.

If you add a new repository in:

  • kyma-project, you do not need to add a new entry to the Prow config.yaml file as the branch protection is already defined for all repositories within this organization. The only exception is if you want to specify additional rules that are not handled by Prow.
  • kyma-incubator, add a new repository entry to the Prow config.yaml file, under branch-protection.orgs.kyma-incubator.repos. See an example of such an entry for the marketplaces repository.

Add webhooks

Add ZenHub and Prow webhooks to integrate them with your repository. This way, GitHub can send all events from the repository to Prow and notify ZenHub on the selected events related to issues and pull requests.

These settings are available under Webhooks in the left menu, under repository Settings:


Prow webhook

Only Prow admins can activate the Prow webhook. To activate the Prow webhook in your repository, a Prow admin must have admin permissions. Contact Prow admins by creating an issue in the test-infra repository with the details of your request. You can also contact them on the CI Slack channel.

To activate the Prow webook: 1. A Prow admin connects to the Prow cluster and retrieves hmac-token from a Secret. They run:

Click to copy
kubectl get secret hmac-token -o jsonpath="{.data.hmac}" | base64 --decode
  1. The Prow admin enters the hmac-token into the Secret field.

Prow Webhook

ZenHub webhook

To activate the ZenHub webhook: 1. Go to the Kyma workspace on ZenHub. 2. Click Repos and select the Add Repos option.

Zenhub webhook

  1. Choose the organization in the left bottom corner of the pop-up box, select the repository you want to add from the available list, and click the Add this repo button.

Zenhub webhook 2

Update CLA assistant configuration

Ask a kyma-project owner to add the newly created repository to the Contributor License Agreement (CLA).

Add a milv file

If you define any governance-related Prow job for the new repository to validate documentation links, you must add a milv.config.yaml file at the root of the repository. See an example of the milv file.

Create labels

Define labels for the new repository so you could use them in issues and pull requests. Follow the naming convention and color array used in other repositories such as kyma.

TIP: You can copy labels from the existing repository to the new repository using the GitHub CLI tool.

Add the repository to teams

Add the repository to both developers and developers-triage teams.