On Tue, 3 Nov 2015 15:33:36 +0100
Lukas Ocilka
Moin,
I've been working on this task ($SUBJECT, https://trello.com/c/Rg7bI6rP/367-3-add-libstorage-snapper-to-jenkins) for some time and implemented a simple but ugly solution:
1. New Jenkins project: https://ci.suse.de/view/openSUSE/job/snapper/configure 2. New simple Rakefile at https://github.com/kobliha/snapper/tree/jenkins_support 3. Several newly installed packages at vm-yast-ci-worker (automake, libtool, gcc-c++, libmount-devel, dbus-1-devel, libacl-devel)
This is for me the most ugly part. There is huge risk for us to again hit problems like: 1) package is for Leap, but versions above is for factory 2) worker do not have recent enough versions, so we do not detect problems earlier 3) we have to maintain it on server side. That is reason why we introduce idea of simple git tarball and using osc to do all generation, building and other steps.
4. make -f Makefile.repo && rake osc:build
This currently SUCCEEDS! :)
Yast projects have .spec files in their /package directories, but snapper has snapper.spec.in and the .spec file is then generated on-the-fly. Although the current Jenkins solution is really ugly as it brings too many new dependencies into the infrastructure, it's a step forward (at least I hope so). So, what do you think of that? How bad is 'bad', how ugly is 'ugly' :)?
For me nice step forward, but we really have to remove such dependencies in tarball creation process. Josef
PS: If you can't access some pieces of the infrastructure, then you just can't, and I'm sorry
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org