On 25/07/17 23:48, KatolaZ wrote:
> On Tue, Jul 25, 2017 at 11:30:19PM +1200, Daniel Reurich wrote:
>
> [cut]
>
>>
>> As it is I still don't understand what problems scorsh is trying to
>> solve but?
>>
>
>
> One of the problems that scorsh is trying to solve is that at the
> moment only two people can issue build requests on gitlab, besides you
> and nextime, and these two people are me and Lydia_K. This is simply
> not sustainable, and the permission system of gitlab does not seem to
> be flexible enough.
>
It is flexible enough. You have the permission to allow people to build
by either giving them at least master permissions on a project by
project basis, or adding them as master on the devuan-packages group to
grant them the ability to build any package in devuan-packages. This
already works.

> The other problem scorsh is trying to solve is the fact that there is
> no privilege separation between who can issue a build and who can
> modify a Jenkins job.

Actually their is privilege separation. People need to have at least
"master" privileges in
https://git.devuan.org/devuan/devuan-repository-masters to be able to
add/modify/delete projects from jenkins. This is independent of the
permissions required to issue build commands for the project whicn only
requires master permissions on the project itself.

>
> The other problem is that we are going to support other distributions,
> and we need to have separate authentication spaces for each of them.

That is easily enough added using the existing mechanisms. We'd
obviously need to refactor releasebot to handle multiple project configs
- but that's not hard to add.
>
> The other problem is that releasebot depends *heavily* on gitlab, and
> effectively prevents the usage of anything different from gitlab.

It only uses gitlab issues api on that side of things. We can easily
add support for other mechanisms including ssh commands, git post commit
hooks etc. This is a relatively trivial feature to add when we are
working on a migration to another git repository platform or if someone
else decides to use a different platform. I think we should split this
functionality out so the gitlab polling is independent from the main
functionality.
>
> You keep saying that it is possible to patch releasebot to do this and
> that, but it's not easy to see how these patch will be implemented,
> and who will implement and maintain them. And, after all, they will
> just be *patches* to something that was not meant to solve those
> problems.
>
The logic of releasebot is pretty straightforward, but needs to be
refactored to make it more readable, and make adding the needed features
easier to do.

The claim that releasebot was never meant to solve these problems is
entirely beside the point and doesn't mean that it's neither possible or
particularly difficult to do.

Much of the solution is to implement stanza support in the configuration
file so we can provide configurations for each project. Then we need to
have a means for issues to tell us what distrobution to
add/modify/delete a build project - I'd suggest the easiest is to add
this to the issue title parser so we'd do "buildadd maemo" to add a
maemo-job.

The parts of the jobs that would change is we'd need to define the
package mirrors used for the builds and how and where the repo-job
uploads the end result. This is not a particularly hard thing to
achieve either. Potentially we could even have a single definition that
would allow us to have one set of jenkins templates and use the first
part of the branch name to determine which project we are building for -
so instead of branch name "suites/jessie" we'd use "devuan/jessie",
"maemo/jessie" etc, and this could allow a maintainer to use a single
git project and jenkins job to maintain different package profiles
across multiple distrobutions.

I think that if we did this we'd also need to rename the jobs to
"<distrobution|group>_<packagename>-<source|binary|repo> so we'd have
Devuan_debootstrap-source-job which then allows for
Maemo-debootstrap-source-job to have a separate package if it's
maintained separately to the devuan package.

I don't think it's a particularly difficult problem. If you think it's
too hard then the other option is to go and setup a separate jenkins
server and releasebot instance for the other distrobutions, and then
filter the issues by group. If you wanted to use the existing jenkins
we'd need to deal with the job-name clash by prepending the groupname
into the jobnames in jenkins which would be a trivial patch to apply.

Let's discuss this further and focus on how to solve these problems.

If anything of the above is unclear let me know and I will clarify.

Cheers,
    Daniel.

--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722