This commit optimizes Docker cache mounting for the linter with a
CI-aware strategy:
**Local development (macOS/Windows)**: Uses Docker named volumes which
keep data inside Docker's native Linux filesystem, avoiding the slow
host-syncing overhead of bind mounts. This yields ~21x faster linting
on warm cache.
**CI (GitHub Actions)**: Uses bind mounts to host paths (`~/.cache/go-build`,
`~/go/pkg/mod`) that GitHub Actions already caches via the setup-go
action. This ensures CI benefits from cached dependencies across runs.
The Makefile detects CI mode via the `CI` environment variable that
GitHub Actions sets automatically.
Local benchmark results:
- Cold run (empty cache): ~2m 28s
- Warm run (cached): ~11s (~21x faster)
Key improvements in warm runs:
- Go packages loading: 1m 58s → 5.6s
- Linters execution: 20.5s → 2.7s
- Total execution: 2m 20s → 8.6s
This commit adds a script to hunt flakes for a specific unit test with
trace logs. Also rename the make commands to make them more clear on
whether it's a unit test, itest, or paralleled itest.
This commit adds a new flag to shuffle all the test cases before running
them so tests which require lots of blocks to be mined are less likely
to be run in the same tranch.
The other benefit is this approach provides a more efficient way to
figure which tests are broken since all the differnet backends are
running different tranches in their builds, we can identify more failed
tests in one push.
Add this file both to the main LND directory so that devs can use it for
local linter runs and also add it to the `tools` directory so that the
docker environment used to run the linter in CI has access to it. A
custom linter binary can be built via `golangci-lint custom`. This will
pull in and register all the plugins listed in the new config file when
building the new binary. The new binary can then be run using
`custom-gcl run`.
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.
ziggie