move signify repository into keria
Per discussion on discord.
This PR moves the signify-ts into keria repository. I have included the commit history from signify-ts repository my merging with "--allow-unrelates-histories". The purpose is to use signify-ts as a reference client implementation, they are to be released and tested together as a unit.
- Taken from latest
mainon signify-ts - Runs integration tests on every PR and push closes #233
- Publish workflow that creates dev tags on push to main and releases on workflow_dispatch, supersedes #394
- Docker tag: weboftrust/keria:x.y.z-dev.abc123
- Npm version: signify-ts:x.y.z-dev.abc123
Potential todos, can also be subsequent PRs
- [ ] Update documentation.
- [x] Fix integration tests.
The failing integration tests are probably also failing on signify-ts if they would run against latest keria. So I am not sure if that needs to be part of this PR. I have fixed the tests on another branch, but it contains a lot more changes that we probably do not want to add without reviewing.
When I set up the docker-compose, I opted for using network_mode: host. This enable you to switch between running keria or the witness-demo as containers, or locally, without updating any configuration or setting environment variables. On docker desktop, you might have to enable this.
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 86.54%. Comparing base (1f22907) to head (a51123e).
:warning: Report is 2 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #398 +/- ##
==========================================
- Coverage 86.60% 86.54% -0.07%
==========================================
Files 25 25
Lines 5286 5298 +12
==========================================
+ Hits 4578 4585 +7
- Misses 708 713 +5
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
I have never done this but it might be worth experimenting to see if there's a way to merge the git histories. From a quick search, there seems to be a few options. Any thoughts?
The failing integration tests are probably also failing on signify-ts if they would ron against latest keria. So I am not sure if that needs to be part of this PR. I have fixed the tests on another branch, but it contains a lot more changes that we probably do not want to add without reviewing.
Agreed. Either we can do it after, or fix Signify on the main branch now.
With respect to other changes: As both a sanity and security check, I'd like to take a hash of the signify-ts repo directory locally and compare against the new directory being introduced here. So I would avoid updating anything inside the folder (e.g. docs) until another PR. cc @m00sey @kentbull
With respect to other changes: As both a sanity and security check, I'd like to take a hash of the signify-ts repo directory locally and compare against the new directory being introduced here. So I would avoid updating anything inside the folder (e.g. docs) until another PR.
I have removed package-lock.json and used in the root instead. Also fixed the linting config. But I can revert both of those changes. Otherwise a hash of the src directory would maybe suffice.
Otherwise a hash of the src directory would maybe suffice.
Sure, that works for me!
@iFergal I have now included the commit history from signify-ts.
Do we want to do one last release of KERIA and Signify with all latest changes before we do this merge?
The delegation fixes I have in a draft PR to KERIpy 1.2.7, that also need to go in to main and 1.3.2, need to be merged to KERIpy, then a new KERIA version with the new KERIpy version.
What do you think about us doing all of that and then merging this? I like the idea of processing all in-flight work, except ESSR and maybe some old PRs, and then doing this repo merge.
Do we want to do one last release of KERIA and Signify with all latest changes before we do this merge?
The delegation fixes I have in a draft PR to KERIpy 1.2.7, that also need to go in to main and 1.3.2, need to be merged to KERIpy, then a new KERIA version with the new KERIpy version.
What do you think about us doing all of that and then merging this? I like the idea of processing all in-flight work, except ESSR and maybe some old PRs, and then doing this repo merge.
Fine by me. I will wait doing any rebasing until then so I don't duplicate work. It's not very complicated though. Biggest problem was failing integration tests in signify-ts. If we can ensure that the tests pass against the release, this PR will be even easier to re-create as no source or test code will have to change.