[Merged by Bors] - Add listener that allows remote connections without mTLS #5418

fasmat · 2024-01-09T20:39:19Z

Motivation

Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS.

Changes

add new grpcPostServer that allows remote connection to a post service without setting up mTLS
- Post is now available on grpcPostServer (default: 0.0.0.0:9094) to allow exposing it without mTLS and
- on grpcTLSServer (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future)
GRPC services are now true singletons - simplified code to instantiate and register in node.go during startup
updated GRPC PostService to allow connections from multiple post services. (prep. work for multiple smeshers)
- nipostBuilder / atxBuilder can select the required client based on the node Id the post service reports after connecting
- only one post service can connect per Node ID
Merged similar functionality of grpc.NewPublic and grpc.NewPrivate into one grpc.NewWithServices
- function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks
Expanded system tests to automatically add nodes with remote smeshing setups to all tests.
- By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node)
- The node running the post service has an init container where postcli is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the smesherConfig that is deployed with every node and translated into parameters for postcli / post-service
- systest Makefile has been updated with image names and tags for post-service and postcli
- systest Dockerfile has been expanded to include libpost. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs)
Fixed a few minor issues with existing system tests
- tests now generate the same number of keys as nodes are used during the test (1 per node)
- AddBootnodes didn't keep track of the correct number of bootnodes after deployment

Test Plan

Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service.

TODO

Explain motivation or link existing issue(s)
Test changes and document test plan
Update documentation as needed
Update changelog as needed

codecov · 2024-01-09T20:48:56Z

Codecov Report

Attention: 42 lines in your changes are missing coverage. Please review.

Comparison is base (4b0d356) 77.6% compared to head (b3eaede) 77.6%.

Files	Patch %	Lines
node/node.go	77.3%	15 Missing and 11 partials ⚠️
api/grpcserver/post_service.go	58.8%	8 Missing and 6 partials ⚠️
api/grpcserver/grpc.go	75.0%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5418     +/-   ##
=========================================
- Coverage     77.6%   77.6%   -0.1%     
=========================================
  Files          267     267             
  Lines        30976   31059     +83     
=========================================
+ Hits         24067   24109     +42     
- Misses        5393    5421     +28     
- Partials      1516    1529     +13

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

api/grpcserver/config.go

cmd/root.go

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-22T11:27:47Z

Build failed:

ci-status

fasmat · 2024-01-22T12:48:08Z

bors merge

spacemesh-bors · 2024-01-22T13:04:26Z

Merge conflict.

…without-tls

fasmat · 2024-01-22T13:12:34Z

bors merge

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-22T14:53:21Z

Build failed (retrying...):

systest-status

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-22T16:04:29Z

Build failed:

systest-status

fasmat · 2024-01-22T16:39:00Z

grpc disconnects in TestPartition_30_70

bors merge

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-22T17:15:27Z

Build failed:

ci-status

fasmat · 2024-01-22T19:21:41Z

bors merge

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-22T21:58:19Z

Build failed:

systest-status

…without-tls

fasmat · 2024-01-22T22:51:59Z

bors merge

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-22T23:22:13Z

Build failed:

systest-status

fasmat · 2024-01-22T23:47:15Z

bors merge

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-23T00:33:45Z

Build failed:

systest-status

fasmat · 2024-01-23T00:40:54Z

bors merge

## Motivation Adds a new listener to allow remote post services to connect if they are within the same private network without having to setup mTLS. ## Changes - add new `grpcPostServer` that allows remote connection to a post service without setting up mTLS - Post is now available on `grpcPostServer` (default: 0.0.0.0:9094) to allow exposing it without mTLS and - on `grpcTLSServer` (no default listening address) to allow exposing over insecure networks (to allow transmitting keys securely between node and post service in the future) - GRPC services are now true singletons - simplified code to instantiate and register in `node.go` during startup - updated GRPC `PostService` to allow connections from multiple post services. (prep. work for multiple smeshers) - `nipostBuilder` / `atxBuilder` can select the required client based on the node Id the post service reports after connecting - only one post service can connect per Node ID - Merged similar functionality of `grpc.NewPublic` and `grpc.NewPrivate` into one `grpc.NewWithServices` - function checks if listening IP is in a public network and prints a waring (displayed during startup) to ensure to be careful not to expose it over public networks - Expanded system tests to automatically add nodes with remote smeshing setups to all tests. - By default 25% of all nodes will be deployed in a remote setup (i.e. with a separate pod running the post service remotely and connecting to the node) - The node running the post service has an init container where `postcli` is used to create the post data with the same setting as the node would use in a supervised setup. Those settings are picked from the `smesherConfig` that is deployed with every node and translated into parameters for `postcli` / `post-service` - systest Makefile has been updated with image names and tags for `post-service` and `postcli` - systest Dockerfile has been expanded to include `libpost`. This has unfortunately become necessary to parse the config used during system tests with the same code as we use during the startup of the node (to ensure compatibility with changing configs) - Fixed a few minor issues with existing system tests - tests now generate the same number of keys as nodes are used during the test (1 per node) - `AddBootnodes` didn't keep track of the correct number of bootnodes after deployment ## Test Plan - Extended existing system tests to deploy 1/4 of the nodes during the test with a remote post service. ## TODO  - [x] Explain motivation or link existing issue(s) - [x] Test changes and document test plan - [x] Update documentation as needed - [x] Update [changelog](../CHANGELOG.md) as needed

