iterative / iterative/gto

Restricting promotions to `prod` to commits in `main` branch

Open
#333 0 comments 0 reactions 0 assignees View on GitHub
enhancement stages
Dominant language
Python
Stars
162
Forks
18
PR merge metrics
No merged PRs in 30d

Description

A question from a client:
> Right now we have two working branches. + feature branches.
The Idea is that if we merge into development, we can test all integrations before going into main/master branch.
When using tags in studio you can circumvent the whole process by just tagging something production. Any Idea on how to restrict this?
How should the working process Ideally be? It looks like our process does not fit the style of tagging

## workaround
A workaround would be to configure CI/CD workflow so it will run in `main` branch only (not just for git tags like `model#production`). Note you can't do that in the job definition, like this (remember you workflow is triggered by a Git tag, not by a push to branch):
```
on:
push:
branches:
- main
- 'releases/**'
```
So you need to do that check manually in one of your workflow jobs (not handy).

Then a Git tag created, but the commit it points to doesn't belong to `main`, the CI will start, but the job will stop after your check.

## configuring this restriction
The other option is to implement a configuration. Since Studio reads the config from the `main` branch, you can write something like:
```
#.gto.yaml
stages:
production:
branches: [main]
```
which will prevent you from running `gto assign` on some other branch.
Although, this doesn't prevent you from creating renegade git tags manually.

somewhat related https://github.com/iterative/gto/issues/138

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.