(replies inline)
On Thu, 31 Mar 2016, Richard Bywater wrote:
> It sounds to me like there's a good use-case for being able to skip the
> setup wizard even in "prod" mode? Is the jenkins.install.runSetupWizard
> ignored if development = false? If so would it make sense just to skip that
> check?
It sounds to me like there's a good use-case for being able to skip the
setup wizard even in "prod" mode? Is the jenkins.install.runSetupWizard
ignored if development = false? If so would it make sense just to skip that
check?
Richard.
On Fri, 1 Apr 2016 at 10:10 Baptiste Mathus
There's a sysprop for that, but normally only for development mode.
But, NOT FOR KIDS, you can confuse things by forcing it to dev mode.
Probably reasonable for continuously starting from scratch from the docker
container only, not for prod use obviously (beware that you may trigger
weird
Hello,
I am building a Docker container based on jenkinsci/jenkins:2.0-beta-1. I
am autofilling it in with jobs/pipelines but the annoying thing is that
every time I run the image I have to go through the setup wizard.
How do disable this wizard so that my container will just be up and
Anyone? Thanks again.
On Wed, Mar 30, 2016 at 4:52 PM, Guy Matz wrote:
> Hi! I have some groovy methods that I would like to make generally
> available to any jenkins job . . . does anyone have any recommendations
> for creating a library of methods and setting up jenkins
The git client 1.19.6 has been running since 3/22/2016 on the master
without errors, so it seems the feature to detect the jdk works as desired,
at least when run on the master. The class version issue only shows up
when we configure the job to run on a slave, It is also interesting that
the
You're correct that git client plugin 1.19.6 includes a jar file that is
compiled with JDK 7. The JGit support for symlinks requires it. However,
that jar file should not be loaded if it is running on a Java 6
environment. The JGit implementation is designed to allow the Java 7
module to only
That is a shame. I wont be able to move up to Git plugin 2.4.4. until the git
client issue is resolve. I realize you cannot reproduce, and I’m about to
leave for two weeks of well deserved vacation, so I won’t be able to pick this
up again for a while, but if someone else starts reporting
Git plugin 2.4.0 requires at least git client plugin 1.18.0.
Git plugin 2.4.4 requires at least git client plugin 1.19.6.
Mark Waite
On Thu, Mar 31, 2016 at 1:22 PM Michael Giroux wrote:
> Reverted Git Client to 1.18.0 and problem is resolved. The notifyCommit
> no
Reverted Git Client to 1.18.0 and problem is resolved. The notifyCommit
no longer faults, and the job is running on the slave.
Current config: Git plugin 2.4.0, Git client 1.18.0.
Michael
On Thursday, March 31, 2016 at 11:18:54 AM UTC-7, Mark Waite wrote:
>
> I don't know how to duplicate
In the interest of determining if the issue is related to the git client
plugin, I would like to roll back to the previous version. We currently
have 1.19.6 installed. Our previous version was 1.18.0.
Should this combination work? Git Plugin 2.4.0 (or 2.4.4) with Git Client
1.18.0.
Here are a few more facts that might give some clues.
Master is running Jenkins 1.609.3 in Oracle JDK 1.6.0_75
Slave is Linux running Oracle JDK 1.8.0_20
Git Plugin version 2.4.0
Git Client version 1.19.6
I modified the job configuration to restrict execution to a different slave
(one that it
On 31.03.2016, at 18:24, Alex Domoradov wrote:
> Does Jenkins 2.0 really using any of the 3.1 features (new classes, methods)?
I don't think we do, yet, but rather than add it in a regular weekly release in
the future when we start to use these features, we decided to
I don't know how to duplicate either your issue or JENKINS-33907. I
installed a Jenkins 1.609.3 last night with Java 6, then used a slave with
Java 7, and confirmed that I was able to checkout on the master and the
slave using the command line git implementation with git plugin 2.4.4 and
git
Seems another user has similar issue.
https://issues.jenkins-ci.org/browse/JENKINS-33907
That is not exactly the same, but I've seen the same issue, and it could be
related to my issue.
On Tuesday, March 29, 2016 at 11:44:15 AM UTC-7, Michael Giroux wrote:
>
> Since updating to Git plugin
Hello,
I have tried to run jenkins 2.0 with resin but without success. when I'm
trying to open a main page I get the following error
WEB-INF/web.xml:30: http://xmlns.jcp.org/xml/ns/javaee;>
is an unexpected top-level tag.
28: xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
This question belongs on the users list, so It's in the cc.
It's a bit hard to know what could be configured wrong without more info
(and I'm not a windows user, so I don't know of any particulars on that OS)
but;
Have you configured Gerrit Trigger as the build chooser for the git
checkout? i.e.
My two cents :
* Set executors number on master to 0 and run jobs only on slaves. That
prevents anyone without admin access to your master to screw it.
* If you're still afraid to screw your slaves, use one-off slaves using one
of the Cloud implementations (using VMWare, Docker, or any other
Has anyone else seen this problem?
I've just upgraded my Jenkins installation from 1.625.3 to 1.642.3, and
upgraded all my installed plugins to match. Everything seems fine except
that I can no longer use "Tag this build" in jobs that checked out their
sources from svn. The "Credentials for
Hi,
We are using Maven-type projects where the upstream and downstream
dependencies are computed automatically.
Sometimes it happens that Jenkins gets confused about them and have wrong
data.
Is there anyway to reset them? Rebuilding usually does not fix the problem,
the only solution is to
Sounds like you in fact need `dropdownList` (with one empty block) and not
`repeatebale`.
--
oliver
--
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, send an email
to
21 matches
Mail list logo