relauto: init pr builds #495
Conversation
| - . "${INFRA_DIR}/env/lib/environment-setup" | ||
| - . install-rust-builder |
There was a problem hiding this comment.
Why implement these as scripts that run when sourced vs. just running the scripts?
There was a problem hiding this comment.
In the case of these, we need the environment that's a result of running them.
environment-setupsets up the builder environment and modifies/exports variables like$PATHinstall-rust-buildersets up the builder and adds rust + cargo to the$PATH
I'll also take this opportunity to point out that the shell used by CodeBuild is /bin/sh which is why ..
|
We'll want to drop the buildkit bits when #506 lands. |
|
Rebased and updated to address some feedback from folks. |
| configure_color | ||
|
|
||
| # Use rustup to install rust toolchain | ||
| if ! curl --proto '=https' --tlsv1.2 -sS "https://sh.rustup.rs" | bash -s -- -y --no-modify-path --default-toolchain stable; then |
There was a problem hiding this comment.
Should we be pinning to a Rust version rather than taking the latest release?
There was a problem hiding this comment.
Answer: yes, we should probably be.
Longer answer:
We probably /should/ be pinning to a known version of rust, however, the moving parts affected by the build of rust used are: buildsys, cargo-make, and cargo-deny. All the other components build and run with rust are within the scope of the rust.spec version provided at build time in the build containers.
In the short term, tracking the stable version does give us some amount of certainty about the rust toolchain itself that's used; I think that's this is "good enough for the moment" because we don't have methods or assertions to "qualify" these components when moving to a different version of the rust toolchain.
As far as I know we're already tracking some version of the rust toolchain on each developers' machines - we could stand to improve some in the way of being able to truly vet a bump and tie our dependencies to a version of rust if that's the need.
There was a problem hiding this comment.
fwiw: we're now locked to specific dependencies' versions:
cargo-make:0.23.0cargo-deny:0.2.6
The resource requires it to be a arn with the subpath suffix applied.
This generates the project name with a known and expected prefix. The outputs will provide our other tools with the correct reference under a conventional name in the Stacks' Outputs.
This includes: - Minor reordering and YAML tidying - Use of shorthand syntax for !IntrinsicFns - Use of an explicit LogGroup - Introduction of Parameters for inputs to build resources
This prevents misconfiguration where either the tool has run before or in another unassuming environment.
PR #506 switches us away from needing a daemon running. Signed-off-by: Jacob Vallejo <jakeev@amazon.com>
|
Force pushed to catch up to develop and |
|
Current build failure is a true positive, I think! @iliana does this look like a true failing case to you? https://gist.github.com/jahkeup/8b9c39976408d197e4699f39ae9e4855 |
|
@jahkeup The issue is that we're not locking the cargo-deny version :) v0.4.0 was released November 7 and that updates to v3.7 of the SPDX license list. OpenSSL's license name changed from Lock to v0.3.0 (and also lock cargo-make to whatever the current version is). Tracking the update to deny.toml in #531 |
|
@iliana I see breakage even with cargo-deny-0.3.0: https://gist.github.com/jahkeup/39befb1afeb7053aff636ce91d6b09b7 |
|
@jahkeup oh, my local copy is 0.2.6. >_< Maybe just lock to that for now then. |
There's no apparent need for s3:DeleteObject in the context of CodeBuild operation. Neither the artifact's nor cache's buckets have expirations performed by CodeBuild.
Issue #, if available:
#492
Description of changes:
This implements a basic build-on-pr buildspec for use in CodeBuild.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.