iterative
Applying config
Following the question by @tapadipti
Where will the list of all possible stages be defined? Or, is the user free to provide free text stage names?
There is a config file called .gto that user commits to the repo. In it, he can specify list of allowed stages. GTO has API to provide that: gto.api.stages() will return what user has specified, e.g.: [prod, stage]. If he didn’t specify anything, API will return empty list [] - which means any Stages are allowed.
One related question is this: now in CLI we read that config from workspace. E.g. if you’re on HEAD, then we read it from HEAD. I guess it does make sense to read it from the commit we are creating the actual promotion in. E.g. if I create git tag that reference commit abc1234 - should I read config from there?
I think reading from current workspace is easier and has more useful application. E.g. if I want to add something the allowed list, I want to be able to promote to that env even from previous commits, as opposed to limiting myself with types I specified in that commit.
The other question is: can I have a scenario when in different HEADS I want to have different STAGE_ALLOWED lists? E.g. in master I want to have prod, in dev I want to have dev. Then to promote to prod I would need to merge my model from dev to prod - and then promote.
Another thought - can I somehow restrict creating tags in master only? E.g. create TYPE_ALLOWED=[prod, dev] in master, but disallow promotion in other branches with something like PROMOTION_DISALLOWED=True?
Or should it be TYPE_ALLOWED=[] and gto stages should return different things when TYPE_ALLOWED=None and TYPE_ALLOWED=[]?
I think we should allow using stages defined in other commits also. Question: Does Studio need to provide a way for users to update the list? For the scope of the current Model Registry project, I'm assuming not. But want to confirm.
@tapadipti
I think we should allow using stages defined in other commits also.
By using do you mean promoting to them, or just showing in UI? Or using in CI / by downstream systems?
Question: Does Studio need to provide a way for users to update the list? For the scope of the current Model Registry project, I'm assuming not. But want to confirm
No, not now definitely :)
By using do you mean promoting to them, or just showing in UI? Or using in CI / by downstream systems?
promoting to them