[ResultDB] Move to using one transaction in ResultDB RPCs.

This is a preparatory CL to updating ResultDB to allow the
realm of invocations to change. After we implement that feature,
we need to be more careful about reading the realm in the same
Spanner transaction as the rest of the data used by a RPC,
as not doing so introduces theoretical weaknesses, such as
Time of Check, Time of Use vulnerabilities.

It simplifies reasoning about RPCs in any case, as it means
they will operate on a consistent snapshot of the system state.

Reading realm in the same transaction as other data does not
need to occur if we have already validated the invocation
has finalized before we read that other data. So this rule
does not apply to the finalizer task body, metadata
ingestion task queue, bigquery exports, etc.

Invocation creation RPCs have also been excluded from this
requirement as it is satisfactory to demonstrate that it was
possible to include the nominated invocations at one point in
time. That the realm of those invocations may change after the
fact is known and the appropriateness of this will be checked
by the UpdateInvocation RPC when the realm is updated.

BUG=b:318397115
TEST=Integration tests

Change-Id: Ibdbf22ce0f03f4f5082d2f79c1c3ca72eebfcb4a
Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/luci-go/+/5347404
Reviewed-by: Matthew Warton <mwarton@google.com>
Commit-Queue: Patrick Meiring <meiring@google.com>
16 files changed
tree: 2d750829489b0b58a88b5473597a413b6491f77f
  1. analysis/
  2. appengine/
  3. auth/
  4. auth_service/
  5. bisection/
  6. build/
  7. buildbucket/
  8. casviewer/
  9. cipd/
  10. cipkg/
  11. client/
  12. common/
  13. config/
  14. config_service/
  15. cv/
  16. deploy/
  17. examples/
  18. gae/
  19. gce/
  20. grpc/
  21. hardcoded/
  22. led/
  23. logdog/
  24. luci_notify/
  25. lucicfg/
  26. lucictx/
  27. luciexe/
  28. mailer/
  29. milo/
  30. mmutex/
  31. provenance/
  32. resultdb/
  33. scheduler/
  34. scripts/
  35. server/
  36. standalone/
  37. starlark/
  38. swarming/
  39. teams/
  40. third_party/
  41. tokenserver/
  42. tools/
  43. tree_status/
  44. vpython/
  45. web/
  46. .gitallowed
  47. .gitattributes
  48. .gitignore
  49. .go-lintable
  50. AUTHORS
  51. codereview.settings
  52. CONTRIBUTING.md
  53. CONTRIBUTORS
  54. go.mod
  55. go.sum
  56. LICENSE
  57. OWNERS
  58. PRESUBMIT.py
  59. README.md
  60. tools.go
  61. WATCHLISTS
README.md

luci-go: LUCI services and tools in Go

GoReference

Installing

LUCI Go code is meant to be worked on from an Chromium infra.git checkout, which enforces packages versions and Go toolchain version. First get fetch via depot_tools.git then run:

fetch infra
cd infra/go
eval `./env.py`
cd src/go.chromium.org/luci

It is now possible to directly install tools with go install:

go install go.chromium.org/luci/auth/client/cmd/...@latest
go install go.chromium.org/luci/buildbucket/cmd/...@latest
go install go.chromium.org/luci/cipd/client/cmd/...@latest
go install go.chromium.org/luci/client/cmd/...@latest
go install go.chromium.org/luci/cv/cmd/...@latest
go install go.chromium.org/luci/gce/cmd/...@latest
go install go.chromium.org/luci/grpc/cmd/...@latest
go install go.chromium.org/luci/logdog/client/cmd/...@latest
go install go.chromium.org/luci/luci_notify/cmd/...@latest
go install go.chromium.org/luci/lucicfg/cmd/...@latest
go install go.chromium.org/luci/luciexe/legacy/cmd/...@latest
go install go.chromium.org/luci/mailer/cmd/...@latest
go install go.chromium.org/luci/mmutex/cmd/...@latest
go install go.chromium.org/luci/resultdb/cmd/...@latest
go install go.chromium.org/luci/server/cmd/...@latest
go install go.chromium.org/luci/swarming/cmd/...@latest
go install go.chromium.org/luci/tokenserver/cmd/...@latest
go install go.chromium.org/luci/tools/cmd/...@latest

Contributing

Contributing uses the same flow as Chromium contributions.