- Remove all crates that are not linked with `autoprecompiles`,
`openvm`, `constraint-solver`
- Remove tests and artifacts linked with removed crates
- Adjust CI
Based on commit 1dbe4db
- Split into two crates, lib and cli
- upgrade stwo, marked one stwo test `should_panic` @ShuangWu121
- various clippy and fmt fixes linked to the rust version update
- bring all rust versions to 2025-05-14. CI still installs other
versions for openvm which uses them internally. The stable rust version
we test on is bumped to 1.85
- remove `examples` and related tests, which test the powdr crate on the
previous version of powdr (since it uses another nightly). Happy to
discuss this if it's important @leonardoalt
Instead of setting `mtime` to the committed date, which @lvella noted is
error-prone, this PR does the following so that we can utilize the build
cache:
- check out the commit the build cache was built for
- set mtime to the time the cache was built
- check out the commit we are running the tests on
This hopefully has the effect that all modified files will have the
current time as mtime and will trigger re-builds correctly
It seems WarpBuild removed the ability to overwrite a cache with the
same key.
But since they allow for removing a cache, this fix simply removes the
old one before saving the new one.
Please make sure the build cache test run was successful before merging.
I'm not really sure if this is the right fix. For the riscv targets, we
are using nightly-2024-08-01 - is that on purpose? Maybe we should keep
the examples on 2024-08-01 as well?
Working on the assumption that there is a race condition between the
delete command and the push new cache command, that is why some days we
have no cache.
Similar to #1193, but in here I am just interested in having it working
end-to-end, at least for a few cases, so that everybody can try it and
build upon.
<!--
Please follow this protocol when creating or reviewing PRs in this
repository:
- Leave the PR as draft until review is required.
- When reviewing a PR, every reviewer should assign themselves as soon
as they
start, so that other reviewers know the PR is covered. You should not be
discouraged from reviewing a PR with assignees, but you will know it is
not
strictly needed.
- Unless the PR is very small, help the reviewers by not making forced
pushes, so
that GitHub properly tracks what has been changed since the last review;
use
"merge" instead of "rebase". It can be squashed after approval.
- Once the comments have been addressed, explicitly let the reviewer
know the PR
is ready again.
-->
---------
Co-authored-by: Leo <leo@powdrlabs.com>
