Setting up a new Repo

Start by making sure you are in omniverse-dev DL group by going to https://dlrequest

1. Duplicate the template (kit-template repo)

alt_text

  • Rename both the project and its path to be what you want. The project name change is shown below. To change the path, go to Settings > Advanced > Change Path.

alt_text

  • Transfer the project back to the kit-extensions group with its new name. The transfer option is available under Settings > Advanced.

alt_text

To transfer you need “Maintainer” permissions on the namespace (kit-extensions). Ask someone on slack for help.

Note that the new project still has a fork relationship with kit-template, you can break fork relationship in project settings.

2. Change project name

There are several places you need to change the project name:

  • repo.toml:

# Repository Name.
name = "kit-my-funny-project"

That name is used in many other places, like solution name or package name.

  • PACKAGE-INFO.yaml change name and url

  • Each extension has repository for repo url. Don’t forget to update for your extensions.

Search for kit-template in VSCode across whole project to make sure nothing else requires renaming.

You can build, test and push that change:

> build.bat -r

> repo.bat test

3. Duplicate the TeamCity project

All TeamCity (TC) configs are stored in the repo under the .teamcity folder, so you only need to setup the root project with correct VCS url and everything else will show up in TC UI upon first build. It is easier to just copy this project, change VCS settings and run a build to achieve the same result:

  1. Go to https://teamcity.nvidia.com/project/Omniverse_KitExtensions_KitTemplate?mode=builds

  2. Click View Project Settings button on the upper right-hand corner of the page -> From the Actions menu on the upper right-hand corner of the page -> Select Copy project…. We recommend using a namespace on TC matches one on gitlab. E.g. Omniverse/kit-extensions/kit-my-funny-project. You can uncheck the Copy build configurations’ build counters checkbox. Click the Copy button on the dialog to perform the copy operation.

  3. Disable VCS settings sync (otherwise you can’t edit VCS root): View Project Settings -> Synchronization disabled -> Apply

That part requires permissions to edit “Versionned Settings” page on TC. Most people currently don’t have it. Reach out to someone with access or on teamcity slack channel.

  1. Go back into the View Project Settings -> VCS Roots and click to edit previous gitlab-master-omniverse-kit-extensions-kit-template. Change VCS root name and Fetch URL (replace kit-template with your kit-my-funny-project).

  2. Enable VCS setting sync: View Project Settings -> Synchronization enabled. Make sure:

    • Proper VCS root is selected (edited in the previous step)

    • Settings format: Kotlin

    • Allow editing project settings: off

    • Show settings changes in builds: on

    • When build starts: use settings from VCS

Hit Apply and popup appears, select: Import settings from VCS.

This will load all other settings (jobs, agents, parameters) from .teamcity folder of a newly created repo. And from now on any change in that folder will be applied on next build.

  1. Go into Build and validation job and run to make sure all works as expected.

4. What’s next?

Your new extension project is ready to use. It still builds the same demo extensions that were in kit-template. So first step would be to rename or remove them. Create your own extensions and update the application kit file in [source/apps] to load them, update [repo_publish_exts] of repo.toml to publish them.

Extra: Gitlab Settings

It is recommended to make sure approved MRs are required to work on a new repo. Settings are not preserved after fork. Recommended settings to change:

  • General -> Merge request approvals -> Eligible users -> Approvals required -> 1

  • General -> Merge request approvals -> Approval settings:

    • Prevent approval by author: on

    • Prevent approvals by users who add commits: on

    • Prevent editing approval rules in merge requests: on

    • Require user password to approve: off

    • Remove all approvals when commits are added to the source branch: off

  • General -> Merge requests -> Squash commits when merging -> Encourage

  • Repository -> Protected branches -> for master branch (and release/* in the future) -> Allowed to merge -> “Developers + Maintainers”