Skip to content

Add goimports verification and skeleton ci presubmit check#4710

Merged
jetstack-bot merged 1 commit intocert-manager:masterfrom
SgtCoDFish:goimports
Jan 6, 2022
Merged

Add goimports verification and skeleton ci presubmit check#4710
jetstack-bot merged 1 commit intocert-manager:masterfrom
SgtCoDFish:goimports

Conversation

@SgtCoDFish
Copy link
Copy Markdown
Member

This adds a step by which we can run goimports against the codebase.

It's also the first part of moving "testing" more generally from bazel to make. A lot of the existing steps are tied to bazel in some way, but since this is greenfield it's an easy place to start.

After this merges, we can add make -f make/Makefile ci-presubmit to the presubmits.

Sort-of related to #4705

/kind feature

Add goimports verification step for CI

@jetstack-bot jetstack-bot added kind/feature Categorizes issue or PR as related to a new feature. release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates that all commits in the pull request have the valid DCO sign-off message. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jan 5, 2022
@jetstack-bot
Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SgtCoDFish

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jetstack-bot jetstack-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 5, 2022

.PHONY: tools
tools: bin/tools/helm bin/tools/kubectl bin/tools/kind bin/tools/cosign bin/tools/release-notes bin/tools/cmrel bin/tools/ytt bin/tools/yq
tools: bin/tools/helm bin/tools/kubectl bin/tools/kind bin/tools/cosign bin/tools/cmrel bin/tools/release-notes bin/tools/goimports bin/tools/ytt bin/tools/yq
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: I rearranged cmrel to come before release-notes just to match the ordering we have in the list of VERSION variables above.

@munnerz
Copy link
Copy Markdown
Member

munnerz commented Jan 5, 2022

Hm, if we only run this in make and not in bazel, could this lead to either 1) bazel and make 'fighting' each other and 2) a change in what people need to run to do things?

It'd be great if goimports could be automatically called as part of {update,verify}-fmt.sh (and then work to remove that script depending on bazel?).

I'm worried that if we add things that only exist in Make, we end out in a 'split' state of the world until the migration from Bazel to Make is complete, where someone needs both build environments configured correctly (and drift between laptop go version and bazel go version could create issues). During k/k's migration, this didn't come up because they had always maintained both a Make-based and Bazel based build system, so our job is slightly harder than theirs in this instance 😬

Just my 2c 😄 (but a huge +1 to running goimports during presubmits!! 🎉)

@SgtCoDFish
Copy link
Copy Markdown
Member Author

SgtCoDFish commented Jan 5, 2022

During k/k's migration, this didn't come up because they had always maintained both a Make-based and Bazel based build system, so our job is slightly harder than theirs in this instance

That's useful history, thanks. 👍

Maintaining both make + bazel for cert-manager until the final switchover was actually my intention in any case, precisely to avoid the situation you describe with the two fighting.

I take the view that by only adding to make (and not going back and changing bazel) the worst that can happen is someone (justifiably) writes a PR locally using a bazel-based development flow in which all tests pass, and then is surprised to see goimports test failures after they raise the PR.

That's not ideal - ideally there's exactly one way to build code + run tests, which you're alluding to - but I think it's fine for the inbetween "dual-running" period before we do the final shift to using make entirely.

Certainly if the only difference until the switchover is that the make flow also runs goimports, that's totally acceptable to me because it's a small win and mostly we don't have issues with people not running goimports on their code before submitting it. Most of the work from now is going to be in replicating bazel stuff in make, not adding new stuff as in this PR.

(I think probably I should have an issue describing the dual running above, as a focal point for discussion, and I'll make that issue now)

CI check will be built upon as Make is improved to reach testing partiy
with bazel

Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
@SgtCoDFish
Copy link
Copy Markdown
Member Author

SgtCoDFish commented Jan 6, 2022

I think this is probably good to go. If we really don't want to have goimports running without adding it into bazel, then we can not add make -f make/Makefile ci-presubmit to jetstack/testing. This PR is a no-op until we add it there.

@jakexks
Copy link
Copy Markdown
Member

jakexks commented Jan 6, 2022

/lgtm

@jetstack-bot jetstack-bot added the lgtm Indicates that a PR is ready to be merged. label Jan 6, 2022
@jetstack-bot jetstack-bot merged commit 25b6728 into cert-manager:master Jan 6, 2022
@jetstack-bot jetstack-bot added this to the v1.7 milestone Jan 6, 2022
@SgtCoDFish SgtCoDFish deleted the goimports branch January 6, 2022 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates that all commits in the pull request have the valid DCO sign-off message. kind/feature Categorizes issue or PR as related to a new feature. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants