I can enlist another pain point I faced while implementing the pipeline for
log4net. I had to find a way of detecting the uid/guid of the jenkins user
to make it work with dotnet core commandline inside docker. That really got
my head aching and as far as I can remember stemmed from the fact that the
dotnet commandline was unable to the detect the home directory and
attempted to write files into places of the filesystem that it was not
supposed to. If this ran on a disposable environment one would simply don't
care where a build writes stuff into because the machine is going to be
disposed of anyway, either on build success or failure or timeout. Since
then I recommend to wrap builds into virtualbox machines. That works very
well with gitlab-ce.
--
Dominik Psenner

On Fri, Jan 11, 2019, 18:47 Allen Wittenauer
<a...@effectivemachines.com.invalid wrote:

>
>
> > On Jan 10, 2019, at 11:28 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> >
> > On Fri 11 Jan 2019 at 06:28, Joan Touzet <woh...@apache.org> wrote:
> >>
> >> I'm willing to believe that Jenkins, the software, is incapable of
> >
> >
> > I assume you meant capable rather than incapable.
>
>         Nope, I agree with Joan: incapable is probably the correct word.
>
>         I’ve lost track of how many issues I’ve hit just in the past week
> of missing or broken features. [1]  It’s very clear (esp with Blue Ocean
> and Pipelines) that Cloudbees is trying very hard to push people into a
> very simplified model of CI.  Anything complex either can’t be done or
> requires so much work that it isn’t practical. [2]
>
> >> What about buildbot? Or another technology we could use with INFRA's
> >> support? Last time I looked at buildbot, its integration with Docker
> >> was very poor.
> >>
> >> I don't have any special attachment to Jenkins.
>
>         IMO, this is probably something we as a community should look into
> doing.  We’re pushing Jenkins way harder that what it feels like it was
> designed to do, given how many issues we hit on a regular basis and some of
> the core limitations of the platform.
>
>
> 1 - My current favorite being JENKINS-17116, which I’ve hit in both
> freestyle and pipeline jobs to the point that I ended up writing pid
> handling because I can’t trust Jenkins to actually signal processes
> properly.
>
> 2 - JENKINS-27413… and Glick’s answer just re-affirms in my mind that
> Jenkins is getting dumbed down: why push this off to a plugin?
>
>

Reply via email to