Alioth moving toward pagure [LWN.net]

Alioth moving toward pagure

Posted Jun 14, 2017 18:12 UTC (Wed) by drag (guest, #31333)
Parent article: Alioth moving toward pagure

Getting CI features is a big big win. Since they are not going with GitLab it would be well worth their time to look into making a CI service that will compliment pagure.

Right now it looks like Pagure wants to work with Jenkins for CI, which is probably fine. Jenkins is widely known and used. But I really like the simple 'pipeline' style development were you have a yaml file or json file that you throw into the root directory of your git repository that describes the steps to perform when you want to test build/updates.

to post comments

Alioth moving toward pagure

Posted Jun 14, 2017 20:48 UTC (Wed) by kfox1111 (subscriber, #51633) [Link] (9 responses)

Supposedly Jenkins supports the same kind of pipeline file now with the newest versions.

Alioth moving toward pagure

Posted Jun 16, 2017 4:23 UTC (Fri) by ssmith32 (subscriber, #72404) [Link]

"Jenkins is Java" ... And I guess that's a good enough reason to dismiss it out of hand??

Alioth moving toward pagure

Posted Jun 16, 2017 21:12 UTC (Fri) by k8to (guest, #15413) [Link] (7 responses)

Jenkinsfiles are horrifyingly awful.

The declarative version of them is extremely under-documented and you can easily find yourself in a situation where you can no longer do what you need using the declarative version of them. Also if you make any sort of syntactical error you get a completely incomprehensible java stack trace where you have to guess what you did wrong.

The imperative version is only fairly under-documented, and while you can almost certainly do what you need, you have to do it using the magic subset of Groovy that happens to work. There's so many undocumented assumptions in how they assume you'll wire your code together, that you spend your time wondering what the next stack trace means for days on end until you get something that works.

Jenkins also is awful independent of jenkinsfiles. In order to get the functionality you want, you'll have to install a number of plugins, and different projects will need different plugins, and they all mutate global logic, breaking each other and Jenkins overall. Unless you want to go through the process of providing a jenkins service per project, you'll be dealing with either the pain of an unreliable service, or the pain of a very hamstrung and degenerate service that doesn't do what the projects need.

If you choose to go down this road anyway because it's "the default", then good luck for you and I hope you don't experience what I deal with every day.

Alioth moving toward pagure

Posted Jun 19, 2017 8:36 UTC (Mon) by zanchey (subscriber, #94250) [Link] (6 responses)

I'm looking at options for build & deploy systems, and every comment on Jenkins seems to be along these lines - that easy bit is really easy, and the hard bit is mind-boggling hard and inflexible. I'm just not sure that there's better options...

Alioth moving toward pagure

Posted Jun 19, 2017 21:40 UTC (Mon) by yoe (guest, #25743) [Link] (5 responses)

You should look at buildbot. Its master config file is a python script which gets executed, and which builds a set of objects in memory that describe the configuration. This allows for an awesome flexibility; yet at the same time, buildbot ships with a wide swath of classes to help you build that configuration that it's pretty easy to deceive yourself you're not writing python, and that this is just a declarative configuration file (which is a good thing, in case that wasn't clear). The documentation is pretty awesome, too.

Python is much more lightweight than Java is, and it's actually portable to pretty much everywhere.

I use buildbot to automatically build a particular piece of software for Windows, OSX, and various distributions through a number of libvirtd VMs on a single machine (apart from the OSX builds), and release them with version numers based on tags (but granted, my master.cfg is rather complex). I've gone on record saying that I'm not a fan of python, and I in fact have often switched away from particular pieces of software because they were written in that language. I'm very glad I haven't done that with buildbot...

Alioth moving toward pagure

Posted Jun 25, 2017 13:07 UTC (Sun) by paulj (subscriber, #341) [Link] (4 responses)

+1 on buildbot. It's relatively light-weight and easy to install. The python configuration makes it very easy to customise (and I'm not a big fan of python either). It has a clean and logical design. The documentation is pretty good. It can spin up VMs on demand.

It's a great bit of software.

Indeed, I could see it being very useful for wider system-orchestration tasks, beyond just CI.

Alioth moving toward pagure

Posted Jun 25, 2017 19:38 UTC (Sun) by yoe (guest, #25743) [Link]

Oh yeah, that's definitely possible. Buildbot allows you to run whatever you want through the shell build step. Something like 'build, run tests, if tests are successful then commit something in puppet repository so that hosts are auto-updated to install this version from the git commit id' seems very achievable, easy even. And you could limit that do that it would only try to do that for tagged commits or commits on a particular branch, for instance.

Alioth moving toward pagure

Posted Aug 2, 2017 19:20 UTC (Wed) by rurban (guest, #96594) [Link] (2 responses)

-1. I used buildbot for a couple of years, until it got hacked. twisted is insecure.

Alioth moving toward pagure

Posted Aug 3, 2017 3:18 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

The web interface? You don't have to expose that if it's sending status updates to your repository. Or hacked through some other means?

Alioth moving toward pagure

Posted Aug 3, 2017 5:45 UTC (Thu) by mbunkus (subscriber, #87248) [Link]

Can you be a bit more specific,please, so that those of us running Buildbot can take appropriate countermeasures? Thanks.

Alioth moving toward pagure

Posted Jun 16, 2017 7:01 UTC (Fri) by nhippi (subscriber, #34640) [Link]

Pagure supports webhooks, so I think it's matter of just implementing? furthermore, Since Debian pagure is debian-specific, the CI could be 0-configuration - build package, run unit tests, run autopkgtests.

Alioth moving toward pagure

Posted Jun 16, 2017 11:54 UTC (Fri) by guillemj (subscriber, #49706) [Link]

There are already at least two such services in Debian that I'm aware of (but there might be more, in Debian with this things you never know :):

<https://ci.debian.net/>
<https://jenkins.debian.net/>

Well, there's also <http://travis.debian.net/>, which is strictly speaking not a service on its own, and will (I'd assume) never be made official.