Am 17.01.2018 um 20:57 schrieb Jacob Larsen:
> 1. Use Docker Slaves Plugin
>
> 2. Use Cloudbees Docker Custom build environment plugin
>
> 3. Use the Docker Pipeline plugin, specifically the .inside syntax
>
4. Use Docker plugin: Multiple Docker hosts, Container templates must be
defined either
I want to show the workitems from TFS associated to the current build using
a groovy script in jenkins, but the changeset objects doesnt include this
info, how can i get this info?
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To
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,
Am 17.01.2018 um 17:25 schrieb Ioannis Moutsatsos:
> The BUILD_ID (which up to this point was equal to BUILD_NUMBER) is now
> set to 'dontKillMe'
I dimly remember that this is a way to tell the cleanup code that kills
all processes after the build has finished to ignore certain processes.
On Saturday, April 29, 2017 at 5:06:32 PM UTC-4, Kaido Kert wrote:
>
> When i configure a pipeline multibranch build item, there is a Build
> Configuration: Mode dropdown in the UI, which frustratingly only offers 1
> option: Jenkinsfile.
> I'm guessing there is some plugin or mechanism to get
Thanks, that makes things a bit easier! Got the branch stuff now, although
checkout scm just pull the right things, I guess.
Still looking for an easier approach to the parallelization. But, more
importantly, unlike the other 'pipeline' project, this one doesn't have a
configuration section
Hello!
We need to share one Jenkins instance between several group of people and
designate "subadmin" per group.
We have several problems related to the node management. If we give admin
right for some node (Matrix strategy) the relevant user can update the node
config but:
1. There is no
I have recently upgraded to Jenkins v2.100 from v2.93 and all the security
plugins that came along for the ride.
The *upgrade broke all the jobs* where in Groovy scripts and properties I
was using the BUILD_ID environment variable to create unique names for
folders and files.
The BUILD_ID
Am 17.01.2018 um 13:27 schrieb Ana MB:
> I'm trying to erase old builds from my Jenkins, but I've found that in
> some tests, Jenkins doesn't delete old builds as I need.
Some things to keep in mind here:
* Log rotation is only done upon a new build
* Specific builds could be marked as keep
Hi guys,
I'm trying to erase old builds from my Jenkins, but I've found that in some
tests, Jenkins doesn't delete old builds as I need.
I'm doing it from here:
env.BRANCH_NAME is only populated when your job is from a Multibranch
Project type (which is probably a good project type to use for this kind of
building)
On Wednesday, January 17, 2018 at 10:45:53 AM UTC, Hiesgen, Raphael wrote:
> Thanks for the pointer! So, the recommended way is my third
Thanks for the pointer! So, the recommended way is my third option: Use a
Jenkinsfile? I got a few follow up questions.
> If you use Jenkinsfile, you can use BRANCH_NAME environment to detect whether
> it's from a PR or not. What you describes is pretty straight forward to do
> with Jenkins
In my pipeline's post{falure{}} block I want to report at which stage the
pipeline failed. Is there an env or something that tracks this?
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails
13 matches
Mail list logo
