Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Addressing issues raised by staticcheck #2267

Closed
wants to merge 1 commit into from
Closed

Addressing issues raised by staticcheck #2267

wants to merge 1 commit into from

Conversation

gauntface
Copy link
Contributor

@gauntface gauntface commented Jan 22, 2022

I've disabled the checks for switch from go's openpgp implementation to a community fork because it seems like it's not a drop in replacement and needs some extra work.

github/git_commits.go:16:2: SA1019: package golang.org/x/crypto/openpgp is deprecated: this package is unmaintained except for security fixes. New applications should consider a more focused, modern alternative to OpenPGP for their specific task. If you are required to interoperate with OpenPGP systems and need a maintained package, consider a community fork. See https://golang.org/issue/44226. (staticcheck)
        "golang.org/x/crypto/openpgp"

Original issue: #2260

@codecov
Copy link

codecov bot commented Jan 22, 2022

Codecov Report

Merging #2267 (b2ec98c) into master (178169f) will decrease coverage by 0.02%.
The diff coverage is 20.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2267      +/-   ##
==========================================
- Coverage   97.81%   97.78%   -0.03%     
==========================================
  Files         114      114              
  Lines       10266    10269       +3     
==========================================
  Hits        10042    10042              
- Misses        156      158       +2     
- Partials       68       69       +1     
Impacted Files Coverage Δ
github/actions_artifacts.go 96.73% <0.00%> (-3.27%) ⬇️
github/issue_import.go 86.79% <0.00%> (ø)
github/actions_secrets.go 100.00% <100.00%> (ø)
github/repos_pages.go 97.11% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 178169f...b2ec98c. Read the comment docs.

@@ -89,7 +89,7 @@ func (s *IssueImportService) Create(ctx context.Context, owner, repo string, iss
if ok {
decErr := json.Unmarshal(aerr.Raw, i)
if decErr != nil {
err = decErr
return nil, resp, decErr
Copy link
Collaborator

@gmlewis gmlewis Jan 22, 2022

Choose a reason for hiding this comment

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

I'm concerned about this change in behavior... it looks to me like what we had before was most likely broken (because i should not have been returned), but I'm thinking that the original AcceptedError should be returned here instead of the error caused by attempting to unmarshal the JSON.

Because if we return the json.Unmarshal error, the client will have no way of knowing that this is actually an AcceptedError meaning that GitHub accepted the call but decided to not yet return a value.

Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah it's unusual here because the err was never used in this can, so we could simply drop the decErr which will be the current behavior

Copy link
Collaborator

Choose a reason for hiding this comment

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

Except that if decErr is nil then we do want to actually return the value of i, so we cannot drop it entirely. I'm just saying we should return aerr here instead.

@@ -30,3 +30,15 @@ issues:
- linters:
- dupl
path: _test\.go
- linters:
Copy link
Collaborator

Choose a reason for hiding this comment

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

it's probably worth adding at least a one-line comment explaining what each of these rules are that are being excluded

@gmlewis
Copy link
Collaborator

gmlewis commented Nov 3, 2022

Closing abandoned PR.
Feel free to re-open if still desired.

@gmlewis gmlewis closed this Nov 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants