conor 8783 do you have the need for | Dagger | Page 1

It depends on what a "project" is I guess. Is that defined somewhere yet? I think that would help me contextualize a lot of my other questions as well

To use real-world examples, we actually have two major monorepos, and kind of a monorepo within a monorepo

airbyte-platform-internal is our internal repository. Within that you have sets of commands and groups that only certain subteams will care about.

dagger do cloud build/test/publish/deploy/ci (or aircmd cloud build if I wrap it, that's what i'm doing now) is what everyone will work with

dagger/aircmd infra build/test/publish/deploy/ci works on infra/terraformy stuff and is used by my team. Maybe it does some ops related stuff too like building infra runners

Other sub-teams might have their own commands/builds for things like the connector builder server etc.

Then the oss repo (airbytehq/airbyte-platform, the public one) which airbyte-platform-internal wraps has its own oss build/test/publish/deploy/ci etc. Eventually I want to have the internal repo simply call out to the oss repo commands for this so we wouldn't be duplicating the work, since the internal one has to do the same work to build oss

Then connectors (airbytehq/airbyte) has their own sets of build/test/publish/ci

Whether all of that can be captured within single projects per repository I guess is up to what a "project" really is. Typically the overlap between interests is not much, you have one core set of commands that everyone uses (building the main repo/app), but other teams would almost never use the infra commands that my team might use (and indeed, probably wouldn't have permissions to do several of them). That was one of the design goals behind aircmd to create something that was scoped to people's interests and not flood people's CLI experience with a bunch of commands that they don't use and/or don't care about.

#conor 8783 do you have the need for