This allows users to see progress whenever the docker image is
[re]built, and (esp on non-linux hosts) track the size of the build
context being uploaded. Currently no output is displayed, so it's hard
to attribute the source of latency, e.g. network latency, building
layers, a large work directory, etc.
AFAICT it's not possible to flip back from bein synced_to_chain, so we
remove the underlying call that could reflect this. The method is moved
into the test file since it's still used to test correctness of other
portions of the flow.
Rather than performing this call in the SyncManager, we give each
gossipSyncer the ability to mark the first sync completed. This permits
pinned syncers to contribute towards the rpc-level synced_to_graph
value, allowing the value to be true after the first pinned syncer or
regular syncer complets. Unlinke regular syncers, pinned syncers can
proceed in parallel possibly decreasing the waiting time if consumers
rely on this field before proceeding to load their application.
A pinned syncer is an ActiveSyncer that is configured to always remain
active for the lifetime of the connection. Pinned syncers do not count
towards the total NumActiveSyncer count, which are rotated periodically.
This features allows nodes to more tightly synchronize their routing
tables by ensuring they are always receiving gossip from distinguished
subset of peers.
Because we now build a docker image for the RPC compilation, we can save
some execution minutes if we run the mobile RPC and code compilation check in the
same step of the CI workflow.
Now that we have a base docker image that has all our RPC compilation
dependencies installed, we can also run the mobile RPC compilation
there. This removes the need to install falafel and goimports on the
local machine.
Because we compile the REST code from the rest-annotations.yaml and no
longer import the annotations in the proto files, we don't need to
specify the custom import path anymore.
This commit aims to make it easier for developers to compile our
protobuf definitions. They now only need to have docker installed
instead of a whole set of binaries and libraries all pinned to very
specific versions.
When verifying the release signatures, we don't want to fail if a
signer's signature is not available in the gpg key ring. Instead we just
don't want to count the signature for now and still succeed if there's
at least one other good sig with a known key.
To avoid leaking any sensitive information like Docker Hub credentials
because of compromised actions repositories, we use our own, vendored
actions for all steps that potentially touch sensitive information.
