Release repo to crate.io

[ChengyuZhu6]

Do we have a plan to release the repo to crate.io? So we can use standard tooling to check for new releases in other repo like Kata.

[mkulke]

note that if you want to release to crates.io, you cannot reference workspace projects by path anymore, you need to publish every workspace project.

[ChengyuZhu6]

note that if you want to release to crates.io, you cannot reference workspace projects by path anymore, you need to publish every workspace project.

Thanks for your notification.

[fitzthum]

I would be in favor of doing this fwiw

[Xynnn007]

+1 for this. cc @jiazhang0 @jialez0

[mkulke]

If we do this I think we need to re-organize the code a bit and consolidate crates in the project to not litter the registry with internal sub-modules and have a complex release process. at the moment we have:

members = [
    "api-server-rest",
    "attestation-agent/app",
    "attestation-agent/lib",
    "attestation-agent/kbc",
    "attestation-agent/kbs_protocol",
    "attestation-agent/attester",
    "attestation-agent/deps/resource_uri",
    "attestation-agent/deps/crypto",
    "attestation-agent/deps/sev",
    "attestation-agent/coco_keyprovider",
    "attestation-agent/test-binaries",
    "confidential-data-hub/hub",
    "confidential-data-hub/kms",
    "confidential-data-hub/image",
    "confidential-data-hub/secret",
    "confidential-data-hub/storage",
    "image-rs",
    "ocicrypt-rs",
]

I think a good bunch of those can be just modules, since they're not shared across the "main" crates like cdh. A single crate can have multiple binaries and libraries.

api-server-rest probably needs a more discriptive name or needs to be subsumed into a CDH crate.

[Xynnn007]

@mkulke I think code reorgnization is a very good point. To achieve this we should think about which crates can be released separately, which crates can be combined together, and which crates can be finally deprecated.