Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable independent crate versioning for SDK crates #1540

Merged
merged 16 commits into from
Jul 19, 2022

Conversation

jdisanti
Copy link
Collaborator

@jdisanti jdisanti commented Jul 7, 2022

Motivation and Context

This enables SDK crates to version independently of each other so that a release only has to publish changed crates rather than every single crate even if it has no changes. This also enables multiple SDK releases per smithy-rs release since manual version bump is no longer required.

Testing

  • Do a dry-run smithy-rs release with the changes and verify the artifacts
  • Do a dry-run SDK release with the changes and verify the artifacts

Checklist

  • I have updated CHANGELOG.next.toml if I made changes to the AWS SDK, generated SDK code, or SDK runtime crates

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@github-actions
Copy link

github-actions bot commented Jul 7, 2022

A new generated diff is ready to view.

A new doc preview is ready to view.

@github-actions
Copy link

github-actions bot commented Jul 7, 2022

A new generated diff is ready to view.

A new doc preview is ready to view.

@github-actions
Copy link

github-actions bot commented Jul 7, 2022

A new generated diff is ready to view.

A new doc preview is ready to view.

Copy link
Collaborator

@rcoh rcoh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only blocker is figuring out the aws-config version stuff, otherwise LGTM

}
} else {
// TODO(https://github.com/awslabs/smithy-rs/issues/1531): Remove V1 args
println!("Failed to match new arg format. Trying to parse the old arg format.");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eprintln?

Comment on lines +22 to +24
#[derive(Parser, Debug)]
#[clap(author, version, about)]
enum ArgsV1 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is exactly the same right (except for HydrateReadmeArgsV1?) In general, probably nice to have a module of arg versions or something. V1 being old and Args being the latest was a bit confusing

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem worth it to me since the V1 will be short lived. I agree, it is slightly confusing, but it's not terrible.

Comment on lines +206 to 210
fn hash_models(projection: &SmithyBuildProjection) -> Result<String> {
// Must match `hashModels` in `CrateVersioner.kt`
let mut hashes = String::new();
for import in &projection.imports {
hashes.push_str(&sha256::digest_file(import).context("hash model")?);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how does this get used from the Smithy side vs. Rust side?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The publisher tool's generate-version-manifest subcommand creates the versions.toml which includes the model hashes, where this Rust implementation is used.

The Gradle build system then reads the prior release's versions.toml and determines if models were changed by doing its own model hashing.

An alternative we could consider is creating a tool that does model hashing and use it from both.

@@ -27,12 +27,17 @@ mv aws-doc-sdk-examples/rust_dev_preview smithy-rs/aws/sdk/examples
rm -rf smithy-rs/aws/sdk/examples/.cargo
rm smithy-rs/aws/sdk/examples/Cargo.toml

echo -e "${C_YELLOW}Creating empty model metadata file since we don't have model update information...${C_RESET}"
MODEL_METADATA_PATH="$(pwd)/model-metadata.toml"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's model-metadata and how does this compare with the versions manifest?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The model metadata is produced by the automation that brings in the latest SDK service models, and includes information such as what kind of change it was (documentation only, or APIs), and a changelog entry describing the change.

The generate-aws-sdk script is only used in CI, and validates that a SDK can be successfully generated. It's not used to generate the SDK for releases since the sdk-sync tool does that, and there, model metadata and codegen changes get incorporated.

@@ -62,7 +63,7 @@ class AwsReadmeDecorator : RustCodegenDecorator<ClientCodegenContext> {

```toml
[dependencies]
aws-config = "${codegenContext.settings.moduleVersion}"
aws-config = "$awsConfigVersion"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is special because we don't have access to the versions manifest at this point?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. The service crates get generated before the version manifest is created. This is OK though since service crate generation only needs the version numbers of runtime crates.

Comment on lines +25 to +27
val awsConfigVersion: String get() =
awsSdk?.getStringMember("awsConfigVersion")?.orNull()?.value
?: throw IllegalStateException("missing `awsConfigVersion` codegen setting")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably worth noting that this is only for docs? Is this actually used during codegen? (I think it's not?) We should probably use it otherwise it may be surprising when it doesn't actually change the aws-config version when we generate the aws-config dependency normally

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It uses a path dependency when it generates the service crate, so that should always be correct. The fix-manifests tool inserts version numbers after the fact. I think this all should be fine until we make runtime crates version independently, at which point this all needs to be revisited anyway. The mechanism for that revisiting will be the removal of the smithy.rs.runtime.crate.version Gradle property, which should reveal all the locations that rely on it, including this one.

@@ -72,6 +72,8 @@ fun eventStreamAllowList(): Set<String> {
}

fun generateSmithyBuild(services: AwsServices): String {
val awsConfigVersion = properties.get("smithy.rs.runtime.crate.version")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this under the assumption that the aws-config version always matches the smithy.rs runtime crate version? I think those are different numbers—aws-smithy-http is on 0.44, eg.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR makes all the runtime crates use the same version numbers. They all use smithy.rs.runtime.crate.version now. This will result in a version number jump from ~0.15.0 to ~0.46.0 for the AWS runtime crates on the first release that has these changes, but that should be fine.

@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@rcoh rcoh requested a review from a team as a code owner July 19, 2022 17:43
@github-actions
Copy link

A new generated diff is ready to view.

A new doc preview is ready to view.

@jdisanti jdisanti merged commit 6143d90 into main Jul 19, 2022
@jdisanti jdisanti deleted the jdisanti-independent-sdk-versions branch July 19, 2022 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants