-
Notifications
You must be signed in to change notification settings - Fork 196
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
Conversation
The release tag should be added to the versions manifest at the very end of the release process rather than for each individual synced commit.
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
There was a problem hiding this 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
tools/publisher/src/main.rs
Outdated
} | ||
} 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."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eprintln?
#[derive(Parser, Debug)] | ||
#[clap(author, version, about)] | ||
enum ArgsV1 { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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")?); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
val awsConfigVersion: String get() = | ||
awsSdk?.getStringMember("awsConfigVersion")?.orNull()?.value | ||
?: throw IllegalStateException("missing `awsConfigVersion` codegen setting") |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
A new generated diff is ready to view.
A new doc preview is ready to view. |
A new generated diff is ready to view.
A new doc preview is ready to view. |
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
Checklist
CHANGELOG.next.toml
if I made changes to the AWS SDK, generated SDK code, or SDK runtime cratesBy submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.