> **Page index:** https://km.oslo.systems/llms.txt lists every page on this site, with a link to its Markdown version.

# Prepare app repository

Set up branch rulesets, and manual deployment approval for your application repository.

## Step 1: Protect your default branch

Your repository automatically inherits a set of branch rulesets from the GitHub organization when you add a specific custom property to it. These rulesets add a set of required guardrails to your repository to protect your default branch.

### Step 1.1: Set `gp-repository-type`

The value of the custom property should reflect your repository type:

- **Application repository**—the repository contains code for a single application, while the associated infrastructure lives in a separate IaC repository, such as `pirates-iac`.
- **Application repository with infrastructure**—the repository contains both application code and the associated infrastructure for a single application.

Select the tab that matches your repository type:

Go to **Settings** \> **Custom properties** and set `gp-repository-type` to `app`.

Go to **Settings** \> **Custom properties** and set `gp-repository-type` to `hybrid`.

After setting the custom property, verify that **Settings** \> **Rulesets** shows rules inherited from the organization.

### Step 1.2: Remove overlapping rulesets

The organization-level rulesets from the previous step replace any repo-level rulesets that Utviklerflyt has already set up for you - if any. If your repository has repo-level rulesets such as "Protect default branch" or "Require team approval", these can now be removed. [Contact Utviklerflyt](<https://km.oslo.systems/help/contact-us/index.md>) if you are unsure which to remove.

## Step 2: Protect GitHub Actions environment targeting production

This enables manual approval for deployments to production, and ensures that deployments to production only can be made from the default branch. This should **only** be set up for production, not for other environments.

> [!NOTE]
>
> **Manual approval**
>
> You can turn off manual approval of production deployments if you want to, but enabling it during initial setup of the new deployment pipeline is a **strongly recommended practice** to reduce the risk of negatively affecting your production environment.

1. Go to **Settings** \> **Environments** \> **New environment**
2. Set the name to match the name of your production environment:
3. For an application repository: `<environment>`, such as `pirates-prod`
4. For an application monorepo: `<environment>-<app-name>`, such as `pirates-prod-swordsmith`
5. Set **Required reviewers** to your GitHub team
6. Click **Save protection rules**
7. Under **Deployment branches and tags**, select **Selected branches** and add your default branch (`main` or `master`)

## Step 3: Disable existing workflows

If the application has existing GitHub Actions workflows that can conflict with the new deployment pipeline, disable (or delete) them before merging:

1. Go to **Actions** in the repository
2. Select the workflow to disable
3. If you're using the Boilerplate template `docker-build-push` to generate GitHub Actions workflows in your repository, disable or delete these. These workflows are suffixed with `- Build and push Docker image and send tag as dispatch event 🚀`.
4. Select the three-dot menu and choose **Disable workflow**

[Contact Utviklerflyt](<https://km.oslo.systems/help/contact-us/index.md>) if you are unsure which to disable.

## Next steps

[Add deployment pipeline](<https://km.oslo.systems/application/migrate-to-latest-cicd/add-deployment-pipeline/index.md>) for your application.