Multi-profile repo proposal #108
Conversation
aclevername
force-pushed
the
mult-repo-proposal
branch
4 times, most recently
from
bfd8913
to
4d458c6
Compare
|
@Callisto13 be good to get all your thoughts on this before you go on holiday 馃槃 |
aclevername
force-pushed
the
mult-repo-proposal
branch
from
4d458c6
to
0ca0445
Compare
|
So far so good. I would definitely opt for approach one and no sub-directories for sure. |
aclevername
changed the title
aclevername
changed the title
Co-authored-by: Claudia <claudiaberesford@gmail.com>
Co-authored-by: Claudia <claudiaberesford@gmail.com>
Co-authored-by: Claudia <claudiaberesford@gmail.com>
Co-authored-by: Claudia <claudiaberesford@gmail.com>
Co-authored-by: Gergely Brautigam <skarlso777@gmail.com>
Co-authored-by: Claudia <claudiaberesford@gmail.com>
Co-authored-by: Claudia <claudiaberesford@gmail.com>
Yes this is my preference too |
| ``` | ||
|
|
||
| This approach makes it clear upon inspection what tag is actually being referenced in the repository, but is less clear what directory/profile inside the repository is being referenced. | ||
| It also maintains two completely different approaches for using `branch` vs `tag` |
There was a problem hiding this comment.
I prefer this option, path is more explicit than inferring from the tag, tagging strategies vary wildly and we can't really rely on it. Instead of a tag, you could ref a SHA (which is more reliable) and there's no path inferrable.
There was a problem hiding this comment.
Would you mind explaining what do you mean under tagging strategies vary wildly and that we can't rely on it?
I mean we apply the strategy. We create tags and we create the folder structure for it. And if it's documented, why can't we rely on it? Do you mean that people will have difficulties adjusting to it and using it in their own repos and profiles and that we can't rely on proper adoption?
There was a problem hiding this comment.
There are many tag naming policies (we are not going to be the only folks maintaining profiles).
So, it's not about us relying on our tag naming strategy, it's other folks... :-)
There was a problem hiding this comment.
Do you mean that people will have difficulties adjusting to it and using it in their own repos and profiles and that we can't rely on proper adoption?
Ok, so you're are worried about adoption part. Makes sense. But Kustomize is widely adopted and being contributed too. We could argue that this scheme is already pretty well known?
There was a problem hiding this comment.
Adding the option for SHA sounds like a nice follow up feature 馃槈
But Kustomize is widely adopted and being contributed too. We could argue that this scheme is already pretty well known?
Anecdotal but before Kevin pointed me at this repo I'd never seen this pattern before 馃槃
I think with either approach its up to us to heavily document and explain the process to the users, so it doesn't matter too much
There was a problem hiding this comment.
I am happy with the greater clarity of approach 2 馃憤
+1 this, max depth of 1 is enough to allow for multiple profiles per repo |
|
Are folks happy for this to be approved and approach 2 chosen? If so I will update the proposal to show approach 2 was chosen (I'll move approach 1 to alternatives) and write out the follow up stories @Callisto13 @bigkevmcd @Skarlso |
|
Works for me for now :-) |
cool. Re-opening as I would like this doc to be merged so we have an historical artifact |
|
Oops, didn't mean to close it. |
Description
rendered. Sorry in advance for the poor spelling and grammar, feel free to update 馃槃
Checklist
README.md(diagrams, usage, roadmap etc), and anything inexamples/)kindlabel to the PR (e.g.kind/feature)