-
Notifications
You must be signed in to change notification settings - Fork 224
What happens if there are two suborgs mapped to the same repository? #418
Suppose I have these two files:
# admin/suborgs/example.yml suborgs: - example-*
# admin/suborgs/example-foo.yml suborgs: - example-foo-*
And then I were to create a repo named example-foo-bar.
Would it apply one or both suborg settings, and in which order?
All reactions
Hi @justinmchase, it will apply only one of the suborg configurations. I haven't checked yet for the order but I assume it loads the setting files alphabetically and the last one would take precedence.
To prevent from these situations I have implemented in our org a validator, which validates the yaml files based on a schema + ensures that suborgs do not have overlapping repos.
If there is interest I might consider open sourcing the validator. At least the tool ensures that users get immediately informed in a PR through annotations if they made a mistake/typo in the settings.
Replies: 3 comments 4 replies
Hi @justinmchase, it will apply only one of the suborg configurations. I haven't checked yet for the order but I assume it loads the setting files alphabetically and the last one would take precedence.
To prevent from these situations I have implemented in our org a validator, which validates the yaml files based on a schema + ensures that suborgs do not have overlapping repos.
If there is interest I might consider open sourcing the validator. At least the tool ensures that users get immediately informed in a PR through annotations if they made a mistake/typo in the settings.
All reactions
That's about what I figured. Does your validator account for wildcards? I'm not sure how it can do that without enumerating all repos in the org.
All reactions
I don't need to check for all repos in the org. I only ensure that there is no overlap within the suborg settings.
Example:
suborgA:
suborgrepos:
- my-prefix-*
- my-repo-a
suborgB:
suborgrepos:
- my-*
- my-repo-a
The validator will spit out the following error:
::error file=.github/suborgs/suborgA.yml,line=1,col=1,endColumn=1::my-* matches repositories in 2 file(s): {'suborgA.yml', 'suborgB.yml'}
::error file=.github/suborgs/suborgB.yml,line=1,col=1,endColumn=1::my-* matches repositories in 2 file(s): {'suborgA.yml', 'suborgB.yml'}
::error file=.github/suborgs/suborgA.yml,line=1,col=1,endColumn=1::my-repo-a matches repositories in 2 file(s): {'suborgA.yml', 'suborgB.yml'}
::error file=.github/suborgs/suborgB.yml,line=1,col=1,endColumn=1::my-repo-a matches repositories in 2 file(s): {'suborgA.yml', 'suborgB.yml'}
All reactions
Suppose you had my-* in suborgA.yml and my* in suborgB.yml, how would you be able to determine that my-* still matches in both A and B?
Are you actually doing a wild card eval of the overlaps or are you just comparing if they have the exact same match pattern?
All reactions
I have been playing around with suborg matching the same repository and the order in which the suborgs are evaluated is indeed alphabetical.
Which means, you could enforce a specific order by naming your suborg settings files accordingly, e.g., my-suborg-0001.yml, my-suborg-0002.yml, etc. where the latter one is overriding settings from the previous.
All reactions
Not to hijack this but @martinm82 how did you implement the validator, as a plugin or a simple validator in deployment-settings?
All reactions
I have implemented this as a Python script which is executed in a GitHub workflow on PRs.