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

feat(api/log)!: support paging on GetBuildLogs #798

Merged
merged 11 commits into from
Apr 10, 2023
Merged

feat(api/log)!: support paging on GetBuildLogs #798

merged 11 commits into from
Apr 10, 2023

Conversation

cognifloyd
Copy link
Member

@cognifloyd cognifloyd commented Mar 24, 2023

Adds support for the page and per_page query parameters for GetBuildLogs (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.

Adds support for the page and per_page query parameters for
GetBuildLogs /api/v1/repos/+/+/builds/+/logs

This resolves an in-code TODO.
@cognifloyd cognifloyd added the feature Indicates a new feature label Mar 24, 2023
@cognifloyd cognifloyd self-assigned this Mar 24, 2023
@cognifloyd cognifloyd requested a review from a team as a code owner March 24, 2023 02:45
@cognifloyd cognifloyd changed the title feat(api/log): support paging on GetBuildLogs feat(api/log): support paging on GetBuildLogs Mar 24, 2023
@codecov
Copy link

codecov bot commented Mar 24, 2023

Codecov Report

Merging #798 (9aea6af) into main (b5777e5) will decrease coverage by 0.06%.
The diff coverage is 0.00%.

Impacted file tree graph

@@            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              
Impacted Files Coverage Δ
api/log.go 0.00% <0.00%> (ø)

wass3rw3rk
wass3rw3rk previously approved these changes Mar 24, 2023
Copy link
Member

@wass3rw3rk wass3rw3rk left a comment

Choose a reason for hiding this comment

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

lgtm

Copy link
Contributor

@jbrockopp jbrockopp left a 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))
Copy link
Contributor

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)

Copy link
Member Author

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?

Copy link
Contributor

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

Copy link
Member

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 Show resolved Hide resolved
@cognifloyd cognifloyd requested review from wass3rw3rk, a team and jbrockopp and removed request for wass3rw3rk March 24, 2023 18:45
api/log.go Outdated
Comment on lines 55 to 60
// - in: query
// name: per_page
// description: How many results per page to return
// type: integer
// maximum: 500
// default: 100
Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Member Author

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.

Copy link
Member

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.

wass3rw3rk
wass3rw3rk previously approved these changes Mar 27, 2023
jbrockopp
jbrockopp previously approved these changes Mar 28, 2023
Copy link
Contributor

@jbrockopp jbrockopp left a comment

Choose a reason for hiding this comment

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

LGTM

plyr4
plyr4 previously approved these changes Mar 28, 2023
@cognifloyd cognifloyd dismissed stale reviews from plyr4, jbrockopp, and wass3rw3rk via ed5f252 March 28, 2023 15:45
@cognifloyd cognifloyd changed the title feat(api/log): support paging on GetBuildLogs feat(api/log)!: support paging on GetBuildLogs Mar 28, 2023
@cognifloyd cognifloyd requested review from wass3rw3rk, plyr4 and a team March 28, 2023 15:49
Copy link
Contributor

@jbrockopp jbrockopp left a comment

Choose a reason for hiding this comment

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

LGTM

@jbrockopp
Copy link
Contributor

FWIW - we can always hardcode the per_page on the CLI side to 100 for vela get log to reduce the impact

cognifloyd added a commit to go-vela/sdk-go that referenced this pull request Mar 28, 2023
cognifloyd added a commit to go-vela/cli that referenced this pull request Mar 28, 2023
@cognifloyd
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Indicates a new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants