Add PipelineListsOptions to woodpecker-go

[xoxys]

I fear that's a breaking change... It's a bit pain IMO that we can not version the go lib independent of the server.

I don't see a (good) way to make it non-breaking. If you have a better idea, please let me know. However, as this will be breaking anyway, we should replace all other raw query parameters used in the lib (e.g. https://github.com/woodpecker-ci/woodpecker/blob/main/woodpecker-go/woodpecker/repo.go#L6) by proper opt structs as well as this makes it easier to extend with future options.

Changes:

• Add PipelineListOptions and expose them to cli

❯ ./dist/woodpecker-cli pipeline ls --format "#{{ .Number }} {{ .Started }}" --before "2023-08-21T21:11:02+02:00" 2
#1 1692644861
❯ ./dist/woodpecker-cli pipeline ls --format "#{{ .Number }} {{ .Started }}" --after "2023-12-11T15:07:04+01:00" 2
#43 1702762952

• Add RepoListOptions and expose them to cli

❯ ./dist/woodpecker-cli repo ls --all
testorg/test (id: 2, forgeRemoteID: 3, isActive: true)
testorg2/test2 (id: 4, forgeRemoteID: 4, isActive: true)
woodpecker/woodpecker-test (id: 0, forgeRemoteID: 1, isActive: false)
testorg/woodpecker-test (id: 6, forgeRemoteID: 2, isActive: true)

• Add DeployOptions
• Add PipelineStartOptions
• Add PipelineLastOptions
• Add RepoPostOptions
• Add RepoMoveOptions

[xoxys]

How do we handle such PRs in general? Keep it open until we want to do a major version bump?

[qwerty287]

We actually just merged them and ignored that they're breaking...

[xoxys]

Maybe we should just move the lib to a dedicated repo? But same argumentation might apply to cli, agent etc. which would end in a repo mess instead of the current monorepo approach. So maybe a bad idea 🙃

[woodpecker-bot]

Deployment of preview was torn down

[qwerty287]

Current code lgtm, but you introduced a ListOptions type, but did not apply it to all list api methods.

Missing in:
UserList
RegistryList
CronList
SecretList

Thanks for adding tests

[xoxys]

That's correct. It's already on my to-do list thanks for the reminder :)

[6543]

before we merge this, I want to have a bugfix release!

[xoxys]

... Nobody wanted to rush through especially not because the PR is not finished and requires a major version bump...

[qwerty287]

I agree, but which bugfixes should the contained in this patch release? There's no open/merged PR currently (except some docs enhancements) and AFAIK there was nothing critical reported

[6543]

I want a majour bump soon-isch to get some breaking stuff done ...

... so we can just wait till that

[xoxys]

I dont get your point. This PR was marked as breaking all the time. Its was already planned to wait with a merge till the next breaking release all the time.

First you want a bugfix release first (I still dont know how this is related to this PR) now you want a major soonish 🤷‍♂️

Im (again) pretty confused about this communication style. Just dropping a single sentence and not responding to any question is pretty bad.

[xoxys]

Current code lgtm, but you introduced a ListOptions type, but did not apply it to all list api methods.

Missing in: UserList RegistryList CronList SecretList

@qwerty287 Was looking into it again. These client methods don't have any additional options. Should we still add an empty options type?

[xoxys]

If we want to add empty list option types to every list method, what about:

	OrgRegistryList(orgID int64) ([]*Registry, error)
	GlobalRegistryList() ([]*Registry, error)
	OrgSecretList(orgID int64) ([]*Secret, error)
	GlobalSecretList() ([]*Secret, error)
	AgentList() ([]*Agent, error)
	AgentTasksList(int64) ([]*Task, error)

[qwerty287]

My comment was about the pagination options. They're not supported yet, you need to add them and also add the query params to the URL.

[6543]

ci faild related

[pat-s]

@xoxys Do you want to get this into 3.0? Currently consolidating and the state here is unclear to me.

I understand that it could potentially be merged in 3.x as it is considered an independent part of the toolstack anyhow. Yet of course it would be matching to get it into 3.0, but it shouldn't cause any stress.

[xoxys]

Ill finish the PR this week. Would like to get it into 3.0

[6543]

INFO: if #2691 lands this here should not be needed anymore ...

[xoxys]

As this PP is in draft state since a year any plans to finish it soon? Otherwise Ill continue to get it to v3.

[6543]

If this pull is ready before it, we merge it ... I would argue

[xoxys]

Ok so the answer is there is no timeline to finish the linked PR. Then Ill continue with this one for now.

[xoxys]

My comment was about the pagination options. They're not supported yet, you need to add them and also add the query params to the URL.

@qwerty287 Sorry I still dont really understand why we need to add the pagination to e.g. RegistryList but not OrgRegistryList. Can you add some more details?

[codecov]

Codecov Report

Attention: Patch coverage is 71.94245% with 39 lines in your changes missing coverage. Please review.

Project coverage is 27.89%. Comparing base (ebf9f9c) to head (22e2f9f).
Report is 4 commits behind head on main.

Files with missing lines	Patch %	Lines
cli/deploy/deploy.go	0.00%	6 Missing ⚠️
cli/pipeline/list.go	79.31%	4 Missing and 2 partials ⚠️
cli/pipeline/last.go	0.00%	5 Missing ⚠️
cli/pipeline/start.go	0.00%	5 Missing ⚠️
cli/repo/repo_add.go	0.00%	5 Missing ⚠️
cli/repo/repo_list.go	0.00%	5 Missing ⚠️
cli/repo/repo_sync.go	0.00%	5 Missing ⚠️
cli/pipeline/info.go	0.00%	1 Missing ⚠️
cli/pipeline/ps.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3652      +/-   ##
==========================================
+ Coverage   27.57%   27.89%   +0.32%     
==========================================
  Files         381      382       +1     
  Lines       27923    28015      +92     
==========================================
+ Hits         7700     7816     +116     
+ Misses      19538    19512      -26     
- Partials      685      687       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[qwerty287]

My comment was about the pagination options. They're not supported yet, you need to add them and also add the query params to the URL.

@qwerty287 Sorry I still dont really understand why we need to add the pagination to e.g. RegistryList but not OrgRegistryList. Can you add some more details?

That's a pretty old thread, I can't remember that I said something like this. All paginated api endpoints should have pagination options in the sdk as well.

[pat-s]

Alright, everyone seems to be (somewhat) happy -> 🚀

[xoxys]

Noooo :D There was an ongoing discussion, and I was preparing the fix :D Anyway, then it will go into a dedicated PR. Note to myself: Block PRs on my own if I plan to add more changes 🙈

[pat-s]

Sorry! To me it read like everything was resolved and you did all required changes 🙈️

[xoxys]

All good. The PR is good as is, and the missing pagination options in sdk for all api endpoints that supports it can be implemented in a follow-up PR. I'll take care.