Creation of FAS seems purposeless

[jrybar-rh]

From what it looks like at section 2. Approval in docs, the FAS account is an extraordinary step that an upstream maintainer shoudn't be bothered with.

The entire process could be circumvented with the following process:

1. Gitlab users need to make a test of their githook and they obtain a secret token
2. The issue created after webhook-test also provides a link to a simple page with a form accepting this token, along with Legal information which needs to be accepted (ticked) and probably even captcha to avoid false git[hub,lab] accounts and bots
3. From now on there is a flag in the database that this token is valid and associated with specific project and legal stuff was accepted. No FAS creation needed.

The Why:
Not every upstream is keen on creating another account, they just wish to (or accepted the request to) auto-downstream their work. No other burden should be requested on them.

[TomasTomecek]

Thank you @jrybar-rh for opening this! I flagged the issue for discussion on our weekly architecture calls.

[lachmanfrantisek]

We didn't cover this one during the last arch meeting but a few notes about this to give you more context in the meantime:

Here, we are discussing two things -- what we need from the user (requirements) and how to get it (format/implementation).

1. Regarding the requirement of FAS, it used to be a solution to not need to handle legal rules ourselves (=We have a specific FAS user being responsible for the installation. And we can blame that user in case of an issue.). Currently, we require this for the installation but maybe, we can do this per job:

• For Copr builds, we already allow external contributors to trigger the build. (So, for allowed projects, anyone can create a pull-request/merge-request and the build is being triggered.)
• For propose-downstream, we send the release tarball to lookaside cache and open a distgit PR with the scratch build being triggered. (Here, it's a question if we want to allow this for anyone without FAS.) Currently, the trigger is a release, so any maintainer of the approved project can trigger this workflow.
  • And having Pull from upstream #1576 could avoid having to deal from upstream at all. Should be done by the end of the year..;)
• For downstream-only jobs (Koji builds and Bodhi updates, you don't need to do anything. Pushing the config to dist-git is just enough. (=Someone with the dist-git commit rights needs to setup this.)

2. And regarding the form/implementation:

• Merging token generation with the approval process would lead to a lot of forge-dependent code. It's easier for us to have the very same setup we have on GitHub (an issue created to track the approval process). The missing piece is to create a repo on each forge and a few code tweaks to remove the hardcoded GitHub repo and use the one on the current forge.
• We've tried to do a welcome form on GitHub after an app is installed but we've hit multiple technical issues. To name one, the welcome URL is static. And doing a page where you can log in with GitHub/FAS account would take a non-trivial time so we agreed on not doing this in favour of other functionalities. (Also, it's worth mentioning that we want to use forge UI as much as possible for communication. Not only it's cleaner for the user but usually, it's also easier for us to do.)

[FrNecas]

The outcome from arch discussion:

• do not require FAS if it is not really needed (e.g. copr jobs)
• require it only in jobs where it's necessary (mainly downstream -- propose-downstream, koji build)

[lachmanfrantisek]

@jrybar-rh Hello, this issue (and #1707 as well) will not be needed once we finish our #1850 epic.

With that, I am closing this. Feel free to watch the epic and/or we can discuss it at the weekly sync meeting.