[question] Conan workspaces CI

[IYanakiev34]

What is your question?

Hello,
I have recently started using the workspaces as it fits my monorepo style project. I'd like to ask using the workspaces how can I automate the CI process in respect the packages and products. From what I understand when we declare new packages or products in the conanws.yml section they implicitly become editable which means they will be marked as editable when built and not in the local cache. My first question is how can then I use conan create and ensure the package goes into local cache so that we can later do conan upload and upload to a registry. Secondly, let's say I have 2 products and 4 packages which the products use. My question is how a CI using workspaces has to generally be structured. The idea is we would like to ensure correct rebuilding of products and dependencies based on packages. Since packages can depend on one another an products depend on packages the CI will trigger when a folder has changed. Let's say a package has changed and a product depends on this package. We would like to rebuild the package upload it and then rebuild any product which uses the package and upload as well. My 2 struggles are: how to perhaps use the graph API to detect such changes and rebuild correctly, 2 how to use the workspaces correctly so that we can actually create the packages and upload them to a remote registry. I've read the CI tutorial and it makes sense but I struggle to conceptualize how it could be applied to a monorepo with multiple products and packages which depend on each other and the build order matters. Thank you in advance!

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @IYanakiev34

Thanks for your question (though I think it is actually a feature request too).

At the moment, the workspace implements the standard or "canonical" flow, in which the developers use the workspace to develop their code locally, but the creation of packages typically happens in CI. So developer only care about their local workspace, and when they are done they commit their changes to git, push, and the CI will build those as individual packages, not as a workspace.

Then, the CI will take care of building the packages. This building can be managed as concurrent builds of different packages, or if the Pull Request mechanism admits managing several PRs to different repositories in a coordinated way, the same principles can apply. The CI recommendations are documented in https://docs.conan.io/2/ci_tutorial/tutorial.html, where the conan graph build-order is used to obtain the order to build things.

Then, a secondary use case or user flow that hasn't been implemented yet, is a conan workspace create or similar command, that will do an orchestrated creation of packages from a workspace in the cache. This shouldn't be very difficult, I already started the task in some branch some time ago, and I have plans to resume working on it soon. This conan workspace create might be used locally by devs to ensure that the package creation process works fine locally, and maybe in the CI side it might not be necessary or maybe it it also useful there, depending on how the rest of the CI is managed, how other packages that do not belong to the monolithic workspace are managed and evolved, etc.