-
Notifications
You must be signed in to change notification settings - Fork 670
feat(api): add support for Gitlab Deploy Token API #1052
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): add support for Gitlab Deploy Token API #1052
Conversation
ce8567d
to
588e684
Compare
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 for the MR! 👍 Nicely done overall, just a couple of comments regarding docs and a small fix
c8c78f4
to
7703743
Compare
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.
@machine424 I restarted the build as it is now passing on latest
with 12.9 released 👍
Btw, your PR now also enables usage of deploy tokens via the CLI! :) If you like, you could add docs (in docs/cli.rst
) and tests for this in tools/cli_test_v4.sh
, similar to project/group variables:
python-gitlab/tools/cli_test_v4.sh
Lines 163 to 186 in 8173021
# Test project variables | |
testcase "create project variable" ' | |
OUTPUT=$(GITLAB -v project-variable create --project-id $PROJECT_ID \ | |
--key junk --value car) | |
' | |
testcase "get project variable" ' | |
OUTPUT=$(GITLAB -v project-variable get --project-id $PROJECT_ID \ | |
--key junk) | |
' | |
testcase "update project variable" ' | |
OUTPUT=$(GITLAB -v project-variable update --project-id $PROJECT_ID \ | |
--key junk --value bus) | |
' | |
testcase "list project variable" ' | |
OUTPUT=$(GITLAB -v project-variable list --project-id $PROJECT_ID) | |
' | |
testcase "delete project variable" ' | |
OUTPUT=$(GITLAB -v project-variable delete --project-id $PROJECT_ID \ | |
--key junk) | |
' |
For deploy tokens, this might look something like:
testcase "create project deploy token" '
OUTPUT=$(GITLAB -v project-deploy-token create --project-id $PROJECT_ID \
--name foo --username root --expires-at "2021-09-09" --scopes "read_registry")
echo $OUTPUT | grep -q "name: foo"
'
testcase "list all deploy tokens" '
OUTPUT=$(GITLAB -v deploy-token list)
echo $OUTPUT | grep -q "gitlab+deploy-token"
'
..where you grep for whatever output the server response should include. If the custom bash test syntax is too weird then don't worry though, we can also add these later.
Cool, yes of course, I’ll add them. 2- Another problem: the API doesn’t take provided I added some tests here : e9814b2 to illustrate my sayings. |
Nice, thanks! Sorry I wasn't fully following the previous round on this but I'll chime in.
I agree the empty value workaround won't work for libraries. How about just documenting this as a warning in the docs with links to upstream issues (at least that's what gitlab does for their open issues) - for both the optional attributes being required, and the username having no effect? And once it's fixed upstream the exact GitLab versions affected can be defined. The tests will just need to provide the optional args as well for now. As you said it's the API behavior and not the wrapper. I see This way you don't have additional logic or breaking it for specific gitlab versions if a Hm: Looking at it a bit more, seems like the upstream fix for the optional args is just changing required to optional (here and here. I'll see if I can do a few lines of Ruby, maybe then it can already get into a patch release soonish :P |
I've started an upstream PR for the optional params, let's see if that gets merged into the next patch release, then we might not need to worry about it here. Not quite sure yet what's going on with |
e9814b2
to
15ca555
Compare
Great. |
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.
Seems like this API is totally broken. How did this ever pass review at GitLab?
Your MR looks fine. Just a small change
15ca555
to
f9ffbd1
Compare
@max-wittig , when the client serves the server ! I'll not add more tests, I need this feature, lool. |
Wow cool, I never got to that one, thanks for that :) I approved with the two suggestions as you mentioned, it seems both upstream MR's will be merged in time for 12.10. Yeah, thanks for adding all the CLI/integration tests, that's really extensive 😁 |
f9ffbd1
to
60285d9
Compare
There're never that extensive, but I really don't want to open a new issue on Gitlab 😉 |
60285d9
to
01de524
Compare
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.
Thank you for implementing this! LGTM 👍
There is a conflict between the required parameters of
POST /projects/:id/deploy_tokens
(andPOST /groups/:id/deploy_tokens
) as documented here :https://docs.gitlab.com/ce/api/deploy_tokens.html#create-a-project-deploy-token
and required parameters that the API waits for:gitlab.com
that is uses 12.9.0-pre 4b94245907d (As I write these lines) and the docker imagegitlab/gitlab-ce:nightly
require four parameters:name
,expires_at
,username
andscopes
.Creating a deploy token from
gitlab.com
UI agrees with the Deploy Token API documentation: only thename
and thescopes
are required.The managers I added require the four parameters to make tests pass with
gitlab/gitlab-ce:nightly
.the documentation on the other hand reflects the provided Deploy Token API documentation.
I've created an issue to make this clear: https://gitlab.com/gitlab-org/gitlab/-/issues/211878