nexedi / gitlab-ce

@jerome @kirr I found that some instances where failing because they cannot git clone repository. After debug, it's caused by same token used for two projects.

for example: git clone https://gitlab-ci-token:TOKEN@lab.nexedi.com/nexedi/capago.git will return 404 not found and the reason is simply that the token is the same as the one for lab.nexedi.com/jerome/capago.git. Normally when a project is forked, the runner token change, but it's still editable.

Token authentication was changed in gitlab to make it more robust and authentication from build runner token as we use today was disabled, but we had to enable it back because we have many project using it.

The solution is to apply this path or to ask to people to always use different token (and to not edit it).

What do you think ?

I just tried to:

1. enable ci on https://lab.nexedi.com/nexedi/gitlab-ce/settings/ci_cd
2. fork the project for my user https://lab.nexedi.com/jerome/gitlab-ce/settings/ci_cd

the forked project seem to get a new ci token.

If it's easier, maybe we can just reset the duplicated token on user forks - ie. in the case of jerome forking nexedi/capago as jerome/capago, reset the token in jerome/capago ?

the forked project seem to get a new ci token.

Yes, the token change on fork.

If it's easier, maybe we can just reset the duplicated token on user forks - ie. in the case of jerome forking nexedi/capago as jerome/capago, reset the token in jerome/capago ?

It's easier, I prefer that you change the token on jerome/capago.

Thanks, I changed it. I also prefer not to patch at this critical level, even if this patch looks good at a first look.

Do you capago was the only project in this case ?

For now yes, I found the problem only on capago. I'll let you know if there is another project with this problem

From one side I tend to agree with @Jerome that we try to patch as less as we can. On the other hand we are essentially already patching gitlab with enabling gitlab-ci-token user, and from this point of view, it is better we fix it up.

I suggest we resolve capago case manually and wait a bit to see whether there are any problems or not.

@alain.takoudjou, related question: what is the fate of gitlab-ci-token in future versions of gitlab? For 8.17 it was only disabled, but support for it was not completely removed. Is it later removed completely? If you - we have to start thinking out what should be our way.

@kirr from what I read, gitlab-ci-token continue to exists but it's more secure (with the new CI build permissions model).

Authentication with Project runner token was not working anymore because gitlab now use Job token: https://gitlab.com/gitlab-org/gitlab-ce/blob/master-ce/doc/user/project/new_ci_build_permissions_model.md#job-token

Runner token is still present in gitlab project, I didn't see information about removal of it in future versions.