Add support for bzlmod #27
Conversation
Builds the HyperDebug firmware for pull requests. Signed-off-by: James Wainwright <[email protected]>
I don't think this was adding anything over using the GitHub CLI directly. Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
Signed-off-by: James Wainwright <[email protected]>
This reduces maintenence burden. The ARM toolchain was not working entirely correctly in the `WORKSPACE` configuration either for unknown reasons. Signed-off-by: James Wainwright <[email protected]>
| run: | | ||
| git tag ${{ inputs.release_tag }} | ||
| bazel build --stamp :release |
There was a problem hiding this comment.
I don't necessarily have a strong opinion but I can see an advantage to using bazel-release in theory: the release process is part of the build and can be done locally easily. Github/Azure flows are always notorioulsy bad for local reproducibility as they get more complicated.
There was a problem hiding this comment.
That makes sense.
I have this PR for adding bzlmod support to bazel-release: lowRISC/bazel-release#5
If that's merged, we could go back to using it.
|
@jesultra this PR changes the toolchain (still GNU ARM) from the one provided by CRT to the one provided by https://github.com/hexdae/toolchains_arm_gnu which I believe is more up to date and generates a different binary. This is mainly because I couldn't port CRT to bzlmod very easily. I've tested the binary on our HyperDebug in the office, but wanted to get your opinion on changing the toolchain here. |
This project already uses a different toolchain than the one found in ChromeOS "chroot" build environment, meaning that when I do local modifications to the source in platform/ec, and build without using this repository, the resulting binary may behave differently than the official one through this release process. One time recently, timing or optimization differences let to a bug not being detected when I compiled locally. What I am saying is that I do not mind at all the toolchain being changed, and furthermore, if in the process we could make it easier to run the same build process locally, and even with modifications to the source code, then that would be a welcome bonus. |
Summary
This PR does some general cleaning to prepare for and then enable bzlmod support.
WORKSPACEsupport has been removed to reduce maintenance burden and complexity.Best reviewed by commit.
Details
The full changes are:
bazel-releasedependency removed, GitHub CLI used directly.crtdependency swapped fortoolchains_arm_gnuwhich supports bzlmod.BUILDfiles cleaned up with some indirection and hacks removed.WORKSPACEfiles and infrastructure removed.Testing
Tested the deployment in my fork here: https://github.com/jwnrt/hyperdebug-firmware/actions/runs/9853140349
Created this release: https://github.com/jwnrt/hyperdebug-firmware/releases/tag/20240709_01
I've tested the release on our FPGA board by running a few tests that go through HyperDebug.