laconic-sdk tests in CI #46
Labels
No Label
bug
C:CLI
C:Crypto
C:Encoding
C:Proto
C:Types
dependencies
docker
documentation
duplicate
enhancement
go
good first issue
help wanted
high priority
in progress
invalid
javascript
low priority
medium priority
question
Status: Stale
Type: ADR
Type: Build
Type: CI
Type: Docs
Type: Tests
urgent
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/laconicd-deprecated#46
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Run laconic-sdk test suite against laconicd docker image in CI.
The plan here is to add laconic-sdk as a repo dependency in the CI environment, the CI will build the tests from there and run them against the new version of laconicd.
Run these tests on PRs to main and releases.
@ABastionOfSanity in light of https://github.com/cerc-io/laconic-sdk/issues/8 figuring out how to run the laconic-sdk tests in CI is pretty high priority imo
Have CD for a container that incorporates the built cosmos-sdk, such that anybody can pull that container with the
latest
tag and execute with adocker run
command.This will work unless you are making breaking changes on laconicd, which require changes to comsos-sdk. For this scenario it would be helpful to be able to target the CD to a specific commit/branch/release of laconicd.
See: https://github.com/cerc-io/laconicd/pull/71
In that PR I have running the test suite in a containerized network working. However the tests fail. Why, TBD.
Tests pass locally, but failing in CI is masked by docker logs output.
Doubling bond in naming tests from sdk side get tests passing.