-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: Build ROM release from versioned git ref #1604
base: main
Are you sure you want to change the base?
ci: Build ROM release from versioned git ref #1604
Conversation
ci-tools/release/build_release.sh
Outdated
# Generate ROM and Image Bundle Binary | ||
cargo run --manifest-path=builder/Cargo.toml --bin image -- --rom-no-log $WORKSPACE_DIR/caliptra-rom.bin --fw $WORKSPACE_DIR/image-bundle.bin | ||
# Copy ROM ELF | ||
cp -a target/riscv32imc-unknown-none-elf/firmware/caliptra-rom $WORKSPACE_DIR/caliptra-rom.elf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand why the things in this file need to be moved to the action definition.
I think the desire with these scripts is that someone can run them locally to build the expected release artifacts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose that's valid. The intention was to build the ROM with the chosen tag first, before checking out HEAD and building some more. I wanted to avoid an actual git checkout
command here, which would mean calling this has side effects.
Other solutions include passing git commit hashes to this script, and running git checkout
here (if the CI is okay with it, and people won't mind the side effects that calling it will have to their working directory, it's an option). Alternatively, we could pass arguments to the script to determine which build stage to run: ROM, FMC/RT, or both. Then the CI/developer is responsible for making any changes in between.
- uses: actions/checkout@v3 | ||
with: | ||
submodules: 'true' | ||
ref: 'rom-1.0.2' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to ability to build all the fw at a specific revision (e.g. via configuration when manually running the job). But I think we still want the automated nightly release to build from head. Otherwise we won't catch any regressions in ROM until we go to build a new release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I think that I got a little lost in all the workflow files. Shouldn't that be handled by build-test.yml? And if this workflow file doesn't generate the release, which one does? This is the only file to call build_release.sh.
778574a
to
ee1925e
Compare
70bf54b
to
bd121d2
Compare
bd121d2
to
f4f02f9
Compare
|
Signed-off-by: Benjamin Doron <[email protected]>
f4f02f9
to
456b551
Compare
…1604,#1691) Signed-off-by: leongross <[email protected]>
…1604,#1691) Signed-off-by: leongross <[email protected]>
…1604,#1691) Signed-off-by: leongross <[email protected]>
…1604,#1691) Signed-off-by: leongross <[email protected]> (cherry picked from commit a52cdb1)
…1604,#1691) Signed-off-by: leongross <[email protected]> (cherry picked from commit a52cdb1)
Address #1464