Better CI/CD or Full CI/CD

[jot2re]

We need to construct a more complete CI/CD flow during PRs. In particular when it comes to integration, both with authenticator.js and attestation.id.

[SmartLayer]

@abcfy2 do you know the hardhat testing flow?

This is actually not trivial - we might do a small project for getting this right, proper CI/CD setup between attestation.id, authenticator.js, attestation.jar and the smart contracts take a bit of effort to figure out.

[foxgem]

we discussed it with @abcfy2 these days. actually, I suggest we still use the old name: Better CI/CD or Full CI/CD.

here is my thought, although not organized as a final version yet:

• current dependencies between projects:
  • tn -> attestation.id
    • backend -> attestation.jar
    • frontend -> attestation npm
• each project has unit tests or integration tests, more or less.
• each project has its own ci /cd

currently, the biggest problem is: when the dependent project is changed, we don't know if this change will introduce a break.

so, my plan is:

1. we should have a dependency graph about related projects.
2. for each the projects (let's call it Pipe 1):
   • set up ci if there is not
   • add more testcase to increase the coverage
   • the dependencies are installed from the public repos (for example: maven, npm ...) in this ci.
3. for each dependent projects (let's call it Pipe 2):
   • after Pipe 1, do a pre-release. there are several solutions for this purpose:
     • private maven repo or npm repo
     • or simple flat file directory.
   • use another build file which installs the dependencies from the private repos. for example:
     • for a java project, change implementation('org.tokenscript:attestation:...') to other path or other way.
     • for a js/ts project, npm link can help.
   • rerun all the test part in Pipe 1.
4. for each dependent projects passing Pipe 2
   • trigger a deployment pipeline:
     • generate change logs: if we can follow a git commit spec, this change log can be generated automatically.
     • package
     • upload to the public repo or deploy the contracts.

this full pipeline will set up a safe net for our current development. at the same time, it will reuse most of our current efforts.

[jot2re]

In relation to this it should also be mentioned that there are some issues with the hardhat tests in attestation.jar, see issue #254 As part of this CI/CD task these should also be reenable.

[foxgem]

there are some issues with the hardhat tests

yes, that's why I suggest we get our dependencies graph first, ;).

[foxgem]

The following is the draft pipeline for discussion:

The basic ideas behind are:

1. each commit will trigger the target github repo pipeline.
2. if this github repo is depended on other projects, then:
   1. a pre release pipeline will be triggered.
   2. the depending projects will use this new pre release to run test cases.
3. else, only related pipeline will be triggered.

Note:

• Snapshot means the artifact built in the pre release pipeline.
• Maven / npm means the public component repo.
• The dependencies resolution used in snapshot testing: https://github.com/features/packages

[jot2re]

It looks really good! Thanks @foxgem! I think the only thing we might also want to add is the smart contract hard hat testing when attestation.jar has been updated. See issue #254.

[oleggrib]

currently attestation JS code located under https://github.com/TokenScript/attestation/tree/main/src/main/javascript/crypto to test it I do next steps:

1. in the root folder gradle test --rerun-tasks to regenerate test output files
2. in the main/src/main/javascript/crypto folder I run npm run testjest , it read output files from gradle test and tests agains them.

So we can run grable test and npm test one by one or find another solution and generate JAVA output before each NPM test

another note - TN includes attestation npm module and use it to decode magicLink, to test attestation, make proof etc., so ideally TN should be updated when attestation npm changed

[foxgem]

Phase#1

Goals:

• attestation github clean up
• attestation <> attestation.id CI integration

Length: 1~2 weeks

Action Plan

1. Attestation main branch
   1. java component (java-main-p1)
      1. build - test - grype
   2. js component (js-main-p1)
      1. build - test
   3. contract component (contract-main-p1)
      1. build - test
2. Attestation stage branch
   1. java component
      1. java-p1 - prerelease - attestation.id/backend-main-p1
      2. js-p1 - prerelease - attestation.id/frontend-main-p1
3. attestation.id main branch
   1. backend (backend-main-p1)
      1. build - test
   2. frontend (frontend-main-p1)
      1. build - test
4. attestation main enhancement
   1. java-main-p1: trigger js-main-p1 and contract-main-p1
   2. js-main-p1: security scanning
   3. contract-main-p1: security scanning

[foxgem]

after discussing with @jot2re , the output of grype will be like:

success

% grype attestation-0.3.18-all.jar 
 ✔ Vulnerability DB        [updated]
New version of grype is available: 0.40.0
 ✔ Indexed attestation-0.3.18-all.jar 
 ✔ Cataloged packages      [23 packages]
 ✔ Scanned image           [0 vulnerabilities]
No vulnerabilities found

failure

% grype build/libs/backend-0.1-all.jar 
 ✔ Vulnerability DB        [no update available]
New version of grype is available: 0.40.0
 ✔ Indexed build/libs/backend-0.1-all.jar 
 ✔ Cataloged packages      [83 packages]
 ✔ Scanned image           [25 vulnerabilities]

NAME                         INSTALLED     FIXED-IN      TYPE          VULNERABILITY        SEVERITY 
netty-codec-http             4.1.73.Final  4.1.77.Final  java-archive  GHSA-269q-hmxg-m83q  Medium    
netty-reactive-streams       2.0.5                       java-archive  CVE-2019-20445       Critical  
netty-reactive-streams       2.0.5                       java-archive  CVE-2021-21290       Medium    
netty-reactive-streams       2.0.5                       java-archive  CVE-2021-37136       High      
netty-reactive-streams-http  2.0.5                       java-archive  CVE-2015-2156        High

so, the grype task is to find if there is "0 vulnerabilities" in the output. cc @abcfy2

[abcfy2]

I've committed java-p1 CI, which will run gradle build & test & grype check after push / pull_request to main branch.

Sample: https://github.com/TokenScript/attestation/actions/runs/2532698892

[abcfy2]

js-p1 CI added. When push/pull_request code changes to main branch in src/main/javascript/crypto/ directory will trigger this CI.

Sample: https://github.com/TokenScript/attestation/actions/runs/2536158552

[abcfy2]

contract-p1 CI addes.

[abcfy2]

stage branch workflow finished.

Result sample:

java CI: https://github.com/TokenScript/attestation/actions/runs/2596014131

js CI: https://github.com/TokenScript/attestation/actions/runs/2595982268

[foxgem]

Phase#2

Goals: including TN project

Length: 1~2 weeks

Action Plan

1. TN main branch (tn-p1)
   • build - test
2. if the stage branch changed in tokenscript/attestation or attestation.id
   • pre-release-of-dependencies - call tn p1

[abcfy2]

tn-p1 CI finished: https://github.com/TokenScript/token-negotiator/runs/7248708069?check_suite_focus=true

[abcfy2]

Phase#2 done.

tokenscript/attestation does not reference attestation.id since now. So attestation.id does not trigger tokenscript/attestation since now.

Sample: https://github.com/TokenScript/attestation/actions/runs/2648616646

[foxgem]

@abcfy2 as we discussed, please enhance the CI with E2E testing.