-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
Run test suite in GH Actions #195
Conversation
…w HeaderHash in preparation for indexing logic changes DnaAddressable now must be directly storable as an Entry in order for fully-qualified IDs to be encoded in the DHT. This means conversion traits to/from hdk::prelude::Entry must be created, and the inner type of DnaAddressable cannot be ambiguous since this would make implementing such conversions impossible. This makes sense and is a good thing, because it enforces that only tuples of (DnaHash, EntryHash) can be used as identifiers. Implementors should not be linking to revisions but rather records.
Update: looks like travis last ran 2 years ago as well as Circle. Links: https://app.circleci.com/pipelines/github/holo-rea/holo-rea |
…fully qualified address necessary changes to related trait bounds to support this
@Connoropolous actually just submitted a PR for github actions, and those are enabled now to generate builds. Whether we want the test suite to run as part of that process is another matter, possibly an evolving one. At present still maybe 40-50% of the test suite is failing, mostly just because they haven't yet been updated for RSM (see #174). So that's why I haven't yet re-enabled Travis. There might be a worthwhile interim step where we run tests on one CI system and builds on another. Tests should be run for any change on Eventually though yes I think it's best if everything gets run in GH actions and the build doesn't get kicked off if the tests fail! Oh, and a note on the test suite- I didn't have many Rust tests in the beginning so was only running Tryorama tests in JS. Eventually I think it would be best to simply run Does that help? Opinions & input very welcome (: |
cleanup some remaining unneeded non-generic deletion payload structs remove unneeded type generics on deletion functions
…e DHT remove unneeded direct retrieval of identity EntryHash, now gets read from DnaAddressable
…roc macro attributes in macros-by-example does not work
…defs overriding already-registered defs in indexing zomes
I still haven't sent Pospi the cachic secret, that we can add as a secret to the repository, so I will do that now. |
I also just approved the CI runs for this PR, since Harlan and this fork are 'new contributors' |
myself I've never yet tried running the test suite, so I can't comment like Pospi can |
.cargo/registry/cache/ | ||
.cargo/git/db/ | ||
target/ | ||
key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }} |
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.
this repo has the rather anomalous behavior of not checking the Cargo.lock
file into git, which as I understand it has its reasons, but from my experience has had some real downsides
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.
in my other one, I use Cargo.toml
, while realizing that that's not best practice
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.
this repo has the rather anomalous behavior of not checking the
Cargo.lock
file into git, which as I understand it has its reasons, but from my experience has had some real downsides
Hmm I think this is actually best practice for libraries (but not binaries) — https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries
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.
in my other one, I use
Cargo.toml
, while realizing that that's not best practice
Thanks, should update
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.
That kinda makes sense. The zomes themselves are more like binaries, while the things in lib
are libraries, so 🤷 I'm not sure
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.
That kinda makes sense. The zomes themselves are more like binaries, while the things in
lib
are libraries, so 🤷 I'm not sure
More nuanced suggestion here: https://stackoverflow.com/a/63727523
@pospi have you considered moving to sweetest instead of upgrading
tryorama? It’s pretty great to have your tests of rust lib in rust. It’s
slow (unless you’re on an M1 mac) but worth it in my experience so far.
|
That’s exactly the behavior of this PR was merged. And they would run in parallel if you pushed a tag.
Sure, we could chain the builds conditionally later. |
Ah cool. Still the run was about 5 min, must have been found in the holochain-ci cache. |
@pospi overall I’d suggest you just leave this open until you’re ready to run tests in CI, happy to help more at that time if desired. |
"have you considered moving to sweetest instead of upgrading |
- name: Set up nix | ||
uses: cachix/install-nix-action@v16 | ||
with: | ||
nix_path: nixpkgs=channel:nixos-21.05 | ||
extra_nix_config: | | ||
substituters = https://cache.nixos.org https://cache.holo.host https://ci-builds.cachix.org https://holochain-ci.cachix.org | ||
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= cache.holo.host-1:lNXIXtJgS9Iuw4Cu6X0HINLu9sTfcjEntnrgwMQIMcE= cache.holo.host-2:ZJCkX3AUYZ8soxTLfTb60g+F3MkWD7hkH9y8CgqwhDQ= ci-builds.cachix.org-1:fxB0+h/MMlCpXf6hFsQM31YpHbaQoRmcNPNHwDUkXA4= holochain-ci.cachix.org-1:5IUSkZc0aoRS53rfkvH9Kid40NpyjwCMCzwRTXy+QN8= |
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.
we should consolidate between this way of defining these, and the nix.conf
way that is currently at play. I have zero attachment to which way it goes
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 am referring to this file, and the command in the Release CI workflow that references it
https://github.com/holo-rea/holo-rea/blob/sprout/.github/nix.conf
…or module remove deprecated type alias for DNAMappings
…response format
…into LinkTag fixes Unit CRUD tests in h-REA#249 by allowing string IDs to be queried from the DHT again, after PathEntry changes made this impossible using Path construct
…g issues. All index updates & RPC calls now uniformly treated as non-critical and logged for output to assist in debugging.
Just noting here that all integration tests are passing again, so we can probably go ahead with this. I'd also like to see checks configured so that feature branches can't be merged into |
closing in favor of #267 since the git histories became diverged in a weird way I had trouble with |
Runs in Ubuntu and Mac. Would run in Windows too, but I don't think nix works there.
I also came across these lines in circle and travis configs (circle has not run for 2 years, travis I'm not sure) -- maybe these are useful ways to run the tests? @pospi LMK if you'd like different test commands, or if you want test in GH actions at all.