REQ: Gitea Part 2 - Drone

[Dunky13]

Next step in integrating Gitea is apparently Drone. I have much to learn what drone is, and especially how it's used in our product.

I do know, after @j-zimnowoda showed me last Thursday, that GitHub and drone are integrated in several parts of the stack.
Now it wouldn't be too complicated to rewrite everything to Gitea. But that would exclude all usage of GitHub, which we use (for now) in otomi-values.

This discussion is mostly to understand what needs to be modified, and in what general direction, so I can create a Story epic, and some Tasks.

As posted in the #dev channel, but wanting to formalise the questions.

• Should Drone become 'easily' configurable between multiple (GitHub, Gitea, maybe more?) git providers?
• Should values be exposed that the user can choose Gitea/GitHub - or will that become a chicken/egg problem?
• Should configuring these git providers happen more or less automagically or do users need to input multiple different values.

I am sure I'm missing multiple points, and points of view, so please let me know where and at what I should start looking at first/focus on.

[Morriz]

• Should Drone become 'easily' configurable between multiple (GitHub, Gitea, maybe more?) git providers?

Now, since (for now) gitea's ONLY function will be to hold otomi values, then, after this PR, with gitea.enabled (by default) it assumes that is what the user wants: gitea to be the git repo used for gitops.

• Should values be exposed that the user can choose Gitea/GitHub - or will that become a chicken/egg problem?

As I explained before, we will create a story to push to an extra remote for backup. Not this PR.

• Should configuring these git providers happen more or less automagically or do users need to input multiple different values.

One provider: Gitea. You should not be concerned with gitea.enabled=false. Choosing gitea will need only one value for its chart: password. Drone however needs to be told to talk to gitea when gitea.enabled=true. I believe all configuration is available, and the user does not need to provide anything else. Please investigate and correct me if I'm wrong.

Hopefully this answers your questions.

[Morriz]

Ok, given the idea behind this whole endeavour is that we can limit the steps a user has to take to deploy otomi, we should have first asked ourselves the following question:

Can we instruct the gitea api to create an oauth app INCLUDING given clientID and clientSecret?

If so, then just by the following values:

charts:
    gitea:
        enabled: true
        password: somepassword
    drone:
        sourceControl:
            gitea:
                clientID: someclientid
                clientSecretValue: someclientsecret
                server: gitea.dev.eks.otomi.cloud

deployment would result in:

• gitea installed (done)
• gitea having otomi/values (done)
• gitea having an oauth connection
• drone using that oauth connection (to be able in the drone UI to connect to otomi/values and select it for syncing)

[Dunky13]

clientID & clientSecretValue are dynamically generated through the Gitea API: https://gitea.dev.eks.otomi.cloud/api/swagger/#/user/userCreateOAuth2Application
We cannot set it statically. Also is that something we want, as it is an internal application talking to an internal application. Should a user be able to manipulate that data? I don't think that's necessary.

Once otomi-gitea is destroyed, the clientID & clientSecretValue become invalid

[Dunky13]

Drone needs clientID & clientSecretValue on startup. So Gitea + a specific job that generated the clientID & clientSecretValue need to be run & started before drone

[j-zimnowoda]

Quite problematic issue:
If a Gitea-job creates oauthClient then how from that job we populate clientID & clientSecretValue to the values repo 🙀

We may ask Gitea to make an REST API, so we can provide clientID and clientSecret in the POST request of createOauthClient.

[Dunky13]

Just discussed with @Morriz

• store Gitea Oauth as secret
• run apply -l stage!=post (attach stage: post to drone)
• attach secret to drone
• run apply -l stage=post

[Morriz]

Indeed. With "attach secret to drone" becoming a generic script like bin/retrieve-credentials.sh (to make it explicit for now), which performs the following steps:

1. kubectl get secrets and extract creds
2. update values locally. For gitea this would be inenv/clouds/$CLOUD/$CLUSTER/secrets.overrides.$CLOUD-$CLUSTER.yaml (section: charts.drone.sourceControl.gitea)
3. git commit -m "Importing generated credentials [ci skip]" --no-verify

I think step 3 is a clean way to add those to the repo, but that needs to be initialized by then. Is that the case?

[j-zimnowoda]

Will the drone pipeline refresh git repo while running ?

[Morriz]

No, the repo values are updated human side only