iterative / gto

🏷️ Git Tag Ops. Turn your Git repository into Artifact Registry or Model Registry.
https://dvc.org/doc/gto
Apache License 2.0
142 stars 16 forks source link

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

Open aguschin opened 1 year ago

aguschin commented 1 year ago

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