bootstrap repository setup #1
Conversation
| # Ignore `trybuild` errors as they are irrelevant and flaky on nightly | ||
| TRYBUILD: overwrite | ||
|
|
||
| semver: |
There was a problem hiding this comment.
We may want to disable/remove this until we actually publish as it will fail until then (it's not marked as a required check currently though)
.github/workflows/ci.yml
Outdated
| contents: read | ||
|
|
||
| jobs: | ||
| # depens on all actions required for a "successful" CI run |
There was a problem hiding this comment.
| # depens on all actions required for a "successful" CI run | |
| # depends on all actions required for a "successful" CI run |
.github/workflows/ci.yml
Outdated
|
|
||
| - name: test s3-transfer-manager HLL | ||
| run: | | ||
| set -euxo pipefail |
There was a problem hiding this comment.
I thought these settings happened by default in github workflows?
.github/workflows/ci.yml
Outdated
| - ubuntu-latest | ||
| - windows-latest | ||
| - macos-latest |
There was a problem hiding this comment.
To avoid CI unexpectedly breaking, I prefer to use specific versions of the runners (example: awslabs/aws-crt-ruby#61). I don't know a good short comment to indicate "this was latest when I authored this, feel free to update"
| - ubuntu-latest | |
| - windows-latest | |
| - macos-latest | |
| runs-on: ubuntu-24.04 |
I'm fine using "latest" for stuff where you really want to know when your stuff breaks against latest (e.g. Rust version). But a new version of ubuntu isn't usually that kind of thing
| @@ -0,0 +1,270 @@ | |||
| on: | |||
| pull_request: | |||
There was a problem hiding this comment.
this means CI won't run unless we've OK'd every single commit from external forks, right?
There was a problem hiding this comment.
That is a setting at the repository level not in individual workflows but yes that is under our control.
| uses: dtolnay/rust-toolchain@stable | ||
| with: | ||
| toolchain: ${{ env.rust_stable }} | ||
| - name: Install cargo-nextest |
| cargo nextest run --workspace --all-features | ||
| cargo test --doc --workspace --all-features | ||
|
|
||
| fmt: |
There was a problem hiding this comment.
Does it help lead to better dev experience if we eventually catch complaints from fmt or clippy prior to opening a PR, e.g. pre-commit-hooks?
There was a problem hiding this comment.
Yeah we can add those precommit hooks in a follow up PR, I just wanted to be sure we get them checked and this was easy to add with the rest of CI.
Description of changes:
Adds basic repository setup (README, CODEOWNERS, basic CI, gitignore, etc).
NOTE: I have bootstrapped the
mainbranch with the existing commits from awslabs/smithy-rs@s3-tm-main already.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.