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/.
André Boddenberg dr.blobb at gmail.com>> This sounds to me like Pipelines don't actually provide any of the features I >> was dreaming about, except maybe easier docker integration? first yes! second as you said -> maybe, still doubting it :) When we speak about the "easier docker integration", we mean that everyone would be happy if not every matrix-configuration axis builds all deps like libosmocore, libosmo-netif etc pp, right? To address this issue I'd like to create a local temporary docker image which extends osmocom:amd64 and holds all deps. This image can then be used for all openBSC builds and the temporary local docker image can be removed as a "post-build"-step (which should get triggered regardless the build result). A slightly different topic, did you think about pushing your docker images to hub.docker.com [2]? In my opinion this will be a step forward to a transparent and local reproducible build environment. Afair Harald was quite clear about this requirement? >> and "Wiki" is an ancient African word for "hopelessly outdated"... >> We appreciate every checked and/or corrected facts on those pages, >> and the Jenkins_Node_Setup could probably be merged into the Jenkins one. Thanks for pointing this out, usual I am hesitating to correct something to avoid being called nit-picky. >> >> [2] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin >> This sounds like we want to use it! Alright, so I will work on the following migrations: - "as is" -> "JobDSL" - "as is" -> "Pipeline" (probably just for Max) >> so far that doesn't look like an improvement of >> #!/bin/sh >> ./contrib/jenkins.sh Agreed, the biggest advantages of Pipeline are: - the "eye-candy" (but who cares? :) - easy artifacts sharing across different steps, which run on different nodes (but afaics you don't even use the "Copy Artifacts Plugin", which makes this argument pointless). - the duration/sub-steps can be easily seen (as mentioned by Max), but this can be achieved which some simple python scripts/plugins + influxDB + grafana as well. Neels, can you please help me fixing the following build error [3]: 01:59:20 checking dbi/dbd.h usability... no 01:59:20 checking dbi/dbd.h presence... no 01:59:20 checking for dbi/dbd.h... no 01:59:20 configure: error: DBI library is not installed 01:59:22 Build step 'Execute shell' marked build as failure 01:59:22 [WARNINGS] Skipping publisher since build result is FAILURE 01:59:22 Finished: FAILURE I already added the following package to the image, by: docker run ........ osmocom:amd64 /bin/bash -c sudo apt-get install -y r-cran-dbi; /build/contrib/jenkins.sh but the r-cran-dbi package doesn't solve the issue, which package is needed? Why is this build dependency not part of the Docker image? André [1] https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin [2] https://hub.docker.com/ [3] https://jenkins.blobb.me/job/openBSC_multi-configuration/label=master/36/console 2017-03-06 14:53 GMT+01:00 Neels Hofmeyr <nhofmeyr at sysmocom.de>: > On Sun, Mar 05, 2017 at 10:03:20PM +0100, Klaus Müller wrote: >> Hi, >> >> >> So, what would be the actual benefits? >> >> >>* complete job config in git? (to be confirmed) >> >> Just to clarify, the Pipeline plugin on its own doesn't provide a >> complete config handling in git. This means only the code shown in >> image [3] lives in git, configurations within the "General" or "Build >> Triggers" tab will still be handled in the web-ui.*** >> For the sake of completeness the JobDSL plugin [2][ has to be mention. >> This plugin allows to put the entire job configuration to git and >> deploys jobs without previous manual setup in the web-ui. >> >> >>* faster because less things have to be rebuilt? (to be confirmed) >> >> Somehow I doubt that this improvement dependents on the Pipeline >> plugin, but I know to few details to have an opinion based on facts. >> :) >> >> >>* faster because easily parallelizable/easier integration with docker? (to be >> >> confirmed) >> >> first point: e.g. Pipeline can trigger "down-stream-projects/stages" >> after one specific part of a >> parallel-block/matrix-configurations-project is finished. >> >> second point: Pipeline brings a docker wrapper, so one don't have to >> pass one build script holding the entire build sequence when invoking >> the container. You can invoke as much scripts as you want within the >> docker wrapper. (no black-box god-script :) > > This sounds to me like Pipelines don't actually provide any of the features I > was dreaming about, except maybe easier docker integration? > >> Is this mailing list the appropriate communication channel? > > yes. > >> Is there already a osmocom ci wiki page, which I overlooked? I'd be >> happy to contribute! > > well, searching osmocom.org for jenkins gave me > > https://osmocom.org/projects/cellular-infrastructure/wiki/Jenkins > https://osmocom.org/projects/osmocom-servers/wiki/Jenkins_Node_Setup > https://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds > [...] > > and "Wiki" is an ancient African word for "hopelessly outdated"... > We appreciate every checked and/or corrected facts on those pages, > and the Jenkins_Node_Setup could probably be merged into the Jenkins one. > > >> [1] https://jenkins.blobb.me/view/osmocom/ > > nice, a sleepy pipeline ;) > >> [2] https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin > > This sounds like we want to use it! > >> [2.5] https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.DslFactory.pipelineJob >> [3] http://tinyurl.com/zbavrtp > > direct link without javascript cruft: https://media.comsysto.com/images/2016-11-23-jenkins-pipelines/new-jenkins-pipeline-config--c.png > > so far that doesn't look like an improvement of > > #!/bin/sh > ./contrib/jenkins.sh > > ~N > > -- > - Neels Hofmeyr <nhofmeyr at sysmocom.de> http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschäftsführer / Managing Directors: Harald Welte -- Gruß Blobb