Problem accessing renku-env

Renku Admin
1

Hi,

I am working on a Renku template that would automatically and dynamically setup the environment to work with Spark/Hadoop. For this, I thought of using repositories with configurations (repo for the configuration of the backend, using renku-env of the user to tune the configuration) but I cannot access private repositories from the entrypoint script run at startup of the environment.

Is it normal that I cannot clone the renku-env repository of my user from the script if it is private? From what I can read in the sidekick then yes, as it checks that the beginning of the url corresponds to the repository of the environment before adding the access token. I just want to make sure because I find it weird that the user is not allowed to have an private environment.

So for my use I may change the sidekick’s logic to add the token for other clones or api requests but before doing that I want to clarify some things. The tokens we have access to are described here. Does this means that we have access to two different tokens? One with more restricted access than the other? Or are those not related to the GITLAB_OAUTH_TOKEN we can access from the sidekick? I’m somewhat confused because in the scope of renku application there is no mention of write access although we can push to the repository of the environment.

I’m trying to get an understanding of these elements to develop my ideas in line of what has already been done, thank for helping me out!

Jules

2

Hi @jules,
I’m afraid our documentation on this is not really up to date :slightly_frowning_face:. Sorry about that.

If you go to your GitLab profile on renkulab.io/gitlab and select applications from the left sidebar you’ll see the client that is actually used by your RenkuLab deployment. By looking at the registered valid redirect URLs you’ll see that in that configuration, our RenkuLab auth component and the Jupyterhub which is integrated in RenkuLab share the same client application, and that this client application has more scopes than what’s listed in the documentation. In particular, this client does have the write_repository scope activated, otherwise users could not push commits from their interactive sessions back to GitLab (as you’ve pointed out).

I hope that after this clarifications things make more sense to you.

Also, I’ve created an issue for fixing the documentation: Update admin docs on standalone gitlab / gitlab client applications · Issue #2103 · SwissDataScienceCenter/renku · GitHub

Andreas

3

Oh I see. Yes it all makes sense now. Thank you very much.

Jules