-
Notifications
You must be signed in to change notification settings - Fork 28
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
feat(api/log)!: support paging on GetBuildLogs
#798
Conversation
Adds support for the page and per_page query parameters for GetBuildLogs /api/v1/repos/+/+/builds/+/logs This resolves an in-code TODO.
GetBuildLogs
Codecov Report
@@ Coverage Diff @@
## main #798 +/- ##
==========================================
- Coverage 58.20% 58.14% -0.06%
==========================================
Files 242 242
Lines 15721 15737 +16
==========================================
Hits 9150 9150
- Misses 6165 6181 +16
Partials 406 406
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you confirm if this is a breaking change?
I believe it is since the behavior will default to using a per_page
of 10
instead of 100
.
This would impact users running vela get log
via the CLI with more than 10
steps/services in their pipeline since they'd only see logs for 10
steps/services rather than 100
.
api/log.go
Outdated
} | ||
|
||
// ensure per_page isn't above or below allowed values | ||
perPage = util.MaxInt(1, util.MinInt(500, perPage)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this should be 100
based off other API code that calls util.MinInt(<int>, perPage)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant to have it do the same thing as before - the comment says default 100
but I accidentally used 10
. I'll fix that.
I think there can be more than 100 logs, especially if we add the InitStep logs from my proposal. So, I wanted to allow more than 100 per page, even though other endpoints allow at most 100 per page.
Do we really want the per_page max to be 100, the same as the default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we shouldn't allow anything more than 100 results per page 👍
Especially for something like logs which can be quite taxing to retrieve depending on the size
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw, i wasn't concerned about the 10 being the default, but you're right it maybe should have been marked as breaking.
api/log.go
Outdated
// - in: query | ||
// name: per_page | ||
// description: How many results per page to return | ||
// type: integer | ||
// maximum: 500 | ||
// default: 100 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doc comment is a bit clearer on my intention. @jbrockopp do you want the maximum to be 100? I would like to increase that for this endpoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we shouldn't allow anything more than 100 results per page 👍
Especially for something like logs which can be quite taxing to retrieve depending on the size
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even 100 seems like a lot, tbh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dropped the maximum back to 100.
And I left the default at 100 so that it is backwards compatible. Does that look better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cognifloyd apologies if my initial review left you under the impression that this breaking change is bad.
More so, I wanted to confirm it because if so, we try to update the PR title with a !
i.e. feat(api/log): support paging on GetBuildLogs
-> feat(api/log)!: support paging on GetBuildLogs
FWIW - I'm not opposed to making the default 10
instead of current behavior of 100
.
Like @wass3rw3rk mentioned, 100
does seem like a lot since it can be taxing on the system.
i.e. someone has a build with a bunch of steps that each have > 1 MB
in logs
For now, I'll plan to approve this PR so if we don't want to change it, then we can consider it in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I can add !
(I'm slowly learning this commit format) and switch to 10 by default. I'll do that in 30 min or so
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. I lowered the per_page
default to 10 and marked this PR as a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks.. i like it. we can either hardcode in CLI as @jbrockopp said and/or consider dropping hints if they are viewing a subset of available data.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
ed5f252
GetBuildLogs
GetBuildLogs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
FWIW - we can always hardcode the |
Added to server in go-vela/server#798
Added to server in go-vela/server#798 Added to sdk-go in go-vela/sdk-go#216
Follow-up PRs to review/merge once this one is merged: |
Adds support for the
page
andper_page
query parameters forGetBuildLogs
(endpoint/api/v1/repos/+/+/builds/+/logs
).BREAKING CHANGE:
per_page
default lowered to 10. Before this change it always returned 1 page with up to 100 logs. To maintain the same behavior, you must now use?per_page=100
.This resolves an in-code TODO by copying the implementation from some of the other endpoints that already implement this.
I suspect that we're going to have quite a few more
Log
instances to iterate over if we implement something like go-vela/community#771, so I figured I'd go ahead and resolve this while I was looking at this code.