This commit updates `scripts/release.sh` to include a check for the
correct Go version before executing the release build. This ensures that
the release binaries are built with the specified Go version,
maintaining consistency and integrity for developer signatures.
Implemented linter scripts to ensure consistency of the Go version
specified in Dockerfiles and YAML files. These scripts verify that the
Go version used across these files is uniform, enhancing maintainability
and reducing configuration errors.
This commit also introduces a `GO_VERSION` Makefile variable to control
the Go version used throughout the project.
Renamed the Makefile variable `GO_VERSION` to `ACTIVE_GO_VERSION` for
improved clarity. This change also frees up the name `GO_VERSION` to be
used for defining the global Go version for reproducible binaries in a
subsequent commit.
Add a new `make install-all` command that will perform all `make
install` actions along with generating the manpages. The `manpages`
command is then removed from the existing `make install` command. The
docker build is then updated to use the new `make install-all` command.
This is done because some users running `make install` may be doing so
in environments where they do not have write access to the directory
where the man pages need to be written to.
This commit gives the linter container access to the local machine's
build and module cache, drastically decreasing the run time of
subsequent linter runs (no difference on first run with this change).
This PR addresses the following:
- Install and Configure protolint to enforce the protobuf style guide rules in the CI.
- Fix the protolinting issues (package and import ordering) while maintaining the comaptibility.
In this commit, [we prep for some upcoming changes in
Go](https://go.dev/blog/loopvar-preview) by running our tests with
`GOEXPERIMENT=loopvar`. This changes the loop semantics to fix a common
bug where a scoping issue causes a variable to be re-used, which can
cause unintended bugs down the line.
If everything passes with this flag on, then we can keep it on, and also
rest a bit easier knowing that the compiler will fix a class of bugs
that would previously pop up for us.
When one of the itest tranches fails, because we are running tests in
parallel, other tranches will still be running, which caused 7z to fail
at zipping the logs because race reads. This commit fixes it by making
sure we are waiting other tranches to finish before moving to zipping
and uploading the logs.
sqlc is a tool that generates fully type-safe idiomatic code from SQL.
The result is Go code can then used execute the queries in the database.
The noraml flow looks like:
- The developer write some sql that will update the schema in the
database: new tables, indices, etc
- The developer updates the set of queries that will use the new schema.
- `sqlc` generates type-safe interfaces to those queries.
- The developer can then write application code that calls the methods
generated by sqlc.
The tool configuration needs to live in the repo's root and its name is
`sqlc.yaml`.
LND will support out of the box sqlite and postgres. The sql code needs to
be (almost) the same for both engines, so we cannot use custom functions
like `ANY` in postgres.
The SQLC config file needs to define what is the target engine, we will
set postgres but the generated code can be executed by sqlite too.
In some specific cases, we will `match and replace` some sql lines to be
sure the table definitions are valid for the targeted engine.
Currently `make lint` creates a new container each time it runs. We can
automatically delete these containers once linting is done by using the
--rm flag.
This commit adds a new build tag `integration` and removes the old tag
`rpctest` for clarity. Multiple unnecessary usages of `build !rpctest`
is also removed.
Since `go1.18` the runtime has a package that provides information about module
versions, version control information, and build flags embedded in executable
files built by the go command.
The new packages allows us to get information needed by the `version` command
without having to rely on `ldflags` set at build time.
This can be really helpful while debugging errors from people using custom
binaries. For example a build from master.
`rpc-check` is used in our CI pipeline to detect any difference
between the committed and the automatically generated rpc files.
Unfortunately, the current method only detects changes in the
already existing files and won't fail if `make rpc` generates
a totally new file.
`git status --porcelain` makes the trick, it returns a line for
each file that has been modified, created or deleted.
Instead of hard coding a commit to use for a binary tool that we use
during the build process, we now only use "go install" to install the
binaries and the golang builtin versioning system to pin the exact
version/commit we want to use in go.mod.
