Skip to content
Original file line number Diff line number Diff line change
@@ -1,10 +1,66 @@
---
title: "Setting Up Repositories"
title: "Managing Porch Repositories"
type: docs
weight: 2
description:
description: "A how-to guide on registering Git repositories with Porch"
---

## Lorem Ipsum
# Setting Up Repositories
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This heading can be removed


tutorial in setting up porch repositories and using them
Before Porch can manage packages, you must register the Git repositories where those packages are stored. This tells Porch where to find package blueprints and where to store deployment packages.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a prerequisites section here instead?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the term "packages" a lot in the docs. Do we need to point to a "kpt package" definition somewhere just to be clear?
Also, having this as a prerequisite would suffice for me.

  • A Git repository containing your KPT packages

Or do we have a tutorial to "Set up a Git repo with dummy KPT package".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no i want to veer away from this if possible. we make it extremely clear in the concepts section here

* ***Package***: A package, in Porch, is specifically a [kpt package](https://kpt.dev/) - a collection of related YAML
files including one or more **[KRM resources][krm]** and a [Kptfile](https://kpt.dev/book/02-concepts/#packages).
{{% alert title="N.B." color="warning" %}}
There is no such thing as a "Porch Package" - rather, **Porch stores and orchestrates kpt packages**.
{{% /alert %}}
and soon in the overview also that there is no such thing as porch packages and from that point on packages means kpt packages

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think we should foster this. i see it the same way as mentioning configuration as data. having its acronym stated as CaD and from that point on you refer to it as CaD and if someone does not know what that means they should go to its definition rather than carrying the explanation throughout the entire documentation for those who did not read that section. same with stating oci as experimental. we state that once clearly and explain why it is etc and then from that point on we only really mention git repositories.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but thats just my opinion. if people disagree we can have a discussion and change it


If you don't have an Git repository already created and initialized then follow the steps below to use Gitea (already provided by the developer environment installation), or create and use your own Git repository.

## Creating Additional Gitea Repositories (Optional)

You can create repositories:

- **manually** using the Gitea web UI by following the displayed steps
- **automate** their creation using the Gitea API/CLI. The Porch project includes an example automated setup script that demonstrates how to create repositories and initialize branches:

[install-dev-gitea-setup.sh](https://github.com/nephio-project/porch/blob/23da894a8ef61fea4a4843294f249c3e1817a104/scripts/install-dev-gitea-setup.sh#L82-L100)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we do reference the automated setup, we should break it out into it's component parts and have it here as part of the tutorial.


You can customize the `$git_repo_name` variable for the custom repository you wish to create.

Below is a high-level explanation of the steps performed by that script when initializing a new Gitea repository for use with Porch.

1. Create the repository via the Gitea REST API
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might be a good manual exercise but explicitly using git cli.

2. Clone the (now-empty) repository locally
3. Ensure a main branch exists and push an initial commit
4. Clean up temporary files
5. Register the new repository with Porch using the command below

## Using `porchctl`

The `porchctl` command-line tool provides a straightforward way to register a repository.

### Command Syntax

The basic command for registering a repository is:

```bash
porchctl repo register REPOSITORY [flags]
```

For more information about the `repo` command and available flags, see the porchctl CLI guide [Repository registration]({{% relref "/docs/neo-porch/7_cli_api/relevant_old_docs/porchctl-cli-guide.md#repository-registration" %}}).

### Example

This example registers a private Git repository hosted on Gitea and configures it as a deployment repository.

```bash
# Register a Git repository with Porch
porchctl repo register http://gitea.gitea:3000/nephio/porch-test.git \
--name=porch-test \
--description="Test repository for Porch packages" \
--branch=main \
--deployment=true \
--repo-basic-username=nephio \
--repo-basic-password=secret
```

# See Also

In this example we demonstrate a simple HTTP Basic auth setup using a Kubernetes `Secret`. For production environments, prefer secret management solutions (external secret stores, sealed-secrets, or platform secrets) and avoid embedding plaintext credentials in scripts.

[Authenticating to Remote Git Repositories]({{% relref "/docs/neo-porch/6_configuration_and_deployments/configurations/private-registries.md" %}})
Loading