Repositories
OpsLevel can track ownership of all your git repos, not just services. Libraries, internal tools, templates, Terraform, and more.
You can use OpsLevel to manage your repositories. Teams can be assigned to repositories to promote ownership. Certain repositories can be hidden to avoid cluttering your account with old, unused repositories.
Assigning Ownership
Assigning ownership of your repositories can be done in multiple ways. This can be done from the Repositories List Page, a single Repository Details page and with config as code using opslevel.yml docs.
Repositories List Page
To define ownership of your repositories from the Repositories List Page, select which repositories you wish to edit by clicking on the checkbox next to the name.
Once you have selected 1 or more repositories, you will see the bulk actions menu become active.
When you click the Bulk Actions menu button, you will see a list of options. Press on the Set Owner action to set an owner on the repositories you selected.
From the Set Repository Owner modal, select a team from the dropdown and press Set Owner.
If you have a lot of teams in your organization, you can use type ahead search to search for a team.
If you do not wish to change the owners of any connected services, uncheck the modal checkbox shown below.
Repository Details Page
To define ownership from a Repository Details Page, hover over the owner field and click the pencil icon.
From the dropdown you can select a new owner for your repository.
If you have any services connected to your repository, you can choose to sync the owner between them.
opslevel.yml
You can also define who owns your repositories using opslevel.yml
. Refer to the opslevel.yml docs for more information.
Hiding Repositories
With opslevel.yml
and our Git integrations, you can automatically import all your repositories into OpsLevel. But you might not want to show all of your repositories. Some might contain old, deprecated services. Others could have experimental, proof-of-concepts.
You can hide these repositories in OpsLevel so that they won’t show up by default. This will ensure OpsLevel accurately reflects your production infrastructure.
By default, the Repositories List page only shows visible repositories. To view hidden repositories, you can change the View filter.
To hide repositories, select the ones you want to hide and press the Hide Repos Bulk Action.
To unhide repositories, select the ones you want to unhide and press the Unhide Repos Bulk Action.
To hide a repository while on the Repository Details page, press the gear icon and then press the Hide Repo button.
To unhide a repository, press the gear icon and then press the Unhide Repo button. Note that hidden repositories will have a Hidden label next to their name.
If a repository has a connected service, it cannot be hidden. You must disconnect it from the service if you want to hide it. This applies to repositories that were connected to services through the OpsLevel website or through opslevel.yml
.
When a hidden repository becomes connected to a service, it will automatically be unhidden and made visible.
Archiving
Git providers allow you to archive a repository, making it read-only. OpsLevel will automatically hide a repository that becomes archived. The repository cannot be unhidden while it is archived. An archived repository cannot be attached to a service. When an archived repository becomes unarchived, OpsLevel will unhide it.
If the repository has a connected service controlled through opslevel.yml
and it gets archived, OpsLevel will unlock the service, and then hide the repository. Referencing an archived repository in opslevel.yml will result in a opslevel yaml error as well.
If there are multiple repositories mapped to a service controlled through opslevel.yml
and one gets archived, OpsLevel will try to promote one of the other repositories to primary if an opslevel.yml
is found.
Deleting
Deleting a repository is an uncommon task, but sometimes a necessary task to keep your organization tidy. When you delete a repository in your git provider, we will mirror that action and delete it from OpsLevel.
If the repository has a connected service controlled through opslevel.yml
and it gets deleted, OpsLevel will unlock the service, and then delete the repository. We keep the service around in OpsLevel just in case it is still needed, so it will need to be manually cleaned up if not.
Losing Access
If we lose access to a repository, such as when permissions have been changed, we will invalidate the repository. This will allow users to delete the repository to clean it up.
If the repository has a connected service controlled through opslevel.yml
and it gets invalidated, OpsLevel will unlock the service, and then show a warning on the repository.
Updated about 1 month ago