## 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 -->
Our WASI canary was breaking with the newest Rust version due to the new
WASI build targets:
https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html
## Description
<!--- Describe your changes in detail -->
Updating the version of `cargo-component` used to build our WASI canary.
Made the same update in the `aws-sdk-rust` repo:
https://github.com/awslabs/aws-sdk-rust/pull/1168
## 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 same change was made in the canary workflow in the `aws-sdk-rust`
repo and run successfully there:
* PR: https://github.com/awslabs/aws-sdk-rust/pull/1168
* Canary run:
https://github.com/awslabs/aws-sdk-rust/actions/runs/9575014647
## 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
Update lockfiles based on [the codegen
release](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-06-18)
(a release including code changes in aws runtime crates, smithy runtime
crates, or codegen code).
## Testing
- [ ] Existing tests 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._
## 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 -->
Our endpoint partition parsing was dropping the `implicitGlobalRegion`
value
## Description
<!--- Describe your changes in detail -->
Updated our Partition structs to include that value and update the
parser to include it.
## 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. -->
Added check for `implicitGlobalRegion` to existing partition unit tests
## 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._
This fixes two bugs:
1. `Content-Type` header checking was succeeding when no `Content-Type`
header was present but one was expected.
2. When a shape was `@httpPayload`-bound, `Content-Type` header checking
occurred even when no payload was being sent. In this case it is not
necessary to check the header, since there is no content.
Code has been refactored and cleaned up. The crux of the logic is now
easier to understand, and contained in `content_type_header_classifier`.
## 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._
## Motivation and Context
https://github.com/awslabs/aws-sdk-rust/issues/1163
## Description
When the S3 SDK processes a response with the 200 status code but with
`InternalError`, the SDK today does not trigger a retry through any
classifier in the chain: `AwsErrorCodeClassifier`,
`ModeledAsRetryableClassifier`, `HttpStatusCodeClassifier`, and
`TransientErrorClassifier`. To address it, this PR updates
`AwsErrorCodeClassifier` only for S3 so that it classifies
`InternalError` as retryable.
## Testing
- [x] CI
- [x] Added traced test to the existing test file `status-200-errors.rs`
## Checklist
- [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._
## 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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
We have had numerous recent issues where updated dependencies have
broken our build/release process. This seeks to fix that in a brute
force way by manually generating Cargo.lock files for our main
workspaces.
## Description
<!--- Describe your changes in detail -->
Introduce a new gradle task `generateAllLockfiles` (and some child tasks
that it invokes) that generates lock files for
* `aws-config` crate
* `aws/rust-runtime` workspace
* `rust-runtime` workspace
* the superset workspace generated by the `assemble` task
* NOTE: This Cargo.lock is actually generated from the workspace in the
`aws-sdk-rust` repo, saved in this repo, and copied into place at build
time. Generating this one requires a local copy of the `aws-sdk-rust`
repo whose absolute path is indicated by the `-Paws-sdk-rust-path`
parameter.
## 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. -->
I ran our E2E tests against 3 commits to confirm that the Cargo.lock
files operate as we expect:
* `9d84980ee2e37deadb7e45450d65c5e6bc69e07c` The head commit from this
PR which has our Cargo.lock files
* ✅ Passes
* `d9d9fcec2de0e898bcc804ee0bb31393d7098e72` with lockfiles and with the
`httparse` and `crc323c` crates unpinned
* ✅ Passes
* `df75beb160890b2a9c382c8a2f7da8d7d0ddd3c8` with no lockfiles and has
the `httparse` and `crc32c` crates unpinned
* ❌ Fails (as expected)
This series of tests confirms that that Cargo.lock files will protect us
against bad dependency updates going forward.
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
----
_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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
aws-sdk-rust#1166
## Description
<!--- Describe your changes in detail -->
SSP shouldn't be enabled for long-running operations that transfer no
data.
## 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. -->
Checked the generated lambda SDK to see that SSP has been disabled for
the operations specified.
## 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
aws-sdk-rust#1162
## Testing
Tests in CI
## Checklist
- [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
There are extra service specific model tests in various
`aws/sdk/aws-models/[sdk-id]-tests.smithy` files. These are currently
manually duplicated to `aws-sdk-rust/aws-models`. This PR seeks to make
`smithy-rs` the single source of truth for these tests and remove the
need to copy them into `aws-sdk-rust` at all.
## Description
* move all `-tests.smithy` into a new sibling directory
`aws-models-extra` and _ALWAYS_ include these regardless of what the
path to `aws-models` is (e.g. even when overriding it and generating the
full SDK by setting `-Paws.sdk.models.path`
* move all `-tests.smithy` from `aws-sdk-rust/aws-models` into this
directory (previously only `s3`, `route53`, and `glacier` were in this
repo but there are also additional tests for `ebs`, `batch`, and `sqs`.
This makes `smithy-rs` the only source of truth for additional AWS SDK
model tests
* see https://github.com/awslabs/aws-sdk-rust/pull/1161
* update the `s3` model to latest and revert
ttps://github.com/smithy-lang/smithy-rs/pull/3641
## Testing
Local + 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
https://github.com/smithy-lang/smithy-rs/issues/3672
## Description
Pin to a newer working version of `crc32c` (will still pin to a
particular version to avoid a breaking change, until the lockfile
protection is available)
## Testing
- Verified locally build of `aws-smithy-checksums` with the updated
`crc32c`
----
_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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
part of the `hyper` 1.0 upgrade
## Description
<!--- Describe your changes in detail -->
This PR adds information about the connector used to send a request to
the metadata included in the user agent.
## 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. -->
I added an integration test.
## 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._
This commit gets rid of some Clippy and Rust doc warnings we produce in
generated code, which are surfaced in our codegen integration tests. The
aim is that eventually we will be able to deny Clippy and Rust doc
warnings in #3678 (despite us baking in `RUSTDOCFLAGS="-D warnings"` and
`RUSTFLAGS="-D warnings"` in our CI Docker image, we curently clear
these in codegen integration tests). Note that denying compiler warnings
is separately tracked in #3194.
The commit contains fixes for the following:
- Unconditionally referring to the `crate::types` module in Rust docs
when
the Smithy model is such that it is not generated.
- Broken intra-crate doc links for client documentation.
- Incorrectly escaping Rust reserved keywords when referring to
operation names in Rust docs.
- An unnecessary semi-colon when rendering additional client
plugins.
- Not escaping brackets in text when rendering Rust docs containing
HTML, that are interpreted as broken links.
- A broken link to unit variants of unions.
- Using `TryFrom` instead of `From` when infallibly converting from
`&str` to `String` when deserializing an `@httpPayload` in the server.
- Using a redundant closure with `unwrap_or_else` when falling back to a
`@default` boolean or number value for a `document` shape, instead of
`unwrap_or`.
- Not opting into `clippy::enum_variant_names` when rendering the
`Operation` enum in the server (since we render the operation names
that were modeled as-is).
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The Server README had a stale warning:
```
** This is a work in progress and generates serialization/de-serialization code that is probably unusable for the time being. ```
---------
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
## Motivation and Context
To fix current CI and release pipeline failures coming from
`aws-smithy-runtime` and `aws-sigv4` now depending on `httparse` version
1.9.0 or greater.
## Testing
Tests 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._
## 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 -->
The paginator for the S3 `ListParts` operation could loop forever:
https://github.com/awslabs/aws-sdk-rust/issues/1143. This is because
most paginated operations use an empty next token as an indication that
pagination is exhausted. `ListParts` instead sets the final next token
as `0` causing the pagination to loop back to the first page and loop
forever. Instead of an empty next token `ListParts` uses `IsTruncated =
false` to indicate that pagination has been exhausted.
## Description
<!--- Describe your changes in detail -->
* Added a new trait `isTruncatedPaginatorTrait`
* Add that trait to the S3 `ListPartsOutput` shape
* Use the presence of that trait to vary the logic setting the
`is_empty` value in the paginator.
* If the trait is absent it looks for an empty next token as always
* if the trait is present the value is set based on the value of the
response's `is_truncated` field
## 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. -->
* Added integration test confirming that pagination terminates when a
response contains `is_truncated = false`
**Note:** I'm still working on turning this into a model test rather
than an S3 specific integration test, but I wanted to get some feedback
on the actual fix while I'm figuring that out)
## 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
Reverts e4260f5ab6
## Description
We recently had a CI failure where some of the SDK codegen integration
tests encountered a cargo dependency graph resolution error
([example](https://github.com/smithy-lang/smithy-rs/actions/runs/9351952926/job/25740638098?pr=3677#step:3:639)).
The way the issue manifested is as follows:
1. A preceding test `SdkCodegenIntegrationTest.smokeTestSdkCodegen`
generated a `Cargo.lock` at the top-level directory of a shared test
workspace whose `tokio` dependency did NOT include the `macros` feature:
```
[[package]]
name = "tokio"
version = "1.38.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ba4f4a02a7a80d6f274636f0aa95c7e383b912d41fe721a31f29e29698585a4a"
dependencies = [
"backtrace",
"bytes",
"libc",
"mio",
"pin-project-lite",
"socket2",
"windows-sys 0.48.0",
]
```
2. During its turn, `CredentialProviderConfigTest`, which is one of the
failed tests and depends on the `macros` feature of `tokio`, generated
its own test crate and made it as a member of the workspace, for
instance:
```
[workspace]
resolver = "2"
members = ["smithy-test1475522104838765591"]
```
3. Docker containers used by GitHub action have the `CARGO_HOME` set to
`/opt/cargo` where it stores crates io index, cached crates, and so on.
The registry cache did not contain the sought crate `tokio-macros-2.3.0`
at the end of previous step:
```
bash-5.2# ls /opt/cargo/registry/cache/index.crates.io-6f17d22bba15001f/tokio-
tokio-1.37.0.crate tokio-macros-2.2.0.crate tokio-rustls-0.24.1.crate tokio-util-0.7.11.crate
tokio-1.38.0.crate tokio-native-tls-0.3.1.crate tokio-util-0.7.10.crate
```
(`bash-5.2#` indicates that we shelled into a container)
4. Running `cargo test` from the workspace root (or from within the
crate generated at step 2) then triggered the error in question:
```
bash-5.2# cargo t --all-features
error: failed to select a version for the requirement `tokio-macros = "~2.3.0"`
candidate versions found which didn't match: 2.2.0, 2.1.0, 2.0.0, ...
location searched: crates.io index
required by package `tokio v1.38.0`
```
Whether the issue occurs or not for a given test depends upon the
contents of the lockfile of a workspace generated by prior tests. To
ensure we avoid this during codegen integration tests, this PR updates
crates io index before executing `cargo test`.
## Testing
- [x] Passed CI
- [x] Passed internal release pipeline E2E tests
----
_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
<!--- Why is this change required? What problem does it solve? -->
Making this conversion bidirectional is helpful.
<!--- If it fixes an open issue, please link to the issue here -->
## Description
<!--- Describe your changes in detail -->
Add `impl From<StatusCode> for httpN::StatusCode` that does the obvious
thing.
## 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. -->
I'm using these conversions in my own project. As all three crates have
identical constraints on the status code value the changes are trivially
correct.
## 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
Not clear to me what if anything to do here.
----
_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
There are several service specific http request/response tests from
Smithy. These are similar to the protocol tests but apply only to a
specific service. We were tasked with ensuring some of the S3 URI
related tests were captured.
## Description
We currently were running the API gateway related tests as part of the
`aws/sdk-adhoc-test` package. There are also tests for
[machinelearning](https://github.com/smithy-lang/smithy/blob/main/smithy-aws-protocol-tests/model/awsJson1_1/services/machinelearning.smithy),
[glacier](https://github.com/smithy-lang/smithy/blob/main/smithy-aws-protocol-tests/model/restJson1/services/glacier.smithy),
and
[s3](https://github.com/smithy-lang/smithy/blob/main/smithy-aws-protocol-tests/model/restXml/services/s3.smithy).
I attempted to add all of these but hit issues.
1. `machinelearning` can be enabled but we have yet to actual implement
the [customization](https://github.com/smithy-lang/smithy-rs/issues/139)
that would allow this test to pass.
2. `s3` pulls in `aws-config` as a dev dependency for _reasons_ and this
causes conflicts between relocated and non-relocated runtime crates. The
`sdk-adhoc-test` package does not implement any of the runtime
relocation and Cargo.toml processing that the `sdk` build does (nor do I
want to pursue that).
For now I've enabled the `glacier` tests and copied the S3 specific
tests into `s3-tests.smithy` so that they are built and tested with the
actual S3 model. In the future we can either (1) fix the build issues
allowing us to remove these tests in favor of the ones defined in Smithy
or (2) ideally these tests get implemented in the real upstream service
models and we don't have to do anything special to get them.
## Testing
Tested locally and 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
Rustc 1.74.0 removed the private-in-public check, which raises a
compile-time error if a member of a struct has a type which is less
visible than the parent struct. Fixing this private-in-public issue
enables aws-smithy-runtime to build in projects using rustc older than
1.74.0.
## Description
Make UploadThroughputCheckFuture pub(crate) because it is needed in
MaybeUploadThroughputCheckFuture which is pub(crate).
## Testing
Verified that crate now compiles using rustc 1.72.1.
## 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: ysaito1001 <awsaito@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 -->
#1925
## Description
<!--- Describe your changes in detail -->
Implements the v1 `http_body::Body` trait for `PathBody`. Part of the
ongoing hyper v1 upgrade.
This also moves a pre-1.0 impl into its own module.
## 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. -->
I ported the tests too
## 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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
https://github.com/smithy-lang/smithy-rs/issues/3676
## Description
Internals one of our tests was leveraging has changed in latest release
of `tracing-test`, updates version and test to be compatible.
----
_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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
Our logs had several entries that were extremely verbose and made them
harder to sort through. This change aims to reduce the verbosity of
those logs to something more manageable.
## Description
<!--- Describe your changes in detail -->
- Removed the logging of the full IMDS Client struct, replaced with a
message that it was truncated
- Removed logging the full `Configbag` in a couple places in
`RuntimeComponentsBuilder`
- Removed logging of full `ProvideCredentials` objects in the
CredentialsProviderChain` and replaced with just their names
There are some verbose logs I did not remove because I was not sure of
their usefulness. Most notably the `PartitionResolver` struct logs
several hundred lines of region information each time it appears. Happy
to truncate that as well if those logs aren't too helpful.
## 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 was tested locally by running the SDK [logging
example](https://docs.aws.amazon.com/sdk-for-rust/latest/dg/logging.html)
code with `RUST_LOG=trace` prepended to the `cargo run` command. For
comparison, when saved as a .txt file, the old logs take up `2.8MB` and
the new logs take `273KB` for the same operation.
## 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._
## Motivation and Context
The `invoke` debug span now includes invocation IDs for operation
invocations. It is a random unique ID per client and shared across
retries for the same operation.
Example debug trace output with the changes in this PR:
```
2024-05-29T17:50:22.230526Z DEBUG invoke{service=s3 operation=ListObjectsV2 sdk_invocation_id=4652364}:try_op:try_attempt: aws_smithy_runtime_api::client::interceptors::context: entering 'before deserialization' phase
```
## Description
Note that this invocation ID is currently for internal use only to
improve debuggability when looking at logs (usually with customers).
Note also that the invocation ID is not related to [that used in
amz-sdk-invocation-id](https://github.com/smithy-lang/smithy-rs/pull/2626)
(we [attempted to make it
related](https://github.com/smithy-lang/smithy-rs/pull/3661) but decided
to go for this two-way door approach).
In sum, this PR is meant to be simple, and if we are to augment the
functionality (e.g. make the ID configurable or make it related to that
in `amz-sdk-invocation-id`), we can do so without breaking anything.
## Testing
Relies on the existing tests 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._
## Motivation and Context
In a Docker container we use in our release pipeline, we've got the
following error in `runtime-versioner` unit tests
```
Running tests/test_audit.rs (src/smithy-rs/tools/target/debug/deps/test_audit-9e2b5cd76b506229)
running 6 tests
Cloning into 'test_base'...
Cloning into 'test_base'...
Cloning into 'test_base'...
Cloning into 'test_base'...
Cloning into 'test_base'...
Cloning into 'test_base'...
fatal: detected dubious ownership in repository at '/tmp/.tmpjwZMOW/test_base.git'
To add an exception for this directory, call:
git config --global --add safe.directory /tmp/.tmpjwZMOW/test_base.git
fatal: detected dubious ownership in repository at '/tmp/.tmp9Aw4By/test_base.git'
```
`runtime-versioner` unit tests [unpacks a tar file for a fake git
repo](cd0f0bac51/tools/ci-build/runtime-versioner/test-common/src/lib.rs (L31-L39)),
but for some reason, the resulting file had a strange owner:group
assigned to it
```
drwxr-xr-x 6 504 games 4096 Dec 20 00:46 test_base.git
```
The tests have been passing but they started breaking yesterday for some
reason. To side step this issue, this PR will ensure the resulting file
has the correct current user.
## Testing
Verified running unit tests in a container with the fix and confirmed it
passed.
----
_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
Works around https://github.com/zowens/crc32c/issues/67
----
_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
Upgrades Smithy to 1.49.0
## Description
As part of the upgrade, it updates the serializer for EC2 query protocol
to handle empty lists in response to
[this](https://github.com/smithy-lang/smithy/pull/2269) (otherwise [a
protocol
test](https://github.com/smithy-lang/smithy-rs/blob/main/codegen-client-test/build.gradle.kts#L75)
`ec2_empty_query_lists_request` would fail).
## Testing
Existing tests 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._
Similar to https://github.com/smithy-lang/smithy-rs/pull/3597.
Only run these two workflows when they are triggered from the
`smithy-lang/smithy-rs` repository, not from any fork.
## 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 -->
The scheduled dry run fails daily in forks, failing each time,
triggering alerts to the owner of the fork repository.
The github pages publishing workflow does not run regularly in forks,
but does run when a fork is synced. It would be undesirable for an
arbitrary fork to publish.
## Description
<!--- Describe your changes in detail -->
On each of the two github workflows, add an `if` condition testing the
repository owner and name. Only run if it matches the official
repository, and is not a fork.
## 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. -->
n/a
## 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
n/a in both cases
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Signed-off-by: Joshua Potts <8704475+iamjpotts@users.noreply.github.com>
_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: Zelda Hessler <zhessler@amazon.com>
Co-authored-by: ysaito1001 <awsaito@amazon.com>
AWS SDK Rust Bot