On Tue, 3 Nov 2015 15:33:36 +0100 Lukas Ocilka <[email protected]> wrote:
> 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: [email protected] To contact the owner, e-mail: [email protected]
