The sparse index is preferred to the crates.io API for the checks we
need, according to the [documentation](https://crates.io/data-access).
When the tools were first implemented, the sparse index didn't exist, so
the API was used.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This fixes the claim crate names GitHub Actions workflow that runs on
changes to main.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Currently only a single author can be provided to a changelog entry.
This does not support the cases where a single PR was coauthored by
multiple authors and/or multiple PRs were authored by different
individuals.
## Description
- Accept a list of strings, in addition to a single string in the
`author` field. Each author in the list is added as a contributor to
every PR provided in references.
- Accept references of the form `{ "id": <ID>, "authors": <Author> }`,
in addition to `ID`. Each author given in `authors` is added as a
contributor to that PR. Authors common to all references will be
serialized in the same way as using the top-level `author` field.
## Notes
- This should not be a breaking change. Existing `CHANGELOG.next.toml`
should be deserialized and then serialized identically.
---------
Co-authored-by: Harry Barber <hlbarber@amazon.co.uk>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
This change adds a new crate, `aws-smithy-wasm`, that exports a SDK
compatible WASI http client. This is a continuation of the work in #2520
using the now stabilized WASI 0.2.0 interfaces from the [wasi
crate](https://crates.io/crates/wasi). This supports, but does not
finalize the work for #2087
## Description
<!--- Describe your changes in detail -->
Add a new crate, `aws-smithy-wasm` which exports a function
`wasi_http_client` that will provide the user with a WASI compatible
http client. This client is implemented by using the
`wasi::http::outgoing_handler`
[ref](https://docs.rs/wasi/0.12.0+wasi-0.2.0/wasi/http/outgoing_handler/index.html)
along with some utility implementations of `TryFrom` to transform back
and worth between the types from the `http` crate and the `wasi::http`
types. It also exports a unit struct `WasmSleep` that impls the
`AsyncSleep` trait needed by the SDK.
## Testing
<!--- Please describe in detail how you tested your changes -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
This is tested via an integration test in
`aws/sdk/integration-tests/webassembly` that uses the wasi http-client
to vuild a config and an operation (that is not sent). It is further
tested in a new canary (`wasm_canary`) that calls the S3
`list_objects_v2` API.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [X] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or 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._
---------
Co-authored-by: Eduardo Rodrigues <eduardomourar@users.noreply.github.com>
Co-authored-by: Eduardo de Moura Rodrigues <16357187+eduardomourar@users.noreply.github.com>
Co-authored-by: ysaito1001 <awsaito@amazon.com>
Co-authored-by: John DiSanti <jdisanti@amazon.com>
Co-authored-by: Russell Cohen <rcoh@amazon.com>
Co-authored-by: John DiSanti <john@vinylsquid.com>
## Motivation and Context
Update MSRV to 1.74
## Description
Normal slate of things, mostly appeasing clippy.
----
_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>
## Motivation and Context
The nested path dependencies in our generated runtime crates cause
issues when simulating a release. This strips those out in order to
support testing a release where some versions _don't_ change.
## Testing
https://github.com/smithy-lang/smithy-rs/actions/runs/7917462892
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Remove warning banner related code. The test is broken so this code is
just causing a hassle and will never be used again.
- [ ] A generated code diff should be audited prior to merging.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Testing
- deployed to my personal account
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This CI step will check for subtle semver hazards with the `ConfigBag`
during release. Once all the runtime crates are independent, then this
check can be moved into normal CI.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
- aws-sdk-rust#977
- smithy-rs#3365
## Description
Add `try_from` and `try_into` for HTTP 1.x to the HTTP request/response
wrapper. This is a stepping stone en route to supporting Hyper 1.0
## Testing
- [x] New unit tests
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] 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._
---------
Co-authored-by: John DiSanti <jdisanti@amazon.com>
A tool to patch in new versions of smithy-rs runtime crates was
introduced in #3327 so that semver breaks could better be detected for
upcoming releases. However, this tool didn't support patching in SDK
runtime crates, which is necessary for testing #3355.
This PR moves the tool into the runtime-versioner tool, and adjusts it
to support both smithy-rs and 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._
The runtime-versioner's audit subcommand fails when the current commit
is the tagged release commit due to a bug in `ancestor_tag` where it was
failing to trim the output from `git describe --tags`. I fixed this
earlier in #3369 since I was running into it there, but that hasn't been
reviewed/merged yet. This issue is causing problems for the latest
smithy-rs/SDK release, so I've pulled it out into a separate PR.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This PR implements a build tool to audit runtime crate versions as part
of CI and release. If a runtime crate doesn't have the special
`0.0.0-smithy-rs-head` version number, then it is assumed to be
independently versioned, and the audit tool will verify it is version
bumped when any changes are made to it.
Given that there isn't a complete/reliable semver checking tool for Rust
yet, this tool isn't smart. It will rely on devs to correctly bump the
version number when that is done.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
update version of cargo_toml used by sdk-lints
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Publishing is disabled for this package currently.
## Motivation and Context
Testing is a huge pain. Currently. This method isn't ideal and can lack
accuracy in some cases but in quick and useful for many applications.
## Description
New mock package that allows code like this:
```rust
let s3_404 = mock!(Client::get_object)
.match_requests(|inp| {
inp.bucket() == Some("test-bucket") && inp.key() != Some("correct-key")
})
.then_http_response(|| {
http::Response::builder()
.status(400)
.body(SdkBody::from(S3_NO_SUCH_KEY))
.unwrap()
.try_into()
.unwrap()
});
let s3_real_object = mock!(Client::get_object)
.match_requests(|inp| {
inp.bucket() == Some("test-bucket") && inp.key() == Some("correct-key")
})
.then_output(|| {
GetObjectOutput::builder()
.body(ByteStream::from_static(b"test-test-test"))
.build()
});
let get_object_mocks = MockResponseInterceptor::new()
.with_rule(&s3_404)
.with_rule(&s3_real_object);
let s3 = aws_sdk_s3::Client::from_conf(
Config::builder()
.with_test_defaults()
.region(Region::new("us-east-1"))
.interceptor(get_object_mocks)
.build(),
);
```
There is no binary level mocking and this is completely typesafe. IDE
inference works properly as well. The crimes that were committed were
small and self-contained.
## Testing
There is a unit test and it works.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] 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._
## Motivation and Context
Fix missed change to update changelog tool
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
The TLS test broke. Why? Because Bad SSL stopped working.
Why did BadSSL stop working? Because it used an ancient version of ruby
and it couldn't install packages anymore.
So I:
- Got it working on a newer version of ruby
- But that only work on Ubuntu 22.04.
- The version of nginx/openssl that you can install on 22.04 version
actually serve these terrible certificates.
So instead, we compile nginx and openssl from source.
I also fixed things up so they won't fail silently in the future.
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
## Description
Mostly just sadness.
## Testing
The check passes again.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] 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._
## Motivation and Context
- https://github.com/aws/aws-sdk/issues/574
- https://github.com/awslabs/aws-sdk-rust/issues/1020
## Description
To match the CLI behavior and improve customer experience, make the keys
on the profile file case-insensitive.
## Testing
- New credentials integration test
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] 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._
## Motivation and Context
Extracted from #3308, this adds doc example scraping. This won't make
much of a difference yet but it will help if we're able to move example
repos directly under the SDKs themselves when appropriate.
## Description
https://doc.rust-lang.org/rustdoc/scraped-examples.html
## Testing
verified that examples appear in docs when expected
## Checklist
no changelog
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
As we discovered in #3318, it's possible to cause unexpected breakage by
releasing runtime crates.
This tool automates setting up `aws-sdk-rust` (and manually, you can
copy the patches into `~/.cargo/config.toml` for your entire system), to
simulate the release of new runtime crates.
<img width="1518" alt="Screenshot 2023-12-15 at 12 58 41 PM"
src="https://github.com/smithy-lang/smithy-rs/assets/492903/59d6cb5c-d39c-4e42-98e2-6858d0884449">
### Testing
With this tool (and a small hack—I had to simulate releasing 1.1.100 so
that the versions became the latest), I correctly caught the breaking
changes from the previous release.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
`P109001503`
## Description
When `publisher` yanks crates, it blasts `crates.io` in parallel with
all the yank requests, and then awaits their results.
To avoid throttling errors, this PR instead yanks one crate at a time,
with a configurable time delay in between via a `--delay-millis` command
line argument. Further, a call to yank is now wrapped with
`run_with_retry` to detect throttle errors, wait a long period of time
after, and try again.
Essentially, the structure of the `yank` module is now similar to that
of the `publish` module such as use of `run_with_retry` and the presence
of a CLI argument `delay-millis`.
## Testing
On top of changes in the PR, manually modified the following for loop in
`yank_release.rs` locally
```
for (crate_name, crate_version) in crates {
```
to
```
for (crate_name, crate_version) in [("aws-sigv4", "0.55.0"); 50] { // aws-sigv4@0.55.0 has already been yanked in the past so it's safe to yank repeatedly
```
and observed the behavior of `publisher yank-release --delay-millis
2000` that it
- waits 2 seconds beteen yanks
- yanks in a serial manner
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
_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>
## Motivation and Context
Enables `cargo semver-checks` in CI for PRs created by external
contributors
## Description
For instance, we skipped a run of `cargo semver-checks` in
https://github.com/smithy-lang/smithy-rs/pull/3286 and failed to detect
[a breaking
change](https://github.com/smithy-lang/smithy-rs/pull/3286#discussion_r1416479632)
programmatically.
With this PR, the workflow will run a job `semver-checks` even if the
preceding jobs `save-docker-login-token` or `acquire-base-image` are
skipped. Those jobs are relevant when the PR made changes to build
tools, which is less likely for PRs created by external contributors, so
it's reasonable to skip them and still run the `semver-checks` job.
Furthermore, this PR enables `semver-checks` to run against all crates
in `tmp-codegen-diff/aws-sdk/sdk/`, not just those limited by
`list(os.listdir())[:10]`.
## Testing
Tested the change against [a dummy
PR](https://github.com/smithy-lang/smithy-rs/pull/3288) I created from
my fork of `smithy-rs`. Specifically, `semver-checks` [caught the
aforementioned breaking
change](https://github.com/smithy-lang/smithy-rs/actions/runs/7121830175/job/19391798131#step:4:681)
in CI.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This change reduces the time delay between crate publishes from 5
seconds down to 1, and makes it configurable in case this leads to
release issues.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The SDK canary was failing due to the `.N` suffix on release tags (see
https://github.com/awslabs/aws-sdk-rust/issues/993). This change
upgrades the canary to the 1.x SDK and also fixes the bundle naming
issue by removing periods.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
This PR is a cleanup after
https://github.com/smithy-lang/smithy-rs/pull/3115, fully switching to
`rustv1` for the rust example directory in
[aws-doc-sdk-examples](https://github.com/awsdocs/aws-doc-sdk-examples).
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
This reduces checking aws-config to 6 minutes, down from 28
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Fixes https://github.com/smithy-lang/smithy-rs/issues/3265
## Description
To check semver, `semver checks` needs to compile two versions of a
crate, i.e. baseline and current. Our CI failed to compile `aws-config`
for a baseline version.
The following diagram shows what was missing to cause compilation
failure:
```
┌───────────┐
│ smithy-rs │
└─────┬─────┘
│
│
│ ┌────────┐
└─────┤ target │
└───┬────┘
│ ┌───────────────┐
└────────┤ semver_checks │
└───────┬───────┘
│
│
│ ┌──────────┐
└───────┤ git-base │
└────┬─────┘
│
│ ┌──────────────┐
├────────┤ <rev number> │
│ └──────┬───────┘
│ │
│ │
│ │ ┌───────┐
│ ├───────┤ aws │
│ │ └───┬───┘
│ │ │
│ │ │ ┌──────────────┐
│ │ ├───────┤ rust-runtime │
│ │ │ └──────┬───────┘
│ │ │ │
│ │ │ │ ┌────────────┐
│ │ │ └───────┤ aws-config │ ◄***************
│ │ │ └────────────┘ *
│ │ │ * *
│ │ │ * *
│ │ │ *****depends*on**** *
│ │ │ ▼ *
│ │ │ *
│ │ │ ┌─────┐ *
│ │ └───────┤ sdk │ (with no "build" directory) *
│ │ └─────┘ *
│ │ *
│ │ *
│ │ ┌────────────────────┐ depends on
│ └──────┤ tmp-codegen-diff │ *
│ └─────────┬──────────┘ *
│ │ *
│ │ ┌─────────┐ *
│ └───────┤ aws-sdk │ *
│ └────┬────┘ *
│ │ ┌─────┐ *
│ └─────┤ sdk │ *
│ └─────┘ *
│ *
│ *
│ ┌───────────────────────────────────────┐ *
└───────────┤ local-aws_config-0_0_0_smithy_rs_head │*****************************
└───────────────────────────────────────┘
```
`local-aws_config-0_0_0_smithy_rs_head` under the `git-base` directory
is a special crate created by `semver-checks` for a baseline version of
`aws-config` and its `Cargo.toml` depends on
`target/semver_checks/git-base/<rev
number>/aws/rust-runtime/aws-config`. However, that `aws-config` in turn
depends upon crates in `target/semver_checks/git-base/<rev
number>/aws/sdk/build/` (as shown
[here](https://github.com/smithy-lang/smithy-rs/blob/main/aws/rust-runtime/aws-config/Cargo.toml#L23-L33)),
which does not exist in a baseline branch.
When `semver-checks.py` [creates a baseline
branch](3d0cb5c3b1/tools/ci-scripts/codegen-diff/semver-checks.py (L31))
to prepare for running `cargo semver-checks`, it [moves aws/sdk/build to
tmp-codegen-diff](3d0cb5c3b1/tools/ci-scripts/codegen-diff/diff_lib.py (L59)),
leaving nothing behind in `aws/sdk/build/`. The fix, therefore, is to
`cp -r aws/sdk/build/aws-sdk` instead of `mv aws/sdk/build/aws-sdk` when
preparing a baseline branch.
The issue is specific to `aws-config`, probably because that's the only
runtime crate that depends on those in `aws/sdk/build`.
## Testing
Verified a clean run for `cargo semver-checks` in [an investigation
branch](https://github.com/smithy-lang/smithy-rs/actions/runs/7035082815/job/19144676499#step:4:1101).
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Skip running `semver-checks` on `aws-config` to enable clean runs for CI
while #3265 is investigated.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This will fix the yank tool and canary in the event there are multiple
SDK releases in a day.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Now that we have started [stable
releases](https://github.com/smithy-lang/smithy-rs/releases) since
`release-2023-11-21`, we shouldn't set those as pre-releases.
(this PR also includes a small fix to the `Release` job in our release
workflow to avoid `git push` failing during dry-runs, which [a previous
dry-run](https://github.com/smithy-lang/smithy-rs/actions/runs/6989359794)
ran into)
## Description
The fix is in `changelogger`, and this should remove pre-releases from
releases in `smithy-rs` as well as those in `aws-sdk-rust`.
## Testing
Ran a
[dry-run](https://github.com/smithy-lang/smithy-rs/actions/runs/7007835035)
and checked the release artifacts as follows:
```
{
"tagName": "release-2023-11-27",
"name": "November 27th, 2023",
"body": "",
"prerelease": false
}
```
Have not verified what a release manifest looks like in `aws-sdk-rust`,
but I suspect `prerelease: false` should be applied there as well given
the same `changelogger` is used.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
This small PR cleans up remaining two `TODO(GA)` in #3082.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Stable crates MUST only expose other stable crates.
## Description
This:
- fixes the remaining issues
- adds a lint tool to be sure we don't expose unstable crates by
accident in the future
## Testing
CI run
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] 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._
## Motivation and Context
Addresses `TODO(GA)` from
https://github.com/smithy-lang/smithy-rs/pull/3082
## Description
This small PR will remove a guard so we can truly specify different
versions for stable crates and unstable crates. Previously, whatever
that's entered in `Stable semantic version` in the release workflow
textbox (see a screenshot in the above PR) is overwritten by what's
entered in `Unstable semantic version`. With this PR, whatever that's
entered in `Stable semantic version` will make its way to
`smithy.rs.runtime.crate.stable.version` in `gradle.properties`.
In addition, with this PR, the name of a release branch is derived from
what we enter in `Stable semantic version` in the release workflow
textbox.
## Testing
~~It has been tested in the above PR.~~
EDIT:
Found a bug I introduced in the above PR where `publisher` was not
reading a metadata `package.metadata.smithy-rs-release-tooling`
correctly in a manifest file. Fixed it in c477d2f, confirmed that a
[dry-run](https://github.com/smithy-lang/smithy-rs/actions/runs/6872502257)
passed, and verified the release artifact contained both stable crate
versions & unstable versions as expected.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This should have been done as part of #2766.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
See [rendered
RFC](df518bfb59/design/src/rfcs/rfc0039_behavior_major_versions.md)
## Description
This add `BehaviorMajorVersions` to the SDK and wires them in up and
down the stack.
## Testing
- [x] lots of ITs / UTs
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] 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._
## Motivation and Context
Running this check on all services significantly slows down CI
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
This PR fixes issues introduced by moving the repository from
awslabs/smithy-rs to smithy-lang/smithy-rs.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## 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>
The examples currently reside in aws-doc-sdk-examples/rust_dev_preview,
but this name will need to change when the SDK goes GA. This PR modifies
the SDK generator to look for `rust/` before `rust_dev_preview/`.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Implements #3100
## Description
Currently, we expose `aws_smithy_http::event_stream::Receiver` in
generated SDKs, as shown in the following S3's example (see[ a generated
diff](https://d2luzm2xt3nokh.cloudfront.net/codegen-diff/cc303ab1a07693ab02d5ec4f06101b628d1dbabe/1aa6a8da7d2b7669ba3ab7179a1fd72aadc03162/aws-sdk-ignore-whitespace/index.html)
for
`tmp-codegen-diff/aws-sdk/sdk/s3/src/operation/select_object_content/_select_object_content_output.rs`):
```
pub struct SelectObjectContentOutput {
<p>The array of results.</p>
pub payload: ::aws_smithy_http::event_stream::Receiver<
crate::types::SelectObjectContentEventStream,
crate::types::error::SelectObjectContentEventStreamError,
>,
...
```
This PR wraps `Receiver` in a new-type, called `EventReceiver`, which
then supports `pub async fn recv` method whose signature is the same as
`aws_smithy_http::event_stream::Receiver::recv`.
## Testing
Relied on existing tests (e.g. `s3` and `transcribestreaming`
integration tests cover uses cases affected by this change).
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [x] 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._
The OIDC provider no longer needs to specify the thumbprints now; In the
IAM Identity Provider console it says that those are now sourced
automatically.
I also updated the npm commands to build and deploy everything instead
of just the canary and I added a trait import to the previous version
canary in the hope of getting past that warning that only appears in CI.
If that doesn't fix it, then Yuki will when he takes a look next week.
- update canary npm commands
- update canary OIDC provider stack
- add missing trait to previous version canary
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
https://docs.rs/crate/aws-smithy-types/0.57.0/builds/954806
Smithy-types docs failed to build.
1. Update CI to run a command more like docs.rs
2. Use auto_doc instead
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [ ] I have updated `CHANGELOG.next.toml` if I made changes to the
smithy-rs codegen or runtime crates
- [ ] 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._
## Motivation and Context
Canary is failing because the lambda execution role can't access the
bucket.
## Description
- Grant the lambda role access to the bucket
## Testing
- ran policy engine in my account to verify access
- [x] ran canary in my account
---
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Motivation and Context
Now that we have adopted the approach of distinguishing between stable
and unstable runtime crates, the tilde version requirements introduced
earlier is no longer necessary.
## Description
Reverts the following PRs:
https://github.com/awslabs/smithy-rs/pull/3009https://github.com/awslabs/smithy-rs/pull/3025
## Testing
Relied on the existing tests (if we can generate SDKs in CI, we should
be good to go)
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Fixes#3112.
I opted to upgrade to the latest 0.17.5 in spite of the guidance in
[RFC-21](https://github.com/awslabs/smithy-rs/blob/main/design/src/rfcs/rfc0021_dependency_versions.md)
since this is a security critical dependency, and the maintainer has
aggressively yanked old versions in the past.
Note: ring 0.16 is still pulled in by rcgen as a dev dependency in
aws-smithy-http-server-python after these changes. The rcgen crate
hasn't upgraded yet.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
John DiSanti