Enforce golangci-lint + gofumpt #587
Labels
No Label
has/backport
has/pull
in progress
invalid
kind/breaking
kind/bug
kind/build
kind/deployment
kind/docs
kind/enhancement
kind/feature
kind/lint
kind/proposal
kind/question
kind/refactor
kind/security
kind/testing
kind/translation
kind/ui
need/backport
priority/critical
priority/low
priority/maybe
priority/medium
reviewed/duplicate
reviewed/invalid
reviewed/wontfix
skip-changelog
status/blocked
status/needs-feedback
status/needs-reviews
status/wip
upstream/gitea
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitea/go-sdk#587
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Gusted/go-sdk:fix-some-issues"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
go install ....
instead of the old deprecated way ofgo get
@ -15,3 +15,1 @@
var (
version1_12_3, _ = version.NewVersion("1.12.3")
)
var version1_12_3 = version.Must(version.NewVersion("1.12.3"))
As an aside, we should probably just move this into
version.go
with the others.@ -145,3 +145,3 @@
// CreateTeam creates a team for an organization
func (c *Client) CreateTeam(org string, opt CreateTeamOption) (*Team, *Response, error) {
func (c *Client) CreateTeam(org string, opt *CreateTeamOption) (*Team, *Response, error) {
Why do we want this to be a pointer? Is
nil
a valid thing to pass?Easier to work on, see the changes in validate, otherwise we will end up
(&opt).Validate()
which is hacky IMO. But happy to revert it.Oof, I'm not (personally) a fan of side-effects like that.
I would think defaults should be set prior to
Validate
rather thanValidate
changing the struct.I feel like passing in a pointer just opens a footgun whereby passing
nil
could cause a panic.They aren't defaults, it's seems to "fix" certain options(e.g.
opt.Permission
AccessModeOwner -> AccessModeAdmin), such that it would be accepted by the Gitea server.Hmm...I'm not convinced that
Validate
should modify the struct, though that's largely personal preference.I also agree
(&opt).Validate()
looks a bit silly, but from an API standpoint we may as well keep guns away from feet. ?Don't tell anyone, but this behavior was already here... But just broken ?.
@ -191,3 +191,3 @@
// EditTeam edits a team of an organization
func (c *Client) EditTeam(id int64, opt EditTeamOption) (*Response, error) {
func (c *Client) EditTeam(id int64, opt *EditTeamOption) (*Response, error) {
Same question
@ -85,3 +85,3 @@
// AddCollaborator add some user as a collaborator of a repository
func (c *Client) AddCollaborator(user, repo, collaborator string, opt AddCollaboratorOption) (*Response, error) {
func (c *Client) AddCollaborator(user, repo, collaborator string, opt *AddCollaboratorOption) (*Response, error) {
Same question
Finally, CI failures relevant.
CI Isn't passing!! Please do not merge yet.
Odd, it was passing. Looks like a sum error now?
It was a lie, the binaries weren't downloaded(see the
... not found
errors). And now it's downloading and it's giving a sum error 😄 This will be a interesting rabbit hole.go run ...
So for some reason the latest golangci-lint version has errors with go sum(probably some linter changed something) so we're running an older version, the same Gitea currently uses.
The CI now also pulls go1.18, because go1.17+ allows to use
go run package_here
without having to usego install ...
orgo get -u ...
first. And now the CI is passing and actually linting! So we can safely merge :DOho! Sneaky CI!
Oof, yeah that might be fun.
Perhaps CI should use images for our linters? That way it doesn't need to build them every time.