Skip to content

Commit 05343e9

Browse files
Merge pull request #538 from HeavyWombat/fix/go-card-warnings
Fix some of the Go Report Card findings
2 parents 9393625 + 23f5763 commit 05343e9

File tree

18 files changed

+115
-90
lines changed

18 files changed

+115
-90
lines changed

Makefile

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -152,6 +152,39 @@ install-counterfeiter:
152152
install-operator-sdk:
153153
hack/install-operator-sdk.sh
154154

155+
.PHONY: govet
156+
govet:
157+
@echo "Checking go vet"
158+
@go vet ./...
159+
160+
# Install it via: go get -u github.com/gordonklaus/ineffassign
161+
.PHONY: ineffassign
162+
ineffassign:
163+
@echo "Checking ineffassign"
164+
@ineffassign ./...
165+
166+
# Install it via: go get -u golang.org/x/lint/golint
167+
# See https://github.com/golang/lint/issues/320 for details regarding the grep
168+
.PHONY: golint
169+
golint:
170+
@echo "Checking golint"
171+
@go list ./... | grep -v -e /vendor -e /test | xargs -L1 golint -set_exit_status
172+
173+
# Install it via: go get -u github.com/client9/misspell/cmd/misspell
174+
.PHONY: misspell
175+
misspell:
176+
@echo "Checking misspell"
177+
@find . -type f | grep -v /vendor | xargs misspell -source=text -error
178+
179+
# Install it via: go get -u honnef.co/go/tools/cmd/staticcheck
180+
.PHONY: staticcheck
181+
staticcheck:
182+
@echo "Checking staticcheck"
183+
@go list ./... | grep -v /test | xargs staticcheck
184+
185+
.PHONY: sanity-check
186+
sanity-check: ineffassign golint govet misspell staticcheck
187+
155188
# https://github.com/shipwright-io/build/issues/123
156189
test: test-unit
157190

docs/build.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ A `Build` resource can specify a Git source, together with other parameters like
7171

7272
By default, the Build controller will validate that the Git repository exists. If the validation is not desired, users can define the `build.build.dev/verify.repository` annotation with `false`. For example:
7373

74-
Example of a `Build` with the **build.build.dev/verify.repository** annotation, in order to disbale the `spec.source.url` validation.
74+
Example of a `Build` with the **build.build.dev/verify.repository** annotation, in order to disable the `spec.source.url` validation.
7575

7676
```yaml
7777
apiVersion: build.dev/v1alpha1

docs/development/testing.md

Lines changed: 11 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -45,6 +45,16 @@ This allow us to use test doubles in the unit tests, from where we can instantia
4545

4646
Counterfeiter is required by the code generator scripts. Run `make install-counterfeiter` to add counterfeiter to your `GOPATH`.
4747

48+
### Static code analysis and linting
49+
50+
Run `make sanity-check` to run a collection of static code analyser and linters to check the code for issues, for example ineffective assignments, unused variables, missing comments, misspellings and so on. Each check also has an individual Make target to check:
51+
52+
- `make govet` examines Go source code and reports suspicious constructs
53+
- `make ineffassign` checks Go source for variable assignments that are not used (i.e. overridden)
54+
- `make golint` runs a linter against the Go source
55+
- `make misspell` checks for TYPOs
56+
- `make staticcheck` performs more complex static code analysis to find unused code and other issues
57+
4858
## Unit Tests
4959

5060
We use unit tests to provide coverage and ensure that our functions are behaving as expected, but also to assert the behaviour of the controllers during Reconciliations.
@@ -95,7 +105,7 @@ make test-integration
95105

96106
## E2E Tests
97107

98-
We use e2e tests as the last signal to ensure the controllers behaviour in the cluster matches the developer specifications( _based on [e2e-tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md)_ ). During e2e tests execution, we don´t want to test any interaction between components but rather we want to simulate a normal user operation and ensure that images are succesfully build. E2E tests should only cover:
108+
We use e2e tests as the last signal to ensure the controllers behaviour in the cluster matches the developer specifications( _based on [e2e-tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/e2e-tests.md)_ ). During e2e tests execution, we don´t want to test any interaction between components but rather we want to simulate a normal user operation and ensure that images are successfully build. E2E tests should only cover:
99109

100110
- As the way to validate if the image was successfully build, only assert for a Succeeded Status on TaskRuns.
101111
- Testing should be around building images with different supported strategies, and different runtimes inside the strategies.
@@ -208,4 +218,3 @@ make test-e2e \
208218
TEST_PRIVATE_GITLAB="[email protected]:<youruser>/<your-repo>.git" \
209219
TEST_SOURCE_SECRET="<secret-name>"
210220
```
211-

docs/proposals/build-execution-using-build-run.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ spec:
3434
name: kaniko-golang-build
3535
```
3636
37-
The `BuildRun` API also provides a way to override/specify execution time information.
37+
The `BuildRun` API also provides a way to override/specify execution time information.
3838

3939
As an example, a `Build` configuration should not have to accurately specify the resource requirements - the information on resource requirements is valuable at build execution time which varies from environment to environment.
4040

@@ -73,7 +73,7 @@ As an example, the source code [nodejs-rest-http-crud](https://github.com/nodesh
7373
Note:
7474
In some scenarios, the source code 'revision' may not necessarily be deterministic as well, especially in case of builds triggered from PRs/forks.
7575

76-
### Deciding what should be overriden
76+
### Deciding what should be overridden
7777

7878
- Could the value of attribute X be reasonably determined at the time of `Build` configuration specification ?
7979
- Could the modification of attribute X reasonably compromise the integrity of the build ?
@@ -83,7 +83,7 @@ The above is a non-exhaustive list of questions that should help us modify the B
8383

8484
### Next steps / Consequences
8585

86-
Here's what it means to adopt this proposal:
86+
Here's what it means to adopt this proposal:
8787

8888
1. Make `spec.output` optional in `Build` API's `spec` .
8989
2. Introduce `spec.output` in the `BuildRun` API's `spec`.

docs/proposals/buildstrategy-steps-resources.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -54,8 +54,8 @@ there could be situations where containers under the same strategy required diff
5454

5555
## Motivation
5656

57-
For strategies with multiple steps like Buildpacks, not all the steps(_containers_) will require the same set of resources(_e.g. memory, cpu, etc_) values.
58-
In order to be able to manage situations where setting particular steps resources is required, we need a more flexible way to deal with N number of steps under the same strategy (_Build/ClusterBuildStrategy_). Also, we still need to help users to know that independently of the abstraction of the strategies, there are options for speeding up the builds. This options could be presented in the form of different `flavours` of the same strategy(_cluster or namespaced scope_), that differ between each other in terms of container resources values.
57+
For strategies with multiple steps like Buildpacks, not all the steps (_containers_) will require the same set of resources (_e.g. memory, cpu, etc_) values.
58+
In order to be able to manage situations where setting particular steps resources is required, we need a more flexible way to deal with N number of steps under the same strategy (_Build/ClusterBuildStrategy_). Also, we still need to help users to know that independently of the abstraction of the strategies, there are options for speeding up the builds. This options could be presented in the form of different `flavours` of the same strategy (_cluster or namespaced scope_), that differ between each other in terms of container resources values.
5959

6060
### Goals
6161

@@ -256,7 +256,7 @@ spec:
256256
### Risks and Mitigations
257257
258258
Proper documentation needs to be made to communicate the existence of `flavours` for strategies of the same type to users. When it comes to UI, is the decision of the UI team to decide
259-
how they will expose(_interface_) this flavours to their end-users. Strategy admins have full responsability on the flavours they decide to define, but recommendations of flavours should be
259+
how they will expose(_interface_) this flavours to their end-users. Strategy admins have full responsibility on the flavours they decide to define, but recommendations of flavours should be
260260
made for this repository.
261261

262262
## Design Details

docs/proposals/remote-artifacts.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -103,7 +103,7 @@ can extend the API to support arbitrary configuration.
103103
For the initial implementation, we will only support one git repository that is specified in
104104
`.spec.source`. Remote artifacts will be specified n `.spec.sources` only.
105105

106-
We will address supporting multipe Git repositories in a future enhancement proposal. This will
106+
We will address supporting multiple Git repositories in a future enhancement proposal. This will
107107
involve re-defining `/workspace/source` location and the `$workspace` placeholder.
108108

109109
## Steps and Helper

pkg/apis/core/v1alpha1/condition_types.go

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -127,6 +127,7 @@ type Status struct {
127127
Conditions Conditions `json:"conditions,omitempty" patchStrategy:"merge" patchMergeKey:"type"`
128128
}
129129

130+
// GetCondition returns the condition based on the type
130131
func (s *Status) GetCondition(t ConditionType) *Condition {
131132
for _, cond := range s.Conditions {
132133
if cond.Type == t {

pkg/controller/build/build_controller.go

Lines changed: 4 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -101,9 +101,11 @@ func add(ctx context.Context, mgr manager.Manager, r reconcile.Reconciler) error
101101

102102
// Watch for changes to primary resource Build
103103
err = c.Watch(&source.Kind{Type: &build.Build{}}, &handler.EnqueueRequestForObject{}, pred)
104+
if err != nil {
105+
return err
106+
}
104107

105108
preSecret := predicate.Funcs{
106-
107109
// Only filter events where the secret have the Build specific annotation
108110
CreateFunc: func(e event.CreateEvent) bool {
109111
objectAnnotations := e.Meta.GetAnnotations()
@@ -137,7 +139,7 @@ func add(ctx context.Context, mgr manager.Manager, r reconcile.Reconciler) error
137139
},
138140
}
139141

140-
err = c.Watch(&source.Kind{Type: &corev1.Secret{}}, &handler.EnqueueRequestsFromMapFunc{
142+
return c.Watch(&source.Kind{Type: &corev1.Secret{}}, &handler.EnqueueRequestsFromMapFunc{
141143
ToRequests: handler.ToRequestsFunc(func(o handler.MapObject) []reconcile.Request {
142144

143145
secret := o.Object.(*corev1.Secret)
@@ -190,12 +192,6 @@ func add(ctx context.Context, mgr manager.Manager, r reconcile.Reconciler) error
190192
return reconcileList
191193
}),
192194
}, preSecret)
193-
194-
if err != nil {
195-
return err
196-
}
197-
198-
return nil
199195
}
200196

201197
// blank assignment to verify that ReconcileBuild implements reconcile.Reconciler

pkg/controller/buildrun/buildrun_controller.go

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -306,7 +306,7 @@ func (r *ReconcileBuildRun) Reconcile(request reconcile.Request) (reconcile.Resu
306306
if err = r.client.Update(ctx, buildRun); err != nil {
307307
return reconcile.Result{}, err
308308
}
309-
ctxlog.Info(ctx, fmt.Sprintf("succesfully updated BuildRun %s", buildRun.Name), namespace, request.Namespace, name, request.Name)
309+
ctxlog.Info(ctx, fmt.Sprintf("successfully updated BuildRun %s", buildRun.Name), namespace, request.Namespace, name, request.Name)
310310
}
311311

312312
// Set the Build spec in the BuildRun status

pkg/controller/buildrun/generate_taskrun.go

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -51,6 +51,7 @@ func getStringTransformations(fullText string) string {
5151
return fullText
5252
}
5353

54+
// GenerateTaskSpec creates Tekton TaskRun spec to be used for a build run
5455
func GenerateTaskSpec(
5556
cfg *config.Config,
5657
build *buildv1alpha1.Build,
@@ -173,6 +174,7 @@ func GenerateTaskSpec(
173174
return &generatedTaskSpec, nil
174175
}
175176

177+
// GenerateTaskRun creates a Tekton TaskRun to be used for a build run
176178
func GenerateTaskRun(
177179
cfg *config.Config,
178180
build *buildv1alpha1.Build,

0 commit comments

Comments
 (0)