Yes, kind of...
The parameters are hidden in the "properties" structure. They will be
applied to the job when it runs, meaning that the first run will not
have these parameters defined. If you make your Jenkinsfile robust for
undefined parameters, it should be doable, just remember that they
Looks like the agent image is the default one that was just set in the
latest release, see
https://github.com/jenkinsci/docker-slaves-plugin/commit/2d0470b27a84ddff00c3e1adc7aec9b7e8dece00
Take a look at the Docker Slaves section of the global Jenkins
configuration. The remoting image is
Wouldn't you need a Windows SCM image as well?
On 2017-08-12 18:56, nicolas de loof wrote:
I think you just miss a Jenkins agent docker image for Windows
architecture, everything else should work (linux style paths aren't an
issue afaik)
Le 11 août 2017 16:37, "Thiago Carvalho Davila"
I agree. Extending the base image is the way to go. Alternatively, you
can use a clean image for the master and set up slaves with ruby,
labeled appropriately.
/Jacob
On 2017-07-27 16:02, Mark Waite wrote:
I would be very surprised if the Jenkins docker image were extended to
include ruby.
iption: '')
string(name: 'branch', defaultValue: 'dev', description: '')
}
you may load some properties from a file and use those variables
for defaultValue...
AM
On Thursday, 3 August 2017 04:13:54 UTC-4, Jacob Larsen wrote:
Yes, kind of...
Sounds like you need something that isolates the "Jenkins Slave"
functionality from your build environment. I see these solutions:
A new machine with the Jenkins Slave that does SSH to your CentOS 5
build environment in the build step.
Put your CentOS 5 build environment in a Docker
If you look at https://jenkins.io/download/lts/ there is a link to
https://jenkins.io/event-calendar/ where you can see the schedule.
/Jacob
On 2017-06-19 17:49, Tammy Osborn wrote:
I happened to see some info in another thread for this group that the
next LTS release is 2.60.1
But I
a
named volume as jenkins home instead of a host mount in order to support a
jenkins slave running in a sibling container.
Any advice?
/Jacob
Den fredag den 26. maj 2017 kl. 00.08.23 UTC+2 skrev Jacob Larsen:
>
> Does anybody know what will happen to the Docker Slaves plugin? It looks
Does anybody know what will happen to the Docker Slaves plugin? It looks
like development has halted when looking at commit activity. I took a look
at the Dockins stuff, but it looks like that is just as dead. Does anybody
know where I should look if I have these requirements:
* The jenkins
Have you tried just adding the gerrit trigger for change merged instead of
polling SCM?
Also, your condition looks wrong, try this:
if [ -z "${GERRIT_EVENT_TYPE}" ] || [ "$GERRIT_EVENT_TYPE" ==
'change-merged' ]
/Jacob
Den tirsdag den 23. maj 2017 kl. 20.58.51 UTC+2 skrev John Mellor:
>
> I
What happened to the debian version of the official docker image named
jenkins/jenkins:lts? When I pull that image right now, I get an image
built on alpine. Was there an official decision to switch I could not
find any mention of, or was it overwritten by mistake?
/Jacob
--
You received
Yes. Put this snippet into a .groovy file, e.g. usercreate.groovy:
instance = Jenkins.getInstance()
def hudsonRealm = new hudson.security.HudsonPrivateSecurityRealm(false)
hudsonRealm.createAccount("admin","Password1234")
instance.setSecurityRealm(hudsonRealm)
def strategy =
I wouldn't use Docker Slaves for this. Just install the docker client in
your Jenkins image and bind mount /var/run/docker.sock. Then a simple sh
step with docker build + docker push should do the trick.
If you don't want to use your jenkins master for this, you could make a
slave container
Here is a list of the options I know, but one important aspect to this
is if you use pipeline or not in your builds as that affects your choices:
Docker Custom Build Environment Plugin. This will use an existing
executor to launch a container with the build. The images used need not
be aware
On 2017-12-05 09:03, nicolas de loof wrote:
2017-12-04 21:38 GMT+01:00 Jacob Larsen <ja...@larsen.net
<mailto:ja...@larsen.net>>:
Here is a list of the options I know, but one important aspect to
this is if you use pipeline or not in your builds as that affects
. The one property shared with the 3 first solutions is that
they only need the build environments themselves, as the slave daemon
runs outside this container.
/Jacob
On 2018-01-18 07:41, Dirk Heinrichs wrote:
Am 17.01.2018 um 20:57 schrieb Jacob Larsen:
1. Use Docker Slaves Plugin
2. Use
There are 3 ways I know of that allows you to avoid having the Jenkins
slave dependency in the container:
1. Use Docker Slaves Plugin
- Has some limitations, but works for the most part. Supports
pipeline at least partially, and can run on dockerized slaves. Will not
run directly on
Hi
After upgrading a bunch of plugins, I have noticed a number of warnings
in my Jenkins system log. Every 3 minutes, I see a bunch of these:
com.cloudbees.jenkins.GitHubRepositoryName create
WARNING: Could not match URL ssh://192.168.42.13:29418/jenkins-util
This is the place where I store
18 matches
Mail list logo
