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: GitlabComment knows how to deal with project ids #68

Merged
merged 1 commit into from
Jan 15, 2024

Conversation

rsrchboy
Copy link
Contributor

ListGitlabMergeRequests only provides the project's id in the status, as that's what the API returns. GitlabComment only accepts the project's path.

Not an excellent situation, but one we can readily handle.

For most of the GitLab API, it will accept either a string (the "full path") or a numeric id to identify a project. Here we simply change the Project from a string to intstr, and inject some logic to handle it.

Note that this does introduce a non-breaking CRD change.

`ListGitlabMergeRequests` only provides the project's id in the status,
as that's what the API returns.  `GitlabComment` only accepts the
project's path.

Not an excellent situation, but one we can readily handle.

For most of the GitLab API, it will accept either a string (the "full
path") or a numeric id to identify a project.  Here we simply change the
`Project` from a `string` to `intstr`, and inject some logic to handle
it.

Note that this does introduce a non-breaking CRD change.
// +required
Project string `json:"project"`
Project *intstr.IntOrString `json:"project"`
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder why this had to be a pointer? It's required anyway, so can't be nil. It can still be explicitly "", which is the thing that needs to be checked.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd thought that as well, but ultimately chose a pointer to make it consistent with GitlabMergeRequestRef.MergeRequestId -- that field is similarly required and a pointer. No objections here if you'd prefer it not be.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm true, looks like I missed that one in the past. Then I'm fine with this being a pointer as well. I'll consider "fixing" each case of this in a future api version bump.

@codablock
Copy link
Contributor

@rsrchboy Thanks for the contribution, mostly LGTM :) Just one comment I added.

@codablock codablock changed the title GitlabComment knows how to deal with project ids feat: GitlabComment knows how to deal with project ids Jan 15, 2024
@codablock codablock merged commit 534f1a4 into kluctl:main Jan 15, 2024
@codablock
Copy link
Contributor

@rsrchboy Merged. Do you need it released asap or are you able to run with a self built container image at first?

@rsrchboy
Copy link
Contributor Author

@rsrchboy Merged. Do you need it released asap or are you able to run with a self built container image at first?

Thanks! I'm good for now -- I'm still in a testing stage against one repo, so self-built isn't a huge deal at the moment.

@rsrchboy rsrchboy deleted the gitlab-project-id-or-path branch January 16, 2024 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants