On 24/07/17 23:32, KatolaZ wrote:
> On Fri, Jul 21, 2017 at 12:15:05AM +1200, Daniel Reurich wrote:
>
> [cut]
>
>>
>>
>> Lets instead take a look at how it currently works.
>> - So to start off with, devuan-releasebot does 2 jobs. It sets the
>> jobs, and it triggers the jobs. Setting up the jobs consists of
>> providing a bunch of parameters and little snippets of script that are
>> laid on templates that make up the jenkins jobs. The builds themselves
>> various bits of script provided via jenkins-debian-glue that do the
>> actual work of building sources and packages. The built packages to are
>> deployed to the respective repo in the repo job that has a script that
>> signs and uploads the files to dak and then tells dak to get to work.
>>
>
> Hi Dan,
>
> we think we have understood how releasebot works now, and parazyd and
> I are working to integrate it with scorsh to start testing it

Ok... can you lay out the changes your proposing for devuan-releasebot?

> What remains unclear to me is how jenkins-debian-glue needs to be
> modified in order to support more than just one distribution. Looking
> at the commits on git.devuan.org, the Devuan configuration for
> jenkins-debian-glue is the stuff in the "devuan/" dir.
>
> Now, is it possible for the same jenkins installation to use different
> jenkins-debian-glue configurations to put stuff into different repos?
> If so, can this selection be made by using a parameter to the build
> command?

It's look in the releasebot jenkins_tpl folder for the job templates.

I think it's best to do a separate sources.xml for each repo type (dak
reprepo, minidak etc) and then configure it either via labels, or
perhaps setting flags in the issue title or description box.
>
> I am sorry if my questions look trivial, but I couldn't find anywhere
> a proper doc explaining what is the current jenkins-to-dak setup in
> Devuan.

If you don't ask questions then you're more likely to make wrong
assumptions.

I'm not against you developing a new and potentially helpful tool, but
was a bit peeved about the way that it was portrayed as a replacement
when you clearly didn't understand (and still don't it seems) the full
picture of how things work. Even I don't fully understand it all, but I
have studied it in depth over the 2 years I've interacted with it.

Perhaps chatting to nextime and me about what the actual goals for
scorsh are might be useful.

To be honest, I'm also a bit miffed at the departure from using python
which is used in all the other parts of the infrastructure that nextime
has built. It sets up immediate barriers to entry for me (I haven't
explored go yet) to understand and interact more deeply in the code you
write.

My feeling is that we should settle on python as the language of choice
for all devuan infrastructure tooling we build unless there is a
compelling reason for a departure. So why does scorsh need to be
written in go instead of python? What compellling feature does scorsh
need that python lacks?? This is not an attack, but a legit question
highlighting that you or I may not be the ones maintaining this code in
the future and adding random programming languages shouldn't be done
without considering the maintenance burden.

Cheers,
    Daniel.

>
> HND
>
> KatolaZ
>
>
>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>


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