@@ -310,7 +310,8 @@ This is a short summary of the already short summary on the pad, do read the pad
another vector for attack or accident weakening security further?_
- The current situation where releasebot uses GitLab Issues to decide how to interact with Jenkins is also not even a short-term solution any more.
_(Centurion Dan) - I disagree with this assesment. Setting up jenkins jobs is a typically one off occurence and I don't think it is a big burden to do it
_(Centurion Dan) - I disagree with this assessment. Setting up jenkins jobs
is a typically one off occurence and I don't think it is a big burden to do it
this way - in fact it makes sense as your not having to manually provide any
urls etc. Obviously triggering builds is the issue, and that can be solved
easily with a webhook and triggers builds on push - uses releasebot unchanged
@@ -332,6 +333,8 @@ A couple things where the proposed options (should) concur:
(KatolaZ) ^^^ The above means that we should give master privileges to all the users that have
provided packages to devuan?!?
(Centurion_Dan) ^^^ that's a separate issue to do with which permissions are
allowed to build what packages.
(*) Valid here means both valid and authorised
- Giving build permissions to a large number of packages in the experimental branch should not be much of a hassle (example use case)
@@ -342,8 +345,11 @@ A couple things where the proposed options (should) concur:
Since there is no code to judge, this is gathered from what was said that would be done on Releasebot:
- There are no real proposed improvements to the current workflow, it keeps GitLab as a source of *authorisation* for Devuan and is extremely vague about the way other distributions provide *authorisation*. It looks like the proposed solution is to make them sign up for GitLab, create dedicated groups for each distribution and have them use the GL Issue workflow. Far from optimal.
(Centurion Dan) - that's false. I've laid out multiple times with specifity what's required and what's
(Centurion Dan) - that's false. I've laid out multiple times with specifity what's required and how to acheive that, and I will provide the code to solve it
along with tests to validate it.
- Current code is python, but hard to understand python. Refactoring is badly needed, integration tests, etc. Basically a rewrite. Again, in theory this already started, more transparency is needed.
(Centurion Dan) I've started with tests suites so we can validate refactoring doesn't break current functionality. As I get functional test coverage I will provide a feature branch with proposed patches for each issue, and where I refactor or add functions I will write unit tests to ensure test coverage for that too.
- It is go, but it is easy to understand go.
@@ -355,8 +361,18 @@ Whatever we do:
- We need a different *authorisation* source, relying on GL for this is insane even short-term.
(Centurion Dan) why is it "insane"?
- because you're relying completely on gitlab issues to build (~parazyd)
(Centurion Dan) ^^ that simply doesn't my question. Also the use of the term "insane" is emotive and doesn't describe what the actual problem with relying on gitlab for authorisation is. If we have specific detail we can address them
- If we consider different options, they may not look much different than Scorsh.
(Centurion Dan) the only other option is to build a full featured federated auth service...
(Centurion Dan) We can't consider options until we have a good grasp of the current issues. We can't evaluate scorsh until the issues are defined. I suggest we file specific bugs in the bts for each issue against each component. We can use the namespace 'devuan-infrastructure':
+ for non descript build pipeline issues use 'devuan-infrastructure-build-pipeline'
* use this for raising issues about integration issues etc
+ for configuration or non bug/wishlist issues with specific components,
use the component name eg:
+ for issues relating to a particular software package eg devuan-releasebot, amprolla:
please file bugs, feature requests etc there.
Perhaps by using the BTS we can get some clarity.
Something that has crossed my mind and can be seen as a middle-ground, which may or may not be worth considering:
* Special permissions repository (per distro) with PGP signed commits by whitelisted keys.