Restricting promotions to `prod` to commits in `main` branch
- 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.