Greetings fellow Jenkins users.
I have just pushed v0.4 of snowglobe-plugin for jenkins, I thought this is
the point at which it is possibly useful for others treading down the same
path as us.
We develop software which is shipped as Docker images, which is neat. But
what starts out as a simple '
Yes, there are restrictions.
See https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document - the
section on Trademark should give you a guide as to next steps.
On Thu, Sep 1, 2016 at 12:25 PM, Ioannis Moutsatsos
wrote:
> Greetings to all;
>
> We have developed a number of scientific appl
l Tool
> Configuration" under the "Git installations" section. You can set the git
> location from that spot in the configuration and give that new git
> installation a distinct name ("win-git"). Then assign "win-git" git
> scm.gitTool and see if tha
The host it builds on is not under my control.
Is manipulating fields in scm not supposed to work?
On Thursday, 28 July 2016, nicolas de loof wrote:
> Any reason you don't set git in default path ? Would be so simpler ;)
> Le 27 juil. 2016 10:56 PM, "Nigel Magnay" > a
ur git executable to be "git" rather than
> "/usr/bin/git"? That's what I've used in multi-platform environments and
> it has worked well for me.
>
> Mark Waite
>
> On Wed, Jul 27, 2016 at 1:57 PM Nigel Magnay
> wrote:
>
>> In a bitbucket-sour
In a bitbucket-sourced multibranch repository, I need to ensure the git
checkout doesn't occur with /usr/bin/git, but with a tool that stands a
chance of executing on Windows.
I had rather hoped it would simply be the case of doing
scm.gitTool = 'win git';
before my
checkout scm
But it still se
What we do is look at what the branch name is in the Jenkinsfile itself.
I.E:
if( branchName.equals("master") )
{
// deployment steps
}
On Fri, May 13, 2016 at 12:24 AM, Mike Caspar
wrote:
>
> I am working on a pipeline that does Test/Deploy after a commit.
>
> That's all cool!
>
> However.
You can't.
What you can do is if your build is A->B->C, you can specify C's upstream
repository as 'repositoryChain', so it will include both A and B (where B
takes priority over A).
You could can extend the rules - possibly even with different resolution
rules, but it's not something anyone has
>
>- *Issue* - the container is left behind...is there anyway to automate
>removal of the containers from within Jenkins?
>
>
>
It should be removed when the jenkins build itself is removed.
> The next issues I have are:
>
>- How to mount the workspace into the container.
> -
If you are, like me, living (on the bleeding edge / the dream) that is
workflow-multibranch, you may have scenarios where you need to manage
triggering of downstream builds.
In particular, if you have multiple (dev, release) branches of an upstream
project, leading to multiple (dev,release) branch
Is it possible for workflow-multibranch jobs to take parameters?
I have a similar requirement where I'd like a 'parent' workflow job to
trigger some number of downstream child jobs, probably with something like
(despite the warning in the snippet generator, I don't care to wait for the
outcome or
lly <
stephen.alan.conno...@gmail.com> wrote:
> That sounds like you need the "James Nord operator"
>
> Workflow can do that, because the specific use case was requested by the
> person it was named after
>
>
> On Monday 12 October 2015, Nigel Magnay wrote:
&
ld help.
>
> I'd get the current branch and only run the ITU stage only if it's
> currently working on master.
>
> Vincent
>
> 2015-10-12 13:05 GMT+02:00 Nigel Magnay :
>
>> I'm migrating a lot of fairly hairy infrastructure around to use
>> jerk
I'm migrating a lot of fairly hairy infrastructure around to use
jerkins-workflow.
At the moment, we have a number of projects that use triggering: -
proj-build
proj-ITU
proj-robot-tests
What I want to migrate is - proj-build builds every commit. proj-ITU is
very expensive, so it gets triggered
and
>>> other mailinglists).
>>>
>>> Is there somewhere a "Best Practices with Jenkens and JobDSL in 2015"
>>> reference?
>>>
>>> With regards,
>>>
>>>
>>> Nick Stolwijk
>>>
>>> ~~~ Try to
It's probably what stephen says -- when I wrote the plugin was some time
ago - either before (or before my awareness of) multi-branches and other
non-root project types. Probably not a big fix..
It's also (currently, but am fixing) tied to the 'evil job type' :-)
You might find workflow-plugin be
>
>
> Don't use forks, use branches.
>
> Forks are good to allow people to contribute w/o being members of a
> projects (i.o.w. w/o granting them push permission). This is not the case
> for GH Enterprise, where all your devs are members of your project, aren't
> they?
>
>
Access control to the rep
Build a slave image with a copy of the git repository and any known
artifacts within it. Then the build will only be fetching the diffs.
On Fri, Apr 24, 2015 at 4:18 PM, krishna kunapuli
wrote:
> Hi,
> I was able to setup Jenkins running in a docker container and configure
> plug-in to kick of
You could try the beta-1 version in the experimental jenkins update centre
- though the error there looks like a connection failure.
On Thu, Apr 16, 2015 at 10:13 AM, Jānis Balodis
wrote:
> Hi,
>
> I've experienced a similar behaviour, but with docker plugin v 0.8 and
> Jenkins starting from ver
So, launching slaves based on a dockerfile looks like a particularly useful
enhancement (particularly as a personal usecase has recently popped up,
which involves compiling embedded code with highly specific versions of
GCC).
My question is, why not merge it into the main docker plugin?
On Tue,
Maven builds?
On our install, we saw pretty much the same behaviour, which was down to
slow disk, and memory pressure. Basically when memory gets short, things
needed for the home view get binned, making the reload expensive.
If you can do without them, rm -rf'ing the fingerprints directory and
r
> Nexus proxy next to the slaves.
Do you have a lot of maven project builds?
Stop Jenkins
cd ~/.jenkins/fingerprints
rm -rf *
Start Jenkins
Our install is like 1/100th the size of yours, and that alone saved 450Mb
of memory.
--
You received this message because you are subscribed to the Google
>
>
> Also there seems something strange is going on in that it seems to start a
> container, and then seem to switch to another container before the build
> kicks off. I haven't been able to troubleshoot this behaviour yet but
> wonder if something like that is expected?
>
>
Yes, there's a few od
>
>
>
> My question is whether Docker's lightweight nature also allows better
> exploitation of Jenkins' master-slave paradigm. Under this, I might expect
> that several Docker slaves on some slave Docker host could run in parallel.
> Thus, test suites would be broken down and run in parallel on a
> The docker plugin deals with images not containers - basically it does a
> docker run on the image, and then can, optionally, keep the container at
> the end of the run (but cannot be reused in a subsequent job I believe)
>
> It currently always tears down the container at the end of the Jenkins
I made the error of upgrading my Jenkins installation, and now I'm getting
my slaves dying with an OOM (which it's never done previously):
java.io.IOException: Unexpected reader termination
at
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:76
>
>
>>
>> From your reply, I am even more concerned with disproportionally high
>> number of the blocked threads (120) compare to offline slaves (2 at the
>> time), as it sounds like it should be closer to 1:1?
>>
>
> Yes, it sounds like there is a race condition between the post disconnect
> tasks
Interesting:
http://www.thoughtworks.com/news/go-continuous-delivery-now-available-as-free-open-source
Thoughts / experiences ?
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, s
unctionality? I can't see the utility of
it, and it's making the system totally unusable.
On Wed, Dec 11, 2013 at 5:55 PM, Nigel Magnay wrote:
> I've just cracked out MAT on a oom dump from our machine, and I can
> confirm that it looks like OldDataMonitor is the culprit
I've just cracked out MAT on a oom dump from our machine, and I can confirm
that it looks like OldDataMonitor is the culprit here, too (750Mb of
retained heap).
There's over a million entries in the hashmap...
On Mon, Dec 9, 2013 at 4:32 PM, Tim Drury wrote:
> I'm doing a heap-dump analysis
Interesting - we use the disk usage plugin too, though had disabled it
(thought not removed it).
On Mon, Dec 9, 2013 at 5:13 PM, Robert CHAVANNE
wrote:
> Tim Drury gmail.com> writes:
>
> >
> >
> > I'm doing a heap-dump analysis now and I think I might know what the
> issue
> was. The start of
For us, I think we actually have several things going on -
- something is taking far more memory - bumping up Xmx significantly seemed
to help, though ..
- this was then causing the host (smartos / solaris) to run out of swap,
because of fork(). So I had to significantly raise tmpfs too.
- we ha
Yes, we're seeing the same.
Our jenkins install is currently unusable :-(
On Fri, Dec 6, 2013 at 1:33 PM, Tim Drury wrote:
> We updated Jenkins to 1.542 two days ago (from 1.514) and we're getting a
> lot of OOM errors. (info: Windows server 2008 R2, Jenkins JVM is jdk-x64-1
> .6.0_26)
>
> At
Hi -
We have many jobs that work correctly, but one maven (integration) job is
displaying weird behaviour.
It runs correctly, it reports 'artifacts being archived'. These appear in
the .jenkins directory in the place I'd expect. However, the left-hand
sidebar reports a build size of '1 MB', and t
ick, but it seems to obsessively re-build a random
(seemingly the first alphabetical) branch.
On Tue, Oct 29, 2013 at 10:39 AM, nicolas de loof
wrote:
> This is fixed in HEAD, try using a SNAPSHOT build for git-client
>
>
> 2013/10/29 Nigel Magnay
>
>> So, doing some digging :
&
talled, and has never interacted with a Gerrit
>> instance.
>>
>> I don't have time to investigate the conditions which cause the bug now,
>> but hope within the next 24 hours to do some further investigation.
>>
>> Thanks,
>> Mark Waite
>>
>>
&
; Which of the repositories contain that SHA1? (Is it in the Gerrit repo
> and not in the Jenkins repo, or vice versa)?
>
> Mark Waite
>
>
> On Mon, Oct 28, 2013 at 7:01 AM, Nigel Magnay wrote:
>
>> Has anyone got the above combination to work?
>>
>> Our jen
Has anyone got the above combination to work?
Our jenkins seems obsessed with building wrong versions. I'm not sure which
of the vague "Usage with the Git plugin" options (here
https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger) are valid, and
our gerrit server is spitting errors such as:
Actually, I have also recently upgraded to the git plugin 2.0, and am also
seeing it repeatedly building (each time reporting many "SCM Change")
followed by it rebuilding the exact same SHA1 as the last time it was built.
Looks like a bug, but not sure exactly *where* yet..
On Thu, Oct 24, 2013
>
>
> I don't think that is how the Git plugin does what it does.
>
> I believe the Git plugin monitors multiple repositories and branch names
> for changes. If a change is detected in one or more repositories, the
> plugin merges those changes into its local branch, and attempts to run the
> job
y are being blocked by the build on jenkins-2 (they are not - jobs
are not tied).
When that job finishes, the queue drains, starting jobs on jenkins-1
jenkins5).
This is all very strange..
On Tue, Jul 23, 2013 at 10:54 AM, Nigel Magnay wrote:
> I have a job that has been running for a while,
I have a job that has been running for a while, and the sidebar reports it
as running on slave 'jenkins-2'.
This is an SSH slave. The connection, IP &c all look fine.
The job is taking a while, So I look at the logfile. It reports:
No such file:
/home/jenkins/.jenkins/jobs/gerrit-preflight/buil
I'm wondering if anyone has gone down this route before, and has any
experiences that they can share.
We're looking to possibly creating a new build server. It seems (to me)
that SmartOS would make an ideal host OS for running builds. (SmartOS is a
Joyent-derived Illumos(Solaris) derivative focuss
Hard to tell without some more detail -- wouldn't the jar name be the same
each time anyway?
You can probably craft something with a combination of copy-artifacts
plugin, maven repository server plugin and possibly a groovy script..
On Wed, Mar 14, 2012 at 7:05 PM, Nicky Ramone wrote:
> Did an
This is partially what the jenkins maven repository plugin [1] was built
for -- each build is exposed as a separate build repository, so you don't
need to go copying things around.
What we do is :
1) Install the plugin
2) Add the following to the jenkins settings.xml [2]:
3) In the downstream pr
45 matches
Mail list logo