spacemesh-bors · 2024-01-23T02:18:32Z

Pull request successfully merged into develop.

Build succeeded:

fasmat self-assigned this Jan 9, 2024

fasmat force-pushed the allow-remote-post-without-tls branch 2 times, most recently from e281bdd to 0110842 Compare January 11, 2024 13:30

fasmat marked this pull request as ready for review January 11, 2024 15:47

fasmat requested review from dshulyak, poszu and ivan4th as code owners January 11, 2024 15:47

fasmat force-pushed the allow-remote-post-without-tls branch 4 times, most recently from a130f9f to 2e17094 Compare January 15, 2024 16:07

poszu reviewed Jan 16, 2024

View reviewed changes

api/grpcserver/config.go Show resolved Hide resolved

cmd/root.go Outdated Show resolved Hide resolved

fasmat force-pushed the allow-remote-post-without-tls branch 2 times, most recently from 787fabb to 9c8fdac Compare January 17, 2024 09:49

fasmat added 15 commits January 17, 2024 11:27

Add listener that allows remote connections without mTLS

938a097

Use dedicated endpoint for post

890d3b9

Expose TLS services list

13e254f

Improve unit test

accab5a

Add remote smeshers to system tests WiP

f08ed86

Get post services deployed and initialized

cde4035

Extend system test runner with dependencies for go-spacemesh

799809c

Add post_init_image to Makefile

543c70d

Fix formatting README.md

4acf76c

Expose nodes using remote service with a k8s service

6652868

Improve description of post listener

127763d

Add log for debugging

7a2f2b5

Try possible fix for resizing clusters

2e5b799

Fix rediscovery post services

c9d31f8

Add info about nodeId connecting

d882840

Merge remote-tracking branch 'origin/develop' into allow-remote-post-…

92a1eaa

…without-tls

fasmat force-pushed the allow-remote-post-without-tls branch from 0d153e9 to 92a1eaa Compare January 22, 2024 13:11

Merge remote-tracking branch 'origin/develop' into allow-remote-post-…

b3eaede

…without-tls

spacemesh-bors bot changed the title ~~Add listener that allows remote connections without mTLS~~ [Merged by Bors] - Add listener that allows remote connections without mTLS Jan 23, 2024

spacemesh-bors bot closed this Jan 23, 2024

spacemesh-bors bot deleted the allow-remote-post-without-tls branch January 23, 2024 02:18

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Merged by Bors] - Add listener that allows remote connections without mTLS #5418

[Merged by Bors] - Add listener that allows remote connections without mTLS #5418

fasmat commented Jan 9, 2024 •

edited

Loading

codecov bot commented Jan 9, 2024 •

edited

Loading

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 23, 2024

fasmat commented Jan 23, 2024

spacemesh-bors bot commented Jan 23, 2024

[Merged by Bors] - Add listener that allows remote connections without mTLS #5418

[Merged by Bors] - Add listener that allows remote connections without mTLS #5418

Conversation

fasmat commented Jan 9, 2024 • edited Loading

Motivation

Changes

Test Plan

TODO

codecov bot commented Jan 9, 2024 • edited Loading

Codecov Report

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 22, 2024

fasmat commented Jan 22, 2024

spacemesh-bors bot commented Jan 23, 2024

fasmat commented Jan 23, 2024

spacemesh-bors bot commented Jan 23, 2024

fasmat commented Jan 9, 2024 •

edited

Loading

codecov bot commented Jan 9, 2024 •

edited

Loading