I don't really ever weigh in on things but this time I'd like to.
I think its safe to say no one wants anything with a space or special
chars, due to obvious technical issues.
In that vein, 'Jenkins Server' could have such technical implications plus
it is very broad.
So we're left with one
Are you mis-matched in your pairing? Windows Server 2012 is in the Windows
8 family. Windows Server 2008 is the 'mate' to Windows 7, isn't it?
On Fri, Apr 10, 2020, 8:48 AM Tim Jacomb wrote:
> Sounds reasonable to me +1,
> I speak as someone who barely ever touches Windows and never for Jenkins
I'll start by stating that i don't know how Jenkins does it exactly -
you'll have to poke around the source to figure out its classloading tricks.
That said, i do know how you do it without special classloading tricks.
It is 2 parts - first part is to extract all jars involved in the servlet
, the admin user has every authorization checked.
On Wednesday, June 4, 2014 8:54:36 PM UTC-4, Ben Castellucci wrote:
Robert is correct - when delegating you are entirely subject to
authentication against the container. Jenkins handles no part of
authentication in this situation. It only handles
If login through gui works OK then try token based [1] and see if that
works.
Other than that I am stumped.
[1]
https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
On Jun 12, 2014 12:53 PM, Ben Castellucci ben...@gmail.com wrote:
A good test to see if jenkins properly
Castellucci ben...@gmail.com wrote:
If login through gui works OK then try token based [1] and see if that
works.
Other than that I am stumped.
[1]
https://wiki.jenkins-ci.org/display/JENKINS/Authenticating+scripted+clients
On Jun 12, 2014 12:53 PM, Ben Castellucci ben...@gmail.com wrote
It's been a while since I posted to this group and I'm not in a position
where I can actually try this to verify so bear with me...
Sounds like what you need is to deploy the war exploded. Easiest way to do
that us to just unzip it and deploy the resulting directory in tomcat or
similar app
Robert is correct - when delegating you are entirely subject to
authentication against the container. Jenkins handles no part of
authentication in this situation. It only handles authorization via
roles/groups which you sometimes have to tell the container to map. For
example, you have a user
Quick throw out here - how about JPA? Pretty DB-independent and can provide
its own schema creation scripts and such.
Not sure about sync-ing over time.
Maybe Apache's implementation (OpenJPA) for a friendly license?
Would keep plugin developers away from writing SQL (it's just POJOs) and
let
There is another email bouncing around on this list with the subject,
memory consumption of builds that sounds a lot like it is describing the
same behavior.
Was a change made after 1.485 to load all builds when a user navigates to
the main page vs on startup?
Is that the problem here?
Just my
Ima hijack this real quick just to throw in a few comments unrelated to
what is actually being requested...
First this looks like a really cool plugin. Nice job! I want to use this
but first...
It may be advantageous to offer a configuration option of using a
datasource via JNDI defined at the
Greetings.
In the same vein as [1], [2] and [3], but slightly different. No changes
ever show up for any jobs and I am seeing the following exceptions:
java.lang.RuntimeException: Change date could not be parsed
...
Caused by: java.text.ParseException: Unparseable date: 2012/08/24
17:11:48
,
Michael
-original message-
Subject: CVS Plugin Changeset Date Parse Exception
From: Ben Castellucci ben...@gmail.com
Date: 24/08/2012 20:16
Greetings.
In the same vein as [1], [2] and [3], but slightly different. No changes
ever show up for any jobs and I am seeing the following
Gotcha.
:)
On Aug 24, 2012 6:16 PM, Michael Clarke michael.m.cla...@gmail.com
wrote:
Next CVS plugin release.
-original message-
Subject: RE: CVS Plugin Changeset Date Parse Exception
From: Ben Castellucci ben...@gmail.com
Date: 24/08/2012 23:14
Thanks Michael.
Just a clarification
14 matches
Mail list logo