The GitHub workflow for `exotic platform` downloads the `openssl.sh`
script, which tries to download
`https://www.openssl.org/source/openssl-1.0.2t.tar.gz`, but the file has
been permanently moved. This PR updates the `curl` command to include
the `-L` option.
Co-authored-by: Fahad Zubair <fahadzub@amazon.com>
## Description
This PR updates lockfiles by running:
```
./gradlew aws:sdk:generateAllLockfiles -Paws-sdk-rust-path=/Users/awsaito/src/aws-sdk-rust
```
However, due to [the minicbor
issue](https://github.com/smithy-lang/smithy-rs/pull/3818), we still pin
it to 0.24.2 by running the following on `rust-runtime/Cargo.lock` and
`aws/sdk/Cargo.lock`:
```
RUSTFLAGS="--cfg aws_sdk_unstable" cargo update -p minicbor --precise 0.24.2
```
The rest of the changes handle miscellaneous scenarios:
- **Updated nightly version**: Upgraded to `nightly-2024-03-15` to
address a [compatibility
issue](https://github.com/serde-rs/serde/issues/2770) introduced by the
updated serde library.
- **Cleaned up use statements**: Removed redundant use statements, which
were flagged as warnings by the new nightly version.
## 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._
**Will merge to the release branch**
## Motivation and Context
Fixes a failure observed in our release pipeline
## Description
A lockfile located at `aws/sdk/Cargo.lock` did not include the
`minicbor` crate that was introduced as part of RPC V2 CBOR. This has
caused a build failure in our release pipeline due to a new version of
`minicbor` 0.24.3 uploaded to crates.io.
```
error: unsupported output in build script of `minicbor v0.24.3`: `cargo::rustc-check-cfg=cfg(atomic64, atomic32)`
```
To address this issue, this PR pins `minicbor` to 0.24.2 in
`aws/sdk/Cargo.lock` (`rust-runtime/Cargo.lock` already pins it to
0.24.2)
The change in `aws/sdk/Cargo.lock` was obtained by
1. running `git pull` in `/Users/awsaito/src/aws-sdk-rust`
2. running `./gradlew aws:sdk:generateAllLockfiles
-Paws-sdk-rust-path=/Users/awsaito/src/aws-sdk-rust`
3. retaining the portion only relevant to `minicbor`
In addition, since the release of aws-sdk-rust the other day, smoke
tests have started getting rendered and compiled in cargo-semver-checks.
This has caused cargo-semver-checks to exceed the previous timeout of 20
minutes. To address it, we have increased the timeout to 30 minutes.
## Testing
- [ ] Tests in CI
- [x] End-to-end tests in our release pipeline
----
_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 MSRV to 1.78.0 since the [latest
Rust](https://www.rust-lang.org/) at the time of writing is 1.80.1 (we
try keeping [two releases
behind](https://github.com/awslabs/aws-sdk-rust?tab=readme-ov-file#supported-rust-versions-msrv)).
## Description
In Rust 1.78.0, `clippy` enforces stricter checks in two areas:
- `dead_code`
It seems to be able to uncover more unused code patterns, especially
when different combinations of cargo features are enabled
- `empty_docs`
Prior to 1.78.0, the codegen used to render the following empty docs
`///`, regardless whether the codegen is for the server or for the
client. This is now flagged as `empty_docs` by `clippy`:
```
///
pub(crate) mod XXX {
...
}
```
Other than bumping MSRV to 1.78.0, the remaining code changes address
issues related to the fixes mentioned above.
**EDIT:**
`cargo-semver-checks` required an upgrade due to incompatibility issues
following the MSRV upgrade ([example
error](https://github.com/smithy-lang/smithy-rs/actions/runs/10534205294/job/29261105195#step:4:2068)).
Specifically, after updating the MSRV to 1.78.0, the rustdoc version was
upgraded to v28. However, the version of `cargo-semver-checks` we were
using (0.24.1) only supported rustdoc [up to
v27](4bce03d4a6/Cargo.toml (L18)).
To resolve this, we have updated `cargo-semver-checks` to the first
version that supports rustdoc
[v28](94a491f085/Cargo.toml (L18)).
## Testing
Existing tests in CI
## Checklist
<!--- If a checkbox below is not applicable, then please DELETE it
rather than leaving it unchecked -->
- [x] For changes to the smithy-rs codegen or runtime crates, I have
created a changelog entry Markdown file in the `.changelog` directory,
specifying "client," "server," or both in the `applies_to` key.
- [x] For changes to the AWS SDK, generated SDK code, or SDK runtime
crates, I have created a changelog entry Markdown file in the
`.changelog` directory, specifying "aws-sdk-rust" in the `applies_to`
key.
----
_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
Keeping the history of `github-pages` is not useful, and it hogs the
output of `git log --graph --all` and other such views of the repository
history. In the event that someone would need to look at old contents of
the website, it can be regenerated using `mdbook` from any commit on
`main`.
<img
src="https://github.com/user-attachments/assets/f37630fa-92ef-4e49-a9e5-a1357a785e46"
width="550">
----
_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 [RFC: File-per-change
changelog](https://smithy-lang.github.io/smithy-rs/design/rfcs/rfc0042_file_per_change_changelog.html#rfc-file-per-change-changelog)
## Description
When this PR is merged to `main`, it will impact developer workflow for
creating a changelog entry that goes with a PR.
Prior to this, one edited `CHANGELOG.next.toml` to enter a changelog
entry, but it often caused merge conflicts among us. With this PR, one
creates a `.md` file (any filename stem will do) under the
`smithy-rs/.changelog` directory. This Markdown file has the YAML front
matter, and it can be created manually or via the `ChangeLogger` CLI
(see [this
commit](83cda76608)
for more details).
Here are the highlights of the code changes:
- [The release
script](https://github.com/smithy-lang/smithy-rs/pull/3774/files#diff-162dc2b82eb3d72b105291d2fc5fc8d10c4fbc1e6f35862bc08ac0d6a7c53f76)
has been pointed to `smithy-rs/.changelog`. This is pretty much what it
takes to let the `smithy-rs` release infra switch to the new changelog
mode.
-
[sdk-lints](efcc772b37)
now disallows `CHANGELOG.next.toml`. It will complain if the file is
present.
- The `--source-to-truncate` option for the `changelogger`'s `render` is
now optional because our internal release infra code no longer needs to
specify that option (i.e. there is nothing to truncate there).
- Tests in `smithy-rs-tool-common` and `changelogger` have been updated
so TOML changelog entries used in tests have been re-written to Markdown
changelog entries. We want to avoid giving the false impression that
TOML changelog entries are still well-supported.
## Testing
- Existing tests & lints in CI
- Ran `smithy-rs` [dry-run
release](https://github.com/smithy-lang/smithy-rs/actions/runs/10100442953)
and confirmed the correctness of `CHANGELOG.md` and
`SDK_CHANGELOG.next.json` in the release artifacts
- Ran the internal release and confirmed `CHANGELOG.md` was rendered
correctly in `aws-sdk-rust`
----
_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>
## Motivation and Context
Fixes the last [failed backport workflow
run](https://github.com/smithy-lang/smithy-rs/actions/runs/8971718857/job/24638066793)
## Description
The error `refusing to merge unrelated histories` was caused by the same
reason described in prior PRs (#3479, #3480). We need to tell git
unshallow histories so that it knows they are actually related.
## Testing
Ran the failed workflow from this branch and successfully generated a
backport PR3625.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The verify TLS CI step is flaky at the moment, so it would be helpful to
be able to run it manually against main to see if it was the PR that
broke it, or if it is its general flakiness.
----
_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 sets the `rust-version` property on generated Cargo.toml files
for the AWS SDK crates. It doesn't attempt to place the property on the
runtime crates for now since that will either require manual updating,
or more machinery to automate.
----
_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 CI job that checks CI credentials fails when run on forks, resulting
in daily job failure alerts in forks.
Example failure:
https://github.com/iamjpotts/aws-smithy-rs/actions/runs/8768654532
See https://github.com/smithy-lang/smithy-rs/issues/3519.
## Description
For the `Daily Credentials Verification` workflow, add a condition on
each of its jobs so that they will only run for the
`smithy-lang/smithy-rs` repo and not any forks.
## Testing
No code changes.
## 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
----
CI only; no change log entry required.
_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>
It seems upgrading cargo-semver-checks to 0.30 made it take
significantly longer than before (going from less than 20 minutes up to
between 1-4 hours). Reverting it back to 0.24.1 for now to keep CI
faster.
----
_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
Upgrade JDK to 17 in the repository
----
_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 adds reasonable timeouts to each CI job so that a PR isn't held
up for six hours by a hung runner.
----
_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
A step `trim-changelog-next-on-main` has been
[skipped](https://github.com/smithy-lang/smithy-rs/actions/workflows/release.yml?query=actor%3Aaws-sdk-rust-ci)
probably since a release branch `smithy-rs-release-1.x.y` was created.
## Description
We no longer directly remove released entries from CHANGELOG.next.toml
on `main`. We do so by backport PRs to merge `smithy-rs-release-1.x.y`
to `main`. So `open-backport-pull-request` now depends on `release`,
instead of `trim-changelog-next-on-main`.
## Testing
`open-backport-pull-request` depending on `release` can only be "tested"
in prod runs, so we'll see what happens in the next release. If
`open-backport-pull-request` fails, we will manually run it and address
whatever issue that comes up.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
The new canary secrets weren't being propagated from the root prod
release workflow into the CI workflow, so the canary was failing. This
PR propagates those secrets, and also makes it possible to run the full
CI workflow in a dry-run release so that it's possible to test in the
future.
----
_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
Runs dry-run release workflow daily
## Description
We've had quite a few instances where we discovered that a dry-run
failed when we were about to release, by which time a good amount of
code changes were accumulated in the `main` branch. That sometimes made
it harder to investigate the underlying root cause, compared to if we
had run dry-run daily. To alleviate the issue, this PR runs a dry-run
release daily, ensuring that the `main` branch is in good shape to kick
off a prod release and that we can react to a dry-run failure caused by
a PR merged to the `main` the previous day.
To make this happen, the existing release workflow `release.yml` has
been converted to a reusable workflow (with `workflow_call`). This is
because a scheduled workflow run cannot take inputs, making it difficult
to pass `commit_sha` and the `dry_run` flag to it. With `release.yml`
being a reusable workflow, we have two new workflows calling
`release.yml`: `prod-release.yml` and `dry-run-release.yml`, both of
which we can manually trigger and we can also trigger the latter via
cron.
Note that there is no longer a checkbox `dry-run` that used to exist in
`release.yml`. Instead, we choose a corresponding workflow.
## Testing
Verified the previous workflows continued to work:
- manually triggered dry-run release
- manually triggered prod release
However, a scheduled dry-run has not been tested because we first need
to check-in `dry-run-release.yml` to main for a scheduled workflow to
kick-in. In other words, we'll do live test and see what happens (will
fix if any issues come up).
----
_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
Automatically opens backport PRs merging
`smithy-rs-release-1.x.y-release` to `main`.
## Description
A workflow `backport-pull-request.yml` can be called in two ways:
- called automatically when a prod release runs
- called manually when a patch fix has been made to
`smithy-rs-release-1.x.y-release` and needs to be back-ported
## Testing
- Triggered the workflow manually and confirmed [this (dummy)
PR](https://github.com/smithy-lang/smithy-rs/pull/3556) got created
- Triggered the workflow automatically and confirmed [this (dummy)
PR](https://github.com/smithy-lang/smithy-rs/pull/3557) got created
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
## Description
This does several things:
1. Upgrade to RusTLS 0.23 which enables FIPS support
2. Add smoke test of the clients. This revealed a bug where https URLs
were not supported.
This is technically a breaking change because I added `non_exhaustive`
to the CryptoMode enum.
<!--- Describe your changes in detail -->
## Testing
New integration tests. I expect this to fail in CI since I'll need to
update the build image to match.
## 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
This removes the (unneeded) flags from the smithy-rs release job that
set the stable/unstable versions.
## Testing
- [x] ran a dry run on the branch
## 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
We've hit issues several times where semver hazards were not discovered
until release. Now that we've removed version arguments, we can now run
this test on PRs.
----
_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 same reason for #3500, which is GitHub actions do not allow us to
manually trigger them unless they are first checked-in to the main
branch.
## Description
This PR adds a skeletal workflow file for manually invoking canary
within `smithy-lang/smithy-rs` on behalf of external contributors.
Forked repositories will be missing repository secrets to run the canary
in CI so it will always fail for external contributors. As a workaround,
maintainers will manually trigger `manual-canary.yml`, given a PR number
from an external contributor as input.
A subsequent PR will fill in the blank.
----
_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
## Description
After [upgrading to
actions/upload-artifact@v4](https://github.com/smithy-lang/smithy-rs/pull/3497),
it seems to have brought a behavior change where an artifact with the
same name is [disallowed by
default](https://github.com/smithy-lang/smithy-rs/actions/runs/8423689643/job/23067178393#step:4:639)
within a workflow run.
This happened during a
[release](https://github.com/smithy-lang/smithy-rs/blob/main/.github/workflows/release.yml)
workflow where it first invoked ci.yml (which then called
`generate-smithy-rs-release` and created an artifact with that action
name) and then called `generate-smithy-rs-release` by itself (attempted
to create an artifact with that action name again, leading to the error
above). This was not a problem previously when we were using
`actions/upload-artifact@v3`.
This PR explicitly sets `overwrite: true` to bring back the old behavior
for a place that's affected.
----
_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
Add a skeletal workflow file for later invoking canary in `aws-sdk-rust`
from within `smithy-rs` CI. GitHub actions do not allow us to manually
trigger them unless they are first checked-in to the main branch.
(**Disclaimer**: we may end up executing `canary-runner` from a
smithy-rs CI step without invoking canary in `aws-sdk-rust`, but for the
sake of illustration, assume we invoke canary in `aws-sdk-rust` for the
rest of the PR description)
## Description
To briefly explain where we're going, a diagram below illustrates how
relevant workflow files look like when we run canary in `smithy-rs` CI
(in the context of this PR, it will check-in a file that says
`canary.yml` in red).
<p align="center">
<img width="600" alt="Screen Shot 2023-02-08 at 3 47 05 PM"
src="https://github.com/smithy-lang/smithy-rs/assets/15333866/4a336f7b-8d41-42e4-b59d-4aa87ab91093">
</p>
We will add a new CI step that runs canary in `aws-sdk-rust` from within
`smithy-rs`. It will work when run as part of `cr-pr.yml` but it won't
when run from `cr-pr-forks.yml` (i.e. for external contributors) because
their forked repos do not have a necessary repository secret to invoke
canary in `aws-sdk-rust`. To work around, we will manually run
`smithy-lang/smithy-rs/.github/workflows/canary.yml` on their behalf
with the name of a fork and a commit hash.
----
_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._
Our workflows used outdated actions and that was causing deprecation
warnings for Node v16. Those annoyed me so I updated everything.
----
_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 -->
## Description
<!--- Describe your changes in detail -->
## 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. -->
## 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
I'm not sure what changed but I was able to reproduce the failure from
https://github.com/smithy-lang/smithy-rs/actions/runs/8242141624/job/22564640708
with the downloaded release artifact. Because the clone was shallow, git
did not attempt to push because the histories were unrelated.
Of course, they are in reality, but because the history is shallow git
doesn't know that.
I verified this allowed a dry run push to succeed locally.
----
_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
- #1925
## Description
This adds a minimal Hyper client, focusing on not exposing any unstable
APIs. For this reason, the `Client::Builder` customization API is not
exposed anymore. We do this because at some point in the future, we will
likely move away from the hyper-util based Client.
The code for this was lifted directly from the Hyper 0.14 implementation
but updated for new traits.
However, this does come with some new valuable pieces:
1. Support for aws-lc (no FIPS yet)
2. Support for providing a custom DNS resolver
## Testing
- E2E test with Hyper. A Canary should also be added
(https://github.com/awslabs/aws-sdk-rust/issues/1089)
## 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._
See https://github.com/smithy-lang/smithy-rs/pull/3436
----
_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 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>
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._
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._
Showcase how to pass TLS derived information to server operation
handlers, like the certificate chain presented by the client.
To test, run `RUST_LOG=pokemon_service_tls=DEBUG cargo run` and `curl -v
--insecure https://localhost:13734/do-nothing`. Alternatively, run the
tests using `RUST_LOG=pokemon_service_tls=DEBUG cargo test`, which have
been updated to hit the operation that logs the TLS connection derived
information.
----
_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
Adds a daily credentials verification workflow
## Description
We rotate credentials manually. Those credentials are
`RELEASE_AUTOMATION_BOT_CRATESIO_TOKEN` and
`RELEASE_AUTOMATION_BOT_PAT`. While the validity of those credentials
are checked during dry-runs of [the release
workflow](https://github.com/smithy-lang/smithy-rs/blob/main/.github/workflows/release.yml)
we've had instances where a dry-run failed because it was not idempotent
and we nevertheless kicked off a production run, only to find out the
token was invalid. This raises the need for daily credentials
verification, and the PR adds one.
The workflow will check the validly of two credentials
`RELEASE_AUTOMATION_BOT_CRATESIO_TOKEN` and
`RELEASE_AUTOMATION_BOT_PAT`, each checked by a separate job. Upon
failure, a job will notify us as follows:
<img width="1056" alt="Screenshot 2023-12-12 at 6 26 40 PM"
src="https://github.com/smithy-lang/smithy-rs/assets/15333866/1105b26b-7064-4ba2-849a-5969d59f1dd4">
## Testing
Manually triggered failures and got the messages in the above
screenshot. Also verified a successful run with valid credentials.
----
_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
To manually trigger a workflow, the workflow file needs to have a
revision in the main branch. This PR adds an empty workflow file for
credentials verification. A subsequent PR will fill the contents.
----
_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
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._
## 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
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
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->
## Description
<!--- Describe your changes in detail -->
## 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. -->
## 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
In our GitHub [release
workflow](https://github.com/smithy-lang/smithy-rs/actions/workflows/release.yml),
we require production runs to be triggered by the bot user
`aws-sdk-rust-ci`, which has special permissions. There are times we
have triggered a production run by our own actors and later realized it
wasn't the bot user.
Although there is a way to recover from that (logging in as the bot user
and rerunning the failed step), it's so much easier to add the initial
check to the workflow, especially when that's cheap to add. This PR,
therefore, adds a job `check-actor-for-prod-run` to the workflow.
Note that if it's a dry-run, `check-actor-for-prod-run` will be skipped
and the rest of the jobs in the workflow will be executed normally.
## Testing
Tested the following scenarios using the release workflow:
- making sure that `check-actor-for-prod-run` will be skipped in a
dry-run and the dry-run should succeed
([link](https://github.com/smithy-lang/smithy-rs/actions/runs/6886643811))
- making sure that `check-actor-for-prod-run` will kick in for a prod
run and let the prod run fail if run by me
([link](https://github.com/smithy-lang/smithy-rs/actions/runs/6886709963/job/18732793128))
- making sure that `check-actor-for-prod-run` will kick in for a prod
run and let the prod run proceed if run by the bot user
([link](https://github.com/smithy-lang/smithy-rs/actions/runs/6886738756/job/18732857316)
- I canceled the run as soon as I conformed the check worked)
----
_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._
Fahad Zubair