4 ms·
Well - I dealt quite a bit with Jenkins shared libraries when porting jobs from Jenkins 1.x to Jenkins 2.x recently. Declarative pipelines are often too restric
by nuclx 8y ago
Well - I dealt quite a bit with Jenkins shared libraries when porting jobs from Jenkins 1.x to Jenkins 2.x recently. Declarative pipelines are often too restrictive leading to a mixture of declarative and embedded scripted pipeline scraps. In the end I would have preferred to be able to program the pipeline with python.
The only reasons to still use Jenkins in 2019 are SCM polling and e-mail notification. For manual builds I just use python with fabric for remote builds.
- itielshwartz 8y agoI wrote the "only reasons" as I see them, feel free to correct me. Also we use scripted pipeline all the way
- nuclx 8y agoI guess the reasons depend on the environment, in my case a multi-platform embedded product. E.g. in my case I don't have a use for dynamic node instantiation. Testing partly requires fiddling with hardware and diverse system architectures, so these parts have to be done manually. Delivery bundling isn't fully automatable as well, so there isn't a place for Jenkins in the go-to delivery pipeline I have in mind. It would just complicate things imho. So what's left is SCM-based triggering of builds, unittests, dynamic tests (valgrind, sanitizers) and system tests.