.github: Build artifacts as part of workflow #210
Conversation
|
You can see what this looks like at: https://github.com/alistair23/libtock-rs/actions/runs/147760734 |
|
The produced artifacts will disappear after 90 days. Is that a problem for using them in Tock's CI? |
|
That's not ideal, but hopefully will be ok |
|
Apparently GitHub decided that downloading artifacts would be too useful and block it without authentication. actions/upload-artifact#51 I don't see a good way to allow Tock to download artifacts from libtock-rs without hard-coding someone's credentials in the scripts. |
alistair23
force-pushed
the
alistair/artifacts
branch
from
985a467 to
b41777c
Compare
Do you still have a use case for this PR? |
|
Kind of. I still think it's worth merging. Worst case it just provides binaries which people can download (if they have a GitHub account). Hopefully GitHub will fix their broken API, otherwise maybe we could have access keys in Tock's GitHub CI (and store them securely) to pull the binaries in. |
If we stick to travis there is a way of encrypting secrets in the CI pipeline, e.g. by https://docs.travis-ci.com/user/encryption-keys/ |
Tock doesn't use Travis anymore; it has migrated entirely to GitHub Actions. I was actually planning to send a PR to migrate |
|
Ping! |
|
bors r+ |
210: .github: Build artifacts as part of workflow r=jrvanwhy a=alistair23 This PR builds libtock-rs binaries as part of the CI. The idea here is then other repos (like the Tock kernel) can then use the binaries for testing. Co-authored-by: Alistair Francis <[email protected]>
|
bors r+ I'm not sure why Bors was cancelled, and its Details page requests permissions I am not comfortable giving it. Trying again blindly. |
210: .github: Build artifacts as part of workflow r=jrvanwhy a=alistair23 This PR builds libtock-rs binaries as part of the CI. The idea here is then other repos (like the Tock kernel) can then use the binaries for testing. Co-authored-by: Alistair Francis <[email protected]>
|
Build failed: |
|
Thanks! Bors is unfortunately almost impossible to debug as it requires an account to even see the logs. Luckily I can see the failure on Travis, I'll send a patch |
alistair23
force-pushed
the
alistair/artifacts
branch
from
b41777c to
c1ab0d5
Compare
|
That should fix it. The Tock submodule was too old and failing trying to download the OpenTitan ROM |
|
bors d+ Please try to merge when the currently-ongoing Travis run is finished. |
|
✌️ alistair23 can now approve this pull request. To approve and merge a pull request, simply reply with |
|
... and the Tock update appears to have broken the test runner. Has the path to tock's QEMU changed? |
|
No, it seems to be a weird Make behaviour. I'm trying to figure it out |
|
Would moving the CI to GitHub actions (aways from Travis) make the debugging easier? If so, let me know, and I'll send a PR. |
|
This should fix the failure: tock/tock#2024 |
Instead of running the setup commands as part of bash -c * just have Make call them from the shell. This fixes a build failure seen at: tock/libtock-rs#210 Signed-off-by: Alistair Francis <[email protected]>
1994: kernel: expose APIs for external `ProcessType`s r=bradjc a=bradjc ### Pull Request Overview This pull request adds new functions with `pub` visibility modifiers to enable an implementation of `ProcessType` to exist outside of the kernel/ crate. These new functions are protected with capabilities since these are very sensitive operations that shouldn't be generally called. I named the new functions `_public`. I don't think we have an existing convention for this, so I made one up. I added a new capability `ExternalProcessCapability` to capture the use case for making these functions and constructors public. Increment/decrement work I re-used the `MainLoopCapability` since I think that accurately captures the permissions needed to increment or decrement work. For the others I wasn't sure what to do, so I added a new capability. Replaces #1984. ### Testing Strategy travis ### TODO or Help Wanted @jon-flatley will this work? ### Documentation Updated - [x] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. 2024: Makefile: Don't run the setup commands inside bash r=ppannuto a=alistair23 ### Pull Request Overview Instead of running the setup commands as part of bash -c * just have Make call them from the shell. This fixes a build failure seen at: tock/libtock-rs#210 ### Testing Strategy Running the CI ### TODO or Help Wanted ### Documentation Updated - [X] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [x] Ran `make prepush`. 2035: OpenTitan: USB support cleanup r=bradjc a=alistair23 ### Pull Request Overview This PR includes various commits to start cleaning up the OpenTItan USB support. This is in preperation of supporting a CDC console in Tock. With this PR the OpenTitan USB device will receive interrupts when attached to a USB host. I have more changes locally working on handling interrupt, but haven't made enough progress to send a PR yet. ### Testing Strategy Connecting the OT FPGA dev kit to a Linux USB host. ### TODO or Help Wanted ### Documentation Updated - [X] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [X] Ran `make prepush`. Co-authored-by: Brad Campbell <[email protected]> Co-authored-by: Alistair Francis <[email protected]>
alistair23
force-pushed
the
alistair/artifacts
branch
from
c1ab0d5 to
b9ede61
Compare
Signed-off-by: Alistair Francis <[email protected]>
Signed-off-by: Alistair Francis <[email protected]>
alistair23
force-pushed
the
alistair/artifacts
branch
from
b9ede61 to
87518f9
Compare
|
Due to #225 I am going to merge this manually. |
This PR builds libtock-rs binaries as part of the CI.
The idea here is then other repos (like the Tock kernel) can then use the binaries for testing.