This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Fri, Mar 03, 2017 at 07:27:16PM +0100, Max wrote: > Hi. > > Right now we have rather sophisticated CI/CD setup which is spread over > several services (OBS for nightly packages, jenkins for CI) and > repositories. > > It works well, but if I've got to somehow extend/alter it than I have to > look in at least 3 different places: > - ocmo-ci repo for common scripts > - jenkins job in jenkins web ui > - project's jenkins*.sh scripts > > I think it's not meant to be that way, it's just what has grown organically > over the years. > > Right now we use recent enough jenkins which support Pipelines [1] plugin. Well, whaddaya know, one of the accelerate3g5 contestants actually wanted to help introduce Jenkins Pipelines. Sounds like it's going to happen :) dr.blobb, could you join the discussion please? About the distribution of scripts: the osmo-ci has common scripts, and each project's jenkins.sh has project-specific steps in it. Either we keep all project-specific details in one central place instead of with the project (where one might say it belongs), or we copy the osmo-ci scripts to every project duplicating the code -- I don't really see a way to get out of that part... But I've been annoyed by having to edit a dozen different repositories to tweak the same detail in each jenkins.sh (like adding that value_string check), so keeping all jenkins.sh in one central place has occurred to me several times before as being a good idea. It has the disadvantage that you can't change jenkins.sh at the same time as a patch changes the behavior (like your --enable-sanitizer change in libosmo-abis, which was all nicely applied in one patch), but so far the disadvantage of having to edit N separate repositories has far outweighed that for me. > I suggest following: > - enable Pipelines plugin in jenkins > - configure new pipelines-based job pointing to non-master branch which we > can use as a playground > - once we comfortable with it - migrate existing CI (and possibly CD) to > pipelines (as time permit) > - switch gerrit from old jobs to new pipelines > > What do you think? sounds excellent. > - we'll have actual CI job description under version control (right now it > just sits in web ui) except for the parts we relayed into the jenkins.sh scripts for the same reason -- but this includes the job config as well, right? which sounds excellent. I'd trade any web interface for text files any time. > - we'll have single place to look for CI-related things (ok, maybe 2 places > if we still need common library) ah ok > - it's more eye-candy (it's clear which build step we're in and how long > each step took) > - it's easier to parallelize (e. g. run sanitizer and regular builds in > parallel) how does this come about? Separate workspace per pipeline run? The point being: does jenkins keep separate network interfaces for each? Our 'make check' often starts up things on ports that must not be reused. That's why docker was such an improvement for the openbsc job. Ah, I see that pipelines can actually integrate with docker as "agent"! > On a related note: in general, who's point of contact for things like > "please update jenkins plugin X to version Y"? I guess Holger or me, but the decision whether to do that is probably more with Holger and Harald, besides the community at large. > [1] https://jenkins.io/doc/book/pipeline/ > [2] https://jenkins.io/doc/book/pipeline/jenkinsfile/ One thing that catches my attention: do we have to trade shell script for groovy scripting? That would be a potential drawback, because we're familiar with shell, not with groovy. Groovy is very Java, we're more C and sh. It seems that shell commands become sh 'ls -alh' so I guess we would put everything except one-liners into an actual .sh file and call that from the jenkinsfile. I wouldn't want to shell-script with prepending 'sh' everywhere and losing all of the env on every line. Overall I would +1 pipeline trials. The jenkins.osmocom.org plugin page though says: " Pipeline A suite of plugins that lets you orchestrate automation, simple or complex. See the Jenkins website for more details and documentation. <red>Warning: This plugin requires dependent plugins be upgraded and at least one of these dependent plugins claims to use a different settings format than the installed version. Jobs using that plugin may need to be reconfigured, and/or you may not be able to cleanly revert to the prior version without manually restoring old settings. Consult the plugin release notes for details.</red> " whatever that means in practice. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170304/23f721ea/attachment.bin>