Skip to content

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.

@cognifloyd cognifloyd requested review from a team, jbrockopp and wass3rw3rk 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.

@cognifloyd cognifloyd requested a review from wass3rw3rk March 25, 2023 06:41
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 a review from jbrockopp March 28, 2023 15:49
@cognifloyd cognifloyd requested review from a team, plyr4 and wass3rw3rk 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.

8 participants