[NET-3024] Configure GitHub Actions (#544)

* bootstrap github actions Signed-off-by: Dan Bond <danbond@protonmail.com> * master -> main Signed-off-by: Dan Bond <danbond@protonmail.com> * go fmt Signed-off-by: Dan Bond <danbond@protonmail.com> * fix go vet issues Signed-off-by: Dan Bond <danbond@protonmail.com> * add 386 support Signed-off-by: Dan Bond <danbond@protonmail.com> * add go1.19 Signed-off-by: Dan Bond <danbond@protonmail.com> * revert integ test Signed-off-by: Dan Bond <danbond@protonmail.com> * x86 -> x32 Signed-off-by: Dan Bond <danbond@protonmail.com> * install multilib Signed-off-by: Dan Bond <danbond@protonmail.com> * only use go.mod version Signed-off-by: Dan Bond <danbond@protonmail.com> * arch specific builds Signed-off-by: Dan Bond <danbond@protonmail.com> * fix run error Signed-off-by: Dan Bond <danbond@protonmail.com> * fix if logic Signed-off-by: Dan Bond <danbond@protonmail.com> * INTEG_TESTS: yes Signed-off-by: Dan Bond <danbond@protonmail.com> * remove circle config Signed-off-by: Dan Bond <danbond@protonmail.com> * pin actions versions Signed-off-by: Dan Bond <danbond@protonmail.com> * build last 2 versions of go Signed-off-by: Dan Bond <danbond@protonmail.com> * fix typo Signed-off-by: Dan Bond <danbond@protonmail.com> * add permissions Signed-off-by: Dan Bond <danbond@protonmail.com> --------- Signed-off-by: Dan Bond <danbond@protonmail.com>
hashicorp · Mar 14, 2023 · 7719ff6 · 7719ff6
1 parent 0fc4f86
commit 7719ff6
Show file tree

Hide file tree

Showing 8 changed files with 206 additions and 209 deletions.
diff --git a/.circleci/config.yml b/.circleci/config.yml
diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
@@ -0,0 +1,4 @@
+* @hashicorp/consul-core-reviewers
+
+/.release/                           @hashicorp/release-engineering
+/.github/workflows/ci.yml            @hashicorp/release-engineering
diff --git a/.github/dependabot.yml b/.github/dependabot.yml
@@ -0,0 +1,7 @@
+version: 2
+
+updates:
+  - package-ecosystem: "gomod"
+    directory: "/"
+    schedule:
+      interval: "weekly"
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -0,0 +1,56 @@
+name: ci
+
+on:
+  pull_request:
+    branches: ["main"]
+  push:
+    branches: ["main"]
+    tags: ["*"]
+
+permissions:
+  contents: read
+
+jobs:
+  go-fmt-and-vet:
+    runs-on: ubuntu-22.04
+    steps:
+    - uses: actions/checkout@ac593985615ec2ede58e132d2e21d2b1cbd6127c # pin@v3.3.0
+    - uses: actions/setup-go@6edd4406fa81c3da01a34fa6f6343087c207a568 # pin@v3.5.0
+      with:
+        go-version: '1.20'
+        cache: true
+    - run: |
+        files=$(go fmt ./...)
+        if [ -n "$files" ]; then
+          echo "The following file(s) do not conform to go fmt:"
+          echo "$files"
+          exit 1
+        fi
+    - run: |
+        PACKAGE_NAMES=$(go list ./... | grep -v github.com/hashicorp/raft/fuzzy)
+        go vet $PACKAGE_NAMES
+
+  go-test:
+    needs: go-fmt-and-vet
+    strategy:
+      matrix:
+        go: ['1.19', '1.20']
+        arch: ['x32', 'x64']
+    runs-on: ubuntu-22.04
+    env:
+      INTEG_TESTS: yes
+    steps:
+    - uses: actions/checkout@ac593985615ec2ede58e132d2e21d2b1cbd6127c # pin@v3.3.0
+    - uses: actions/setup-go@6edd4406fa81c3da01a34fa6f6343087c207a568 # pin@v3.5.0
+      with:
+        go-version: ${{ matrix.go }}
+        architecture: ${{ matrix.arch }}
+        cache: true
+    # x86 specific build.
+    - if: matrix.arch == 'x32'
+      run: |
+        sudo apt-get install gcc-multilib
+        go test --tags batchtest ./...
+    # x86-64 specific build.
+    - if: matrix.arch == 'x64'
+      run: go test -race --tags batchtest ./...
diff --git a/README.md b/README.md
@@ -1,4 +1,4 @@
-raft [![CircleCI](https://circleci.com/gh/hashicorp/raft.svg?style=svg)](https://circleci.com/gh/hashicorp/raft)
+raft [![Build Status](https://github.com/hashicorp/raft/workflows/ci/badge.svg)](https://github.com/hashicorp/raft/actions)
 ====
 
 raft is a [Go](http://www.golang.org) library that manages a replicated

diff --git a/config.go b/config.go
@@ -28,67 +28,74 @@ import (
 // The version details are complicated, but here's a summary of what's required
 // to get from a version 0 cluster to version 3:
 //
-// 1. In version N of your app that starts using the new Raft library with
-//    versioning, set ProtocolVersion to 1.
-// 2. Make version N+1 of your app require version N as a prerequisite (all
-//    servers must be upgraded). For version N+1 of your app set ProtocolVersion
-//    to 2.
-// 3. Similarly, make version N+2 of your app require version N+1 as a
-//    prerequisite. For version N+2 of your app, set ProtocolVersion to 3.
+//  1. In version N of your app that starts using the new Raft library with
+//     versioning, set ProtocolVersion to 1.
+//  2. Make version N+1 of your app require version N as a prerequisite (all
+//     servers must be upgraded). For version N+1 of your app set ProtocolVersion
+//     to 2.
+//  3. Similarly, make version N+2 of your app require version N+1 as a
+//     prerequisite. For version N+2 of your app, set ProtocolVersion to 3.
 //
 // During this upgrade, older cluster members will still have Server IDs equal
 // to their network addresses. To upgrade an older member and give it an ID, it
 // needs to leave the cluster and re-enter:
 //
-// 1. Remove the server from the cluster with RemoveServer, using its network
-//    address as its ServerID.
-// 2. Update the server's config to use a UUID or something else that is
-//	  not tied to the machine as the ServerID (restarting the server).
-// 3. Add the server back to the cluster with AddVoter, using its new ID.
+//  1. Remove the server from the cluster with RemoveServer, using its network
+//     address as its ServerID.
+//  2. Update the server's config to use a UUID or something else that is
+//     not tied to the machine as the ServerID (restarting the server).
+//  3. Add the server back to the cluster with AddVoter, using its new ID.
 //
 // You can do this during the rolling upgrade from N+1 to N+2 of your app, or
 // as a rolling change at any time after the upgrade.
 //
-// Version History
+// # Version History
 //
 // 0: Original Raft library before versioning was added. Servers running this
-//    version of the Raft library use AddPeerDeprecated/RemovePeerDeprecated
-//    for all configuration changes, and have no support for LogConfiguration.
+//
+//	version of the Raft library use AddPeerDeprecated/RemovePeerDeprecated
+//	for all configuration changes, and have no support for LogConfiguration.
+//
 // 1: First versioned protocol, used to interoperate with old servers, and begin
-//    the migration path to newer versions of the protocol. Under this version
-//    all configuration changes are propagated using the now-deprecated
-//    RemovePeerDeprecated Raft log entry. This means that server IDs are always
-//    set to be the same as the server addresses (since the old log entry type
-//    cannot transmit an ID), and only AddPeer/RemovePeer APIs are supported.
-//    Servers running this version of the protocol can understand the new
-//    LogConfiguration Raft log entry but will never generate one so they can
-//    remain compatible with version 0 Raft servers in the cluster.
+//
+//	the migration path to newer versions of the protocol. Under this version
+//	all configuration changes are propagated using the now-deprecated
+//	RemovePeerDeprecated Raft log entry. This means that server IDs are always
+//	set to be the same as the server addresses (since the old log entry type
+//	cannot transmit an ID), and only AddPeer/RemovePeer APIs are supported.
+//	Servers running this version of the protocol can understand the new
+//	LogConfiguration Raft log entry but will never generate one so they can
+//	remain compatible with version 0 Raft servers in the cluster.
+//
 // 2: Transitional protocol used when migrating an existing cluster to the new
-//    server ID system. Server IDs are still set to be the same as server
-//    addresses, but all configuration changes are propagated using the new
-//    LogConfiguration Raft log entry type, which can carry full ID information.
-//    This version supports the old AddPeer/RemovePeer APIs as well as the new
-//    ID-based AddVoter/RemoveServer APIs which should be used when adding
-//    version 3 servers to the cluster later. This version sheds all
-//    interoperability with version 0 servers, but can interoperate with newer
-//    Raft servers running with protocol version 1 since they can understand the
-//    new LogConfiguration Raft log entry, and this version can still understand
-//    their RemovePeerDeprecated Raft log entries. We need this protocol version
-//    as an intermediate step between 1 and 3 so that servers will propagate the
-//    ID information that will come from newly-added (or -rolled) servers using
-//    protocol version 3, but since they are still using their address-based IDs
-//    from the previous step they will still be able to track commitments and
-//    their own voting status properly. If we skipped this step, servers would
-//    be started with their new IDs, but they wouldn't see themselves in the old
-//    address-based configuration, so none of the servers would think they had a
-//    vote.
+//
+//	server ID system. Server IDs are still set to be the same as server
+//	addresses, but all configuration changes are propagated using the new
+//	LogConfiguration Raft log entry type, which can carry full ID information.
+//	This version supports the old AddPeer/RemovePeer APIs as well as the new
+//	ID-based AddVoter/RemoveServer APIs which should be used when adding
+//	version 3 servers to the cluster later. This version sheds all
+//	interoperability with version 0 servers, but can interoperate with newer
+//	Raft servers running with protocol version 1 since they can understand the
+//	new LogConfiguration Raft log entry, and this version can still understand
+//	their RemovePeerDeprecated Raft log entries. We need this protocol version
+//	as an intermediate step between 1 and 3 so that servers will propagate the
+//	ID information that will come from newly-added (or -rolled) servers using
+//	protocol version 3, but since they are still using their address-based IDs
+//	from the previous step they will still be able to track commitments and
+//	their own voting status properly. If we skipped this step, servers would
+//	be started with their new IDs, but they wouldn't see themselves in the old
+//	address-based configuration, so none of the servers would think they had a
+//	vote.
+//
 // 3: Protocol adding full support for server IDs and new ID-based server APIs
-//    (AddVoter, AddNonvoter, etc.), old AddPeer/RemovePeer APIs are no longer
-//    supported. Version 2 servers should be swapped out by removing them from
-//    the cluster one-by-one and re-adding them with updated configuration for
-//    this protocol version, along with their server ID. The remove/add cycle
-//    is required to populate their server ID. Note that removing must be done
-//    by ID, which will be the old server's address.
+//
+//	(AddVoter, AddNonvoter, etc.), old AddPeer/RemovePeer APIs are no longer
+//	supported. Version 2 servers should be swapped out by removing them from
+//	the cluster one-by-one and re-adding them with updated configuration for
+//	this protocol version, along with their server ID. The remove/add cycle
+//	is required to populate their server ID. Note that removing must be done
+//	by ID, which will be the old server's address.
 type ProtocolVersion int
 
 const (
@@ -102,19 +109,22 @@ const (
 // Currently, it is always assumed that the server generates the latest version,
 // though this may be changed in the future to include a configurable version.
 //
-// Version History
+// # Version History
 //
 // 0: Original Raft library before versioning was added. The peers portion of
-//    these snapshots is encoded in the legacy format which requires decodePeers
-//    to parse. This version of snapshots should only be produced by the
-//    unversioned Raft library.
+//
+//	these snapshots is encoded in the legacy format which requires decodePeers
+//	to parse. This version of snapshots should only be produced by the
+//	unversioned Raft library.
+//
 // 1: New format which adds support for a full configuration structure and its
-//    associated log index, with support for server IDs and non-voting server
-//    modes. To ease upgrades, this also includes the legacy peers structure but
-//    that will never be used by servers that understand version 1 snapshots.
-//    Since the original Raft library didn't enforce any versioning, we must
-//    include the legacy peers structure for this version, but we can deprecate
-//    it in the next snapshot version.
+//
+//	associated log index, with support for server IDs and non-voting server
+//	modes. To ease upgrades, this also includes the legacy peers structure but
+//	that will never be used by servers that understand version 1 snapshots.
+//	Since the original Raft library didn't enforce any versioning, we must
+//	include the legacy peers structure for this version, but we can deprecate
+//	it in the next snapshot version.
 type SnapshotVersion int
 
 const (

diff --git a/net_transport.go b/net_transport.go
@@ -50,25 +50,21 @@ var (
 	ErrPipelineShutdown = errors.New("append pipeline closed")
 )
 
-/*
-
-NetworkTransport provides a network based transport that can be
-used to communicate with Raft on remote machines. It requires
-an underlying stream layer to provide a stream abstraction, which can
-be simple TCP, TLS, etc.
-
-This transport is very simple and lightweight. Each RPC request is
-framed by sending a byte that indicates the message type, followed
-by the MsgPack encoded request.
-
-The response is an error string followed by the response object,
-both are encoded using MsgPack.
-
-InstallSnapshot is special, in that after the RPC request we stream
-the entire state. That socket is not re-used as the connection state
-is not known if there is an error.
-
-*/
+// NetworkTransport provides a network based transport that can be
+// used to communicate with Raft on remote machines. It requires
+// an underlying stream layer to provide a stream abstraction, which can
+// be simple TCP, TLS, etc.
+//
+// This transport is very simple and lightweight. Each RPC request is
+// framed by sending a byte that indicates the message type, followed
+// by the MsgPack encoded request.
+//
+// The response is an error string followed by the response object,
+// both are encoded using MsgPack.
+//
+// InstallSnapshot is special, in that after the RPC request we stream
+// the entire state. That socket is not re-used as the connection state
+// is not known if there is an error.
 type NetworkTransport struct {
 	connPool     map[ServerAddress][]*netConn
 	connPoolLock sync.Mutex