search

rockcrafters / dotnet

Ubuntu ROCKs for the .NET runtime and family
Apache License 2.0
50 stars 4 forks source link

should this repository be split to have one repo per ROCK? #17

Closed cjdcordeiro closed 2 years ago

cjdcordeiro commented 2 years ago

right now we are packing runtime-deps, runtime, and potential others ROCKs all within this GH repository.

Should we actually split it such that we have one ROCK per repo?

Pros:

Cons:

valentincanonical commented 2 years ago

Whatever is the easiest to manage!

I would advocate for something consistent but flexible-enough. As in, the name of the repo should mean something (probably the name of the ROCK?) but a project should be able to contain multiple build definitions (for example, using different build environments, adding small tweaks, publishing a debug image…).

I assume you’re thinking of runtime-deps vs runtime? We could envision something such as — from the same “dotnet” repo:

This would be consistent with our convention of “app:version-base_risk[_branch]” where the branch is a main track flavour. (The fallback mechanism must allow to fallback from a missing branch to the main track, which I believe is the case here.)

I would also understand that this might create confusion; in that case splitting into multiple projects is also fine.

Anyway, this won't be set in stone and we will be able to change it again later.

MichaelSimons commented 2 years ago

separation of concerns: if one ROCK fails to build, another might succeed

Depending on how the automation is defined I can see this as being a con. For .NET, we want to release all images as a single unit. For example, we have the following dependency tree: runtime-deps -> runtime -> aspnetcore -> sdk. The scenario of concern is say we release a new version of .NET. If the aspnetcore image fails to build, we don't want to release runtime-deps and runtime. What we want is all images to be released concurrently.

cjdcordeiro commented 2 years ago

thanks @valentincanonical .

@MichaelSimons makes a good point too.

I'm not so worried about

  • dotnet:6.0-22.04_stable —> runtime
  • dotnet:6.0-22.04_stable_runtime-deps —> runtime-deps

but once we start moving to aspnet and SDK...this feels a bit weird.

So I think it all boils down to these two questions:

valentincanonical commented 2 years ago

in the ROCKs story, can one single source generate multiple ROCKs?

I would say yes, but things will probably be easier to manage if the name of the repo means something (even if it is just a unique prefix.) We could also not care about being in a somewhat messy situation and completely unrelate the name of the repo from the name of the published ROCK. Let's discuss this on a call! (My thinking is, once again, that whatever is the easiest seem to be the best answer to the question. It doesn't look like we're making a too-deep commitment. Someday, we could imagine ROCKs will be built from upstream's GitLab/GitHub/Git{any} repos and we would not be able to rely on the git repo name anyway.)

If the repositories are split, can we ensure a cross-repository build trigger to abide by this dependency chain?

You tell me 😉 I'm thinking - why not? However, wrt our channels and risks system, it does sound to me like something that should be managed making use of the risks. Let me develop further with a(n example) solution proposal:

(we can also discuss on our next call, it'll probably be easier!)

cjdcordeiro commented 2 years ago

the current implementation is heading towards the following:

We can close this for now, saying "no, we don't need to split the repo into multiple ones"

ref: see #24 for more details on how to structure the ROCK project to have multiple ROCKs