You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Add the confirmation states representing the forestrie trust levels
as described here:
https://github.com/datatrails/\
epic-8120-scalable-proof-mechanisms/blob/main/event-trust-levels.md
* Add the provisional extra details we need in the event for the
MERKLE_LOG proof mechanism
* Use a single oneof per proof mech details
fix: the include paths for openapiv2
build: simplify the include path discovery
build: export the proto dependencies under proto-include
This means consumers do not need to replicate the tricky go list
based include path discovery
ci: add a job to check the dockerall task works
But note this is disabled due to acr permissions issues
For people who can't or wont install protoc and go
AB#8859
remove fields that are not settled yet
use oneof for proof_details
Copy file name to clipboardExpand all lines: README.md
+23-8
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,26 @@
2
2
3
3
Common public api definitions for the DataTrails platform
4
4
5
+
## Finding and including proto files for depdendecnies
6
+
7
+
tools/go.mod is the source of truth for all proto providing dependencies. That file alone specifies both the upstream version we are using *and* is used, via go install, to make the .proto files available locally
8
+
9
+
This corresponds to the practice recommended by grpc-gateway and elsewhere
10
+
11
+
1.*** ALWAYS *** Use tools/go.mod to specify the dependency version.
12
+
2. Add the package to the `go install` command in the apis:preflight task
13
+
3. If necessary, add a var for the new path in any-api **and** then add a reference to that var in the PROTO_INC var.
14
+
15
+
Following this practice removes the need for dual maintenance of dependency versions in the builder image. It also produces a build cycle that is significantly faster.
16
+
17
+
Cross repository builds in docker while using go.work to refer to locally modified sources don't work. And this setup is essential for an efficient workflow.
18
+
19
+
## bootstrap proto files
20
+
21
+
The proto's for protoc itself, the googleapis, and the grpc_health proxy are needed by almost everything and are also don't apear to be compatible with the tools/go.mod approach
22
+
23
+
For this reason we curl the proto's and make them available in our aggregate proto-includes archive
24
+
5
25
## Workflow for updating common apis
6
26
7
27
### Ensure the go tool chain is setup on your host
@@ -46,12 +66,11 @@ If you want to iterate on *just* the helper go code and there tests, do one roun
46
66
47
67
`apis:bootstrap` -> `apis:clean:generated`
48
68
49
-
Then just iterate using `apis:build`
50
-
69
+
Then just iterate using `task apis:generate` and `task apis:test`
51
70
52
71
#### For avid
53
72
54
-
* task avid:xxx
73
+
See the README.md in avid/src/api/README.md
55
74
56
75
##### Build one api against locally cloned go-datatrails-common-api
57
76
@@ -60,8 +79,4 @@ The protos can be included exactly as they are found from a clone of go-datatrai
0 commit comments