Skip to content

Conversation

@PhilippeVienne
Copy link
Contributor

See issue #374 for details

@gmessner gmessner merged commit 35e83d8 into gitlab4j:master Jun 7, 2019
@gmessner
Copy link
Collaborator

gmessner commented Jun 7, 2019

@PhilippeVienne
The testCreateImpersonationToken() test actually fails if any scope other than API or READ_USER is used for the scope. This has been tested on GitLab CE 11.10.4 and 11.11.2 with the same results. So it appears that the API documentation is correctly specifying only api and read_user. I get the following error:

org.gitlab4j.api.GitLabApiException: The following fields have validation errors: scopes
	at org.gitlab4j.api.AbstractApi.validate(AbstractApi.java:593)
	at org.gitlab4j.api.AbstractApi.post(AbstractApi.java:264)
	at org.gitlab4j.api.UserApi.createImpersonationToken(UserApi.java:824)
	at org.gitlab4j.api.TestUserApi.testCreateImpersonationToken(TestUserApi.java:227)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)

Have you had a different result?

For now, I'm going to rollback the change (but leave the modified test) and get ready for the release. Let me know if you have different results than I do.

@PhilippeVienne
Copy link
Contributor Author

PhilippeVienne commented Jun 7, 2019 via email

@gmessner
Copy link
Collaborator

gmessner commented Jun 7, 2019

@PhilippeVienne
The test user is an admin user.

Actually, it is only READ_REGISTRY that is causing the failure, and I would assume that is because the registry is NOT configured in the GitLab server that is being spun up in the Docker container.

I will remove READ_REGISTRY from the test and leave the other scopes in place. I will leave the READ_REGISTRY value in the enum and it will rightly throw an exception if the server does not have the registry configured and that scope is used.

@PhilippeVienne
Copy link
Contributor Author

PhilippeVienne commented Jun 7, 2019 via email

@gmessner
Copy link
Collaborator

gmessner commented Jun 7, 2019

@PhilippeVienne
Yes, that is the problem. I tested against gitlab.com and the READ_REGISTRY scoped worked. I have simply removed READ_REGISTRY from the test. I'll have the release out either today or tomorrow as I'm still working on a separate feature (import/export) that will be included in the release.

@PhilippeVienne PhilippeVienne deleted the fix/impersonnation-token branch June 7, 2019 22:31
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