When using JDK 20, the following error would occur when attempting to
build or run tests:
```
Execution failed for task ':codegen-client:compileKotlin'.
> Inconsistent JVM-target compatibility detected for tasks 'compileJava' (20) and 'compileKotlin' (11).
```
This PR explicitly sets the Java source and target versions to fix this
error.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Fix deprecation warnings in the gradle build scripts, and upgrade jsoup
and gson.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: ysaito1001 <awsaito@amazon.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
This PR updates our smithy-rs release tooling to prepare for handling
both stable and unstable crates. Merging this PR to `main` does not make
any of the runtime crates stable, instead we will just have a supporting
mechanism in place, ready to be turned on by implementing `TODO(GA)`.
## Description
At a high level, this PR will
- update the `Release smithy-rs` workflow UI to have an additional input
`Stable semantic version`:
- split an existing gradle property `smithy.rs.runtime.crate.version`
into `smithy.rs.runtime.crate.stable.version` and
`smithy.rs.runtime.crate.unstable.version`.
- make `publisher upgrade-runtime-crates-version` take a new, optional
(for backwards compatibility) command line argument `--stable-version`
to use the said gradle property
`smithy.rs.runtime.crate.stable.version`. This will allow the
`publisher` to set a value passed via a workflow input `Stable semantic
version` to `smithy.rs.runtime.crate.stable.version` in
`gradle.properties` (and the same goes for unstable crates).
- update `fixRuntimeCrateVersions` so that it fixes up runtime crate
versions based on properties `smithy.rs.runtime.crate.stable.version`
and `smithy.rs.runtime.crate.unstable.version`.
**NOTE**
There is a guard in place. When this PR gets merged and then we enter a
stable crate version in the `Stable semantic version` text box, it will
be overwritten by a version in `Unstable semantic version`, so that
1.x.y version will NOT be published to `crates.io` before GA and that
also replicates today's release workflow's behavior (only publishing
unstable crates). Just make sure we specify a 0.x.y in the `Untable
semantic version` text box because that does get shipped.
### What happens once `TODO(GA)` has been implemented?
Roughly, it will look like this. When we run the `Release smithy-rs`
workflow (not a dry-run), providing a stable version (say 1.0.0) and a
unstable version (say 0.57.0) in the workflow text boxes,
1. the workflow will create a new release branch
`smithy-rs-release-1.x.y`.
2. the workflow will set 1.0.0 to
`smithy.rs.runtime.crate.stable.version` and 0.57.0 to
`smithy.rs.runtime.crate.unstable.version` in `gradle.properties`.
3. for whatever smithy runtime crates whose package metadata says
```
[package.metadata.smithy-rs-release-tooling]
stable = true
```
their `Cargo.toml` will include `version = 1.0.0` (and `version =
0.57.0` if `smithy-rs-release-tooling` is not specified or if its value
is `stable = false`).
4. the workflow will publish smithy runtime crates accordingly to
`crates.io`.
5. releasing `aws-sdk-rust` subsequently will render `version = 1.0.0`
in `Cargo.toml` for stable AWS runtime crates (again as specified by
`smithy-rs-release-tooling`), will render `version = 1.1.0` for SDK
crates (we will not go into details here as to why it's not `1.0.0`),
and will publish those crates to `crates.io`.
## Testing
In a [separate
branch](https://github.com/awslabs/smithy-rs/tree/ysaito/stable-and-unstable-crates)
that implemented `TODO(GA)`, I verified that
- our internal release pipeline was executed without errors
- a generated AWS SDK had following manifests (showing excerpts from
arbitrary crates)
```
[package]
name = "aws-sdk-s3"
version = "1.1.0"
```
```
[package]
name = "aws-smithy-types"
version = "1.0.0"
```
```
[package]
name = "aws-smithy-http"
version = "0.57.0"
```
```
[package]
name = "aws-types"
version = "1.0.0"
```
```
[package]
name = "aws-config"
version = "1.0.0"
```
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
* Move `acquire-build-image` into `.github`
* Move the `tools-hash` script into `.github`
* Upload to ECR from PRs as well
* Move build tools into `tools/ci-build/`
* Move CI scripts out of `ci-build`
* Split CI for forks/non-forks
* Remove `fetch-depth: 0` from PR workflows
* Add Endpoint Resolver Implementation
This commit adds `EndpointDecorator`, standard libary + tests that can be used to add endpoints 2.0 to the AWS SDK.
It _does not_ actually wire these things up. We'll follow up with a PR that actually integrates everything.
* CR Feedback
* CR feedback II
* Update `hydrate-readmes` to take versions from `versions.toml`
* Add cleanup TODO comments to `changelogger`
* Update SDK readme template
* Split up `generate-version-manifest` subcommand
* Eliminate the `aws.sdk.version` property
* Fallback to model hash comparison if model metadata claims no changes
* Add `acquire-base-image` to `release.yml`
* Use empty model metadata for SDK generation in CI
* Fix the `aws-config` version number in SDK crate readmes
This commit splits each of:
* `CodegenContext`,
* `RustSettings`; and
* `CodegenConfig`
into two variants: one for the `rust-codegen` client plugin and another
for the `rust-server-codegen` plugin.
(`CodegenConfig` is a property of `RustSettings`, which is a property of
`CodegenContext`; they constitute pervasive read-only global data that
gets passed around to the code generators).
This allows each plugin to evolve separately, defining different
settings and passing around a tailor-made code-generation context.
Client-specific generators should now use:
* `ClientCodegenContext`,
* `ClientRustSettings`; and
* `ClientCodegenConfig`.
Likewise, server-specific generators should now use:
* `ServerCodegenContext`,
* `ServerRustSettings`; and
* `ServerCodegenConfig`.
This is a more robust and maintainable approach than the current one,
where both generator types have to read possibly null values (because
they don't make sense for a client/server target), and plugins have to
populate settings that are not relevant for the crate they're
generating. For example, the server plugin has to populate and pass
around the settings `renameExceptions`, `includeFluentClient` and
`addMessageToErrors` even though it never uses them and don't make sense
for it.
As of writing these client and server specific classes are very similar,
but in the future they will evolve in separate ways (for example, #1342
will add symbol providers for constrained shapes that only make sense in
a server code-generation context).
Common properties have not been duplicated however. Instead, utilizing
inheritance, code-generation context that is common to _all_ plugins can
be placed in:
* `CoreCodegenContext`,
* `CoreRustSettings`; and
* `CoreCodegenConfig`.
This way, generators that are shared by both client and server can take
in `CoreCodegenContext`. If they need to tweak the code they generate in
small and self-contained places, they can utilize the `CodegenTarget`
flag-like enum to disambiguate, like they have always been doing.
Note this change also makes `RustDecorator`s be targeted for clients or
servers, by making them generic over the code-generation context. When
loading the decorators from the classpath and combining them into one in
the executed smithy-rs plugin, all of them need to either target clients
or target servers. This makes sense: after all, all of the decorators
that conform the AWS Rust SDK are client-specific.
Closes#828.
Establishes a Docker build image with build tools precompiled into it to improve CI time and reduce GitHub Actions workflow configuration. Also makes it possible to run the exact CI workflows in local development.
* Move the publisher tool from `aws-sdk-rust`
* Add `rust-runtime:assemble` target to generate a publishable bundle
* Run `fix-manifests` on assemble output
* Produce publish-ready Smithy runtime bundle during CI
* Allow publish from any arbitrary directory
* Add safe-guard to prevent accidental publish from local dev
* Fix unit test target
* Incorporate feedback
* Add `buildSrc` tests and publisher tool to CI
John DiSanti