gitea/go-sdk
44
46
Fork 72
Code Issues 21 Pull Requests 8 Actions Releases 18 Activity

WIP feat: return response on functions #361

Closed
ankitm123 wants to merge 2 commits from ankitm123/go-sdk:sdk-347 into main
pull from: ankitm123/go-sdk:sdk-347
merge into: gitea:main
Conversation 2 Commits 2 Files Changed 28 +574 -320
ankitm123 commented 2020-06-07 14:22:08 +00:00
First-time contributor
Copy Link

This PR:

  • Creates a Response struct
  • Returns Response struct in addition to error.

Fixes #347

This PR: * Creates a Response struct * Returns Response struct in addition to error. Fixes #347
👍 1
ankitm123 force-pushed sdk-347 from aa263f0475 to eb986ba05f 2020-06-07 19:40:24 +00:00 Compare
6543 commented 2020-06-07 21:01:16 +00:00
Owner
Copy Link

@ankitm123 you dont need to squash, its easyer to review diffs per commit - and thans for your work

@ankitm123 you dont need to squash, its easyer to review diffs per commit - and thans for your work
6543 added this to the v0.13.0 milestone 2020-06-07 21:01:29 +00:00
6543 added the
kind/breaking
kind/feature
status/wip
 labels 2020-06-07 21:01:53 +00:00
6543 reviewed 2020-06-08 23:00:55 +00:00
Dismissed
gitea/client.go
@ -111,3 +117,3 @@
return nil, nil, err
}
switch resp.StatusCode {
6543 commented 2020-06-08 23:00:55 +00:00
Owner
Copy Link

I know this is stil WIP ...
... but I wont remove status check on the client

and on function witch use e.g. getResponse
dont return nil, nil, err -> return nil, resp, err and it should work all fine

I know this is stil WIP ... ... but I wont remove status check on the client and on function witch use e.g. getResponse dont `return nil, nil, err` -> `return nil, resp, err` and it should work all fine
ankitm123 commented 2020-06-09 13:02:18 +00:00
Author
First-time contributor
Copy Link

I think the burden of checking the response status code should be with the end user, but I can return the textual representation of some of the status code (the ones in that status check), thoughts?

I think the burden of checking the response status code should be with the end user, but I can return the textual representation of some of the status code (the ones in that status check), thoughts?
6543 commented 2020-06-09 13:28:41 +00:00
Owner
Copy Link

I think the client should check if there was an error - since http status codes represent them

if remove this a lot of code is not gone just the user has to reimplement it elsewhere
and it is harder to use

I think the client should check if there was an error - since http status codes represent them if remove this a lot of code is not gone just the user has to reimplement it elsewhere and it is harder to use
ankitm123 commented 2020-06-09 13:44:01 +00:00
Author
First-time contributor
Copy Link

I agree for 5XXs, yes, but not so sure about 4XXs (There can be cases where 4XXs are not considered errors)

I agree for 5XXs, yes, but not so sure about 4XXs (There can be cases where 4XXs are not considered errors)
6543 commented 2020-06-09 14:24:25 +00:00
Owner
Copy Link

thats why we will return responce too so the user still can deside what to do with it

thats why we **will** return responce **too** so the user still can deside what to do with it
ankitm123 commented 2020-06-09 14:30:54 +00:00
Author
First-time contributor
Copy Link

The idiomatic way to do error checks in go, would mean that if it's an error, then people wont get it to the check for response, right?

if err != nil {
  return ...
}

//check for response if error is not present ...
The idiomatic way to do error checks in go, would mean that if it's an error, then people wont get it to the check for response, right? ``` if err != nil { return ... } //check for response if error is not present ... ```
ankitm123 commented 2020-06-09 14:38:19 +00:00
Author
First-time contributor
Copy Link

So an error for 4XXs will make it a bit complicated imo.

So an error for 4XXs will make it a bit complicated imo.
6543 commented 2020-06-09 14:57:29 +00:00
Owner
Copy Link

If i like to get something and it return 404 its not what i wont -> error

If the user like to know that he can still check the status with this pull

If i like to get something and it return 404 its not what i wont -> error If the user like to know that he can still check the status with this pull
ankitm123 added 1 commit 2020-06-15 19:44:20 +00:00
Some checks failed
continuous-integration/drone/pr Build is failing
Details
d5327c3b6c
refactor: modify more functions 
Signed-off-by: ankitm123 <ankitmohapatra123@gmail.com>
6543 commented 2020-07-16 09:02:26 +00:00
Owner
Copy Link

@ankitm123 what's the matter?

@ankitm123 what's the matter?
6543 removed this from the v0.13.0 milestone 2020-09-12 04:31:31 +00:00
6543 closed this pull request 2020-09-14 02:37:34 +00:00
Some checks are pending
continuous-integration/drone/pr Build is failing
Details
testing / testing*
Required

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
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 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
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/go-sdk#361
No description provided.
Delete Branch "ankitm123/go-sdk:sdk-347"

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?