Search documentation

Search by page, heading, or keyword.

    Documentation menu
    Early Regression Guard

    Set up your first project

    A project is one deployable thing inside a repository. On the Projects tab, a repository with none yet offers "Set up project" — you will also pick how its releases are identified. That choice is made once, by whichever project is created first in that repository, and there's no way to change it afterward.

    Early's project configuration for checkout-service showing its branch strategy: push-based release identification on main

    What this does

    A repository can hold more than one project — each folder that ships independently, most commonly in a monorepo, gets its own.

    Prerequisites

    At least one repository watched.

    Steps

    1. Open Setup in the left navigation, then the GitHub Setup tab, and enable the repository you want to set up a project for.

      Early's GitHub Setup page showing the backend repository toggled to Enabled among a longer repository list

    2. Still in Setup, switch to the Projects tab. Next to a repository with no project yet, click Set up project.

      Early's Projects tab showing three repositories, one of them offering a Set up project link

    3. Setting up a project walks you through four steps:

      a. Project Info. Choose the project’s root. For a repository with a single project, this is usually the repository root itself — but in a monorepo, it can be any folder inside it. Click Next.

      The Set up project dialog's Project Info step, naming the project and selecting its primary sub-project

      b. Release Strategy. Choose how this project tracks production releases: by tag (a release is cut from a tag) or by branch (a release is cut from a branch). If you choose tag, click Show example tags to see real tags from the repository — a matching tag pattern fills in automatically. Then choose the branch you use for production; if you don’t see it in the list, search for it. Click Next.

      The Release Strategy step showing a tag pattern with matching example tags listed The Release Strategy step's production branch field, searching for a branch by name

      c. Release Candidate. Pick the branch your team merges pull requests into — this is what Early watches to build each release candidate. If your team stabilizes code on a separate branch before it reaches production, set that branch as the Default Release Candidate Branch instead. Click Next.

      The Release Candidate step, setting the pull-request merge branch and the default release candidate branch

      d. Review & Confirm. Review the choices from all three steps, then confirm to create the project.

      The Review & Confirm step summarizing the release strategy, release candidate branch, and primary sub-project

    Warning: the release-identification method is set once per repository, by whichever project is created first in it — there’s no screen to change it afterward. If a repository will host multiple projects, get this choice right on the first one; every later project in that repository inherits it.

    Checkpoint

    The repository now shows at least one project, and mapping relationships becomes available once you have a second one.

    Next

    Map project relationships once you have a second project, or continue to adding a release candidate.

    In this section

    Map Dependencies

    Map dependencies between Early projects as your team adds them — an ongoing practice, not a one-time task.