What exactly do I need to attach an Apps instance to a git repository?
Where do I host the repo and how is the process? Is there any additional documentation apart from the one shipped with Apps itself?
Hi Flogge,
with the git-management for Apps you can have a git repository with the versioned app configuration. Currently we are supporting two git forges, namely GitLab and Gitea. For GitLab we have full integration with ONE DATA, i.e. it is possible to login with your ONE DATA credentials there via an OAuth2 service.
You can link one of the supported git forges to your Apps instance. Apps will then automatically create a repository at this git forge (within a configured namespace - s.b.) when you set your app git-managed via the app settings.
For setting up git at your instance you need either GitLab CE/EE and our GitLab OAuth server or a Gitea instance. This instance must be reachable from the Apps server and vice versa. You can then configure the Apps server to use the respective instance and prepare your GitLab/Gitea instance. More about this can be found in the internal documentation here and here.
Configuration at the git forge is mainly creating a technical user and an API token. Apps will then use this techincal user to create the repository for your app and maintain it. Commits are done on behalf of the logged in user.
If you have any further questions on the setup or details about the git-integration in ONE DATA Apps, please contact me in this thread.
Bests,
Matthias
So in theory, this means that I can connect any gitlab instance as long as there’s a network route to it?
Yes, this is possible. You can configure the Apps server in a way that it puts git repositories in a certain namespace (e.g. a group). Also you would need to have some technical user at this instance who will administrate the repositories. Apart from that it is possible to use any GitLab instance.
How would in such a case the committing take place (i.e. on behalf of which user information)?
When you save a app configuration in the App Builder a commit is made on the checked out branch. The user information (e-mail, name) of the currently logged in user is used for the commit.
In some cases a commit is created by the aforementioned technical user. This is e.g. the case when Apps needs to update the _index.json (a file that the server maintains to be able to reassemble the configuration when external modifications are made to the repository - e.g. through merges in GitLab).
Roger that.
So the user information for the commit is taken from the OD user. Fine.
But how is the mapping between the git user and the OD user done in case of an “external” gitlab?
There is no shared user IDP or authentication service in such a case. How is the OD user used to map to and authenticate as the corresponding gitlab user (for clarity, consider the gitlab instance users being required to identify/authenticate via an SSH key for example)?
The GitLab OAuth server acts as an external identity provider for GitLab. When you choose to login the first time with your ONE DATA credentials (via the ONE DATA option in the “Sign in with” section of the GitLab login), a new GitLab account is created. This account is linked to your ONE DATA account. You can add your SSH key to the account in order to checkout repositories via SSH then.
Ah I see.
So the reuse of already existing external gitlab users is not intended. Instead, new users based on the OD user infos are created (on demand). In a scenario where I already have my own user in the external gitlab, I will have to have another user created for the interaction from Apps side, correct?
I can then chose to “replace” my existing user and use the OD user for outside-Apps interactions or continue to use my existing user in parallel.
This in turn also implies, that the technical gitlab user for Apps needs to have permission to create new users in the gitlab target group(s)/project(s).
Exactly. The users linked to ONE DATA are separate to the users that already exist at the GitLab instance (theoretically you could also manually link your existing users beforehand though).
The technical user requires permission to create users and create projects in the configured namespace. These permissions must also be set in the API token that is set in the Apps server configuration.
1 Like