You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// If you want to add/modify an existing linter, please check out ruleguard's documentation: https://github.com/quasilyte/go-ruleguard#documentation
7
+
8
+
package gorules
9
+
10
+
import (
11
+
"github.com/quasilyte/go-ruleguard/dsl"
12
+
)
13
+
14
+
// This is a custom linter that checks ensures a use of require.Equal
15
+
funcEqualInsteadOfTrue(m dsl.Matcher) {
16
+
m.Match(`require.True($t, $x == $y, $*args)`).
17
+
Suggest(`require.Equal($t, $x, $y, $args)`).
18
+
Report(`use require.Equal instead of require.True`)
├── utility # Implementation of the Utility module
157
163
├── Makefile # [to-be-deleted] The source of targets used to develop, build and test
158
164
```
165
+
166
+
### Linters
167
+
168
+
We utilize `golangci-lint` to run the linters. It is a wrapper around a number of linters and is configured to run many at once. The linters are configured to run on every commit and pull request via CI, and all code issues are populated as GitHub annotations to let developers and reviewers easily locate an issue.
169
+
170
+
#### Installation of golangci-lint
171
+
172
+
Please follow the instructions on the [golangci-lint](https://golangci-lint.run/usage/install/#local-installation) website.
173
+
174
+
#### Running linters locally
175
+
176
+
You can run `golangci-lint` locally against all packages with:
177
+
178
+
```bash
179
+
make go_lint
180
+
```
181
+
182
+
If you need to specify any additional flags, you can run `golangci-lint` directly as it picks up the configuration from the `.golangci.yml` file.
183
+
184
+
#### VSCode Integration
185
+
186
+
`golangci-lint` has an integration with VSCode. Per [documentation](https://golangci-lint.run/usage/integrations/), recommended settings are:
187
+
188
+
```json
189
+
"go.lintTool":"golangci-lint",
190
+
"go.lintFlags": [
191
+
"--fast"
192
+
]
193
+
```
194
+
195
+
#### Configuration
196
+
197
+
`golangci-lint` is a sophisticated tool including both default and custom linters. The configuration file, which can grow quite large, is located at [`.golangci.yml`](../../.golangci.yml).
198
+
199
+
The official documentation includes a list of different linters and their configuration options. Please refer to [this page](https://golangci-lint.run/usage/linters/) for more information.
200
+
201
+
#### Custom linters
202
+
203
+
We can write custom linters using [`go-ruleguard`](https://go-ruleguard.github.io/). The rules are located in the [`build/linters`](../../build/linters) directory. The rules are written in the [Ruleguard DSL](https://github.com/quasilyte/go-ruleguard/blob/master/_docs/dsl.md), if you've never worked with ruleguard in the past, it makes sense to go through [introduction article](https://quasilyte.dev/blog/post/ruleguard/) and [Ruleguard by example tour](https://go-ruleguard.github.io/by-example/).
204
+
205
+
Ruleguard is run via `gocritic` linter which is a part of `golangci-lint`, so if you wish to change configuration or debug a particular rule, you can modify the `.golangci.yml` file.
We follow Go's [Module Version Numbering](https://go.dev/doc/modules/version-numbers) for software releases along with typical [Software release life cycles](https://en.wikipedia.org/wiki/Software_release_life_cycle).
14
+
15
+
For example, `v0.0.1-alpha.pre.1` is the tag used for the first milestone merge and `v0.0.1-alpha.1` can be used for the first official alpha release.
16
+
17
+
## [WIP] Build Versioning
18
+
19
+
Automatic development / test / production builds are still a work in progress, but we plan to incorporate the following when we reach that point:
20
+
21
+
-`+dirty` for uncommited changes
22
+
-`-version` flag that can be injected or defaults to `UNKNOWN`
23
+
-`branch_name` and a shortened `commit_hash` should be included
24
+
25
+
For example, `X.Y.Z[-<pre_release_tag][+branch_name][+short_hash][+dirty]` is the name of a potential build we will release in the future.
26
+
27
+
## Container Images
28
+
29
+
Our images are hosted on Github's Container Registry (GHCR) and are available at `ghcr.io/poktnetwork/pocket-v1`. You can find the list of latest images [here](https://github.com/pokt-network/pocket/pkgs/container/pocket-v1).
30
+
31
+
### Tags
32
+
33
+
Code built from the default branch (i.e. `main`) is tagged as `latest`.
34
+
35
+
Code built from commits in Pull Requests, is tagged as `pr-<number>`, as well as `sha-<7 digit sha>`.
36
+
37
+
Once releases are managed, they will be tagged with the version number (e.g. `v0.0.1-alpha.pre.1`).
38
+
39
+
### Extended images with additional tooling
40
+
41
+
Extended images with additional tooling are built to aid in troubleshoot and debugging. The extended image is formatted as `<tag>-dev`. For example, `latest-dev`, or `pr-123-dev`.
42
+
43
+
## [TODO] Magefile build system
44
+
45
+
Once the V1 implementation reaches the stage of testable binaries, we are looking to use [Mage](https://magefile.org/) which is being tracked in [pocket/issues/43](https://github.com/pokt-network/pocket/issues/43) that'll inject a version with the `-version` flag.
0 commit comments