Can you summarize what can be expected from those new versions
Is it really only UI refactoring or do changes introduce something more?
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emai
On Fri 16 Jun 2017 at 23:57, Owen Mehegan wrote:
> Does this mean we can move forward with working on GitLab branch source
> work after these changes are final?
>
Yes
(I think the changes are final now, but let's see what it takes to get the
GitHub changes polishing finished)
>
> On Fri, Jun 1
I think I have this almost going. The issue seems to be that I changed my
"clientInterface" field from a String to a custom object. Even though my
readResolve() returns the 'this' object with the new BasicClient type, for
any old projects that have the old String field in their
jobs/jobname/con
Does this mean we can move forward with working on GitLab branch source
work after these changes are final?
On Fri, Jun 16, 2017 at 11:18 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Just a quick status update.
>
> In final stages of this work now. Bobby is being a superstar a
On Fri 16 Jun 2017 at 23:32, Joseph P wrote:
> I'd love to get the bitbucket going, I really want merged PRs TODAY :D
>
If you are on BB server you should be fine
If you are on BB cloud, unless you set permissions up when forking, only
PRs from forks in the team account and PRs from the origin
I'd love to get the bitbucket going, I really want merged PRs TODAY :D
Den fredag den 16. juni 2017 kl. 20.19.12 UTC+2 skrev Stephen Connolly:
>
> Just a quick status update.
>
> In final stages of this work now. Bobby is being a superstar and reviewing
> my 13k LoC change on the Bitbucket branch
I will give it a spin too.
Thanks
-Dan
On Friday, June 16, 2017 at 11:57:26 AM UTC-7, Kevin Burnett wrote:
>
> we'd be down to try that, yes. thanks for making these changes in a way
> that will benefit the product long-term!
>
> fingers are crossed that there's already a built-in way to preten
Couldn't it rely on the JDK configured on the master side for classical
agents ?
For them you have to accept the license and signup with an oracle account
thus I imagine that it might be the best solution
On Fri, Jun 16, 2017 at 11:47 PM, Francis UPTON IV
wrote:
> The s3 bucket where the ec2 plu
The s3 bucket where the ec2 plugin automatically downloaded the JDK no
longer works.
Apparently it's not legal for the JDK to be redistributed automatically in
this manner.
I think this will be somewhat of a usability issue for the plugin.
Does anyone have ideas as to how this might be address
:-P
On Fri, Jun 16, 2017 at 11:09 PM, R. Tyler Croy wrote:
> (replies inline)
>
> On Fri, 16 Jun 2017, Arnaud H?ritier wrote:
>
> > Don't forget to disable all plugins jobs on DEV@cloud to avoid a mess in
> > GitHub pull-requests status
>
>
> That sounds like a good aheritier task :D
>
>
>
> - R
(replies inline)
On Fri, 16 Jun 2017, Arnaud H?ritier wrote:
> Don't forget to disable all plugins jobs on DEV@cloud to avoid a mess in
> GitHub pull-requests status
That sounds like a good aheritier task :D
- R. Tyler Croy
--
Code: <
Don't forget to disable all plugins jobs on DEV@cloud to avoid a mess in
GitHub pull-requests status
On Fri, Jun 16, 2017 at 9:35 PM, Mark Waite
wrote:
> +1 from me. I love buildPlugin() and I've been very grateful for the
> results from Windows and Linux builds, and from pliugin compatibility
+1 from me. I love buildPlugin() and I've been very grateful for the
results from Windows and Linux builds, and from pliugin compatibility
tester, all with a few arguments to buildPlugin().
On Fri, Jun 16, 2017 at 1:13 PM Jesse Glick wrote:
> On Fri, Jun 16, 2017 at 2:54 PM, R. Tyler Croy
> wr
On Fri, Jun 16, 2017 at 2:54 PM, R. Tyler Croy wrote:
> add "*-plugin" to our GitHub Organization Folder here:
> https://ci.jenkins.io/job/Plugins/
+1 naturally! There are a lot of miscellaneous little plugins I have
been meaning to add a `Jenkinsfile` to and this would reduce the
friction to do
Go go go
Eat your own ...
Le ven. 16 juin 2017 à 20:54, R. Tyler Croy a écrit :
>
> Last year we started allowing plugin developers use of new shiney elastic
> compute capacity on ci.jenkins.io provided by our friends at Microsoft.
> Today I
> would like to proposal that we open the flood gates
Last year we started allowing plugin developers use of new shiney elastic
compute capacity on ci.jenkins.io provided by our friends at Microsoft. Today I
would like to proposal that we open the flood gates, and add "*-plugin" to our
GitHub Organization Folder here: https://ci.jenkins.io/job/Plugin
Well I kind of though you were required- given the git plugin is part of
the changes ;-)
On Fri 16 Jun 2017 at 19:35, Mark Waite wrote:
> I'd like to be part of the beta test.
>
> Mark Waite
>
> On Fri, Jun 16, 2017 at 12:19 PM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Ju
I'd like to be part of the beta test.
Mark Waite
On Fri, Jun 16, 2017 at 12:19 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Just a quick status update.
>
> In final stages of this work now. Bobby is being a superstar and reviewing
> my 13k LoC change on the Bitbucket branch so
Just a quick status update.
In final stages of this work now. Bobby is being a superstar and reviewing
my 13k LoC change on the Bitbucket branch source - brings lots of feature
parity with GitHub and adds the configuration ability of the pure Git
branch source
I am finalising the GitHub Branch So
Hello Jenkins Devs,
I would be glad to adopt schedule-build-plugin. There are several open
issues, and also open pull requests which add new functionality like
support for pipelines.
The plugin is not marked for adoption, but unfortunately it seems not to be
maintained anymore:
Last release:
On Fri, Jun 16, 2017 at 8:29 AM, Kirill wrote:
> If I remove 'provided' from the K8s plugin dependency in POM
Which you must!
> it's still being installed in Jenkins along with my plugin
As Daniel said, only in `hpi:run`.
--
You received this message because you are subscribed to the Google G
> On 16. Jun 2017, at 14:29, Kirill wrote:
>
> it's still being installed in Jenkins along with my plugin, despite
> 'true'.
I would guess that happens only in hpi:run; not if you install it from an
update center, or upload the plugin to Jenkins.
--
You received this message because you are
Hi fellow Jenkins developers,
I have a Jenkins plugin, which can optionally use Kubernetes plugin.
However, I don't want the Kubernetes plugin to be installed along with my
plugin in Jenkins.
That's why I have set this in the POM file:
> org.csanchez.jenkins.plugins
> kubernetes
> p
2017-06-16 12:19 GMT+02:00 Christian McHugh :
> On Friday, June 16, 2017 at 11:12:27 AM UTC+1, Robert Sandell wrote:
>>
>> The XStream deserialization from config.xml to the object graph don't use
>> the DataboundConstructor et.al. It is only interested in mapping xml
>> data to fields (in most ca
On Friday, June 16, 2017 at 11:12:27 AM UTC+1, Robert Sandell wrote:
>
> The XStream deserialization from config.xml to the object graph don't use
> the DataboundConstructor et.al. It is only interested in mapping xml data
> to fields (in most cases).
>
> DataboundConstructor is only used for for
The XStream deserialization from config.xml to the object graph don't use
the DataboundConstructor et.al. It is only interested in mapping xml data
to fields (in most cases).
DataboundConstructor is only used for formbinding from the UI and pipeline
step definitions etc.
/B
2017-06-16 12:03 GMT+
Great example, thanks!
Let's say that a release had already been made which changed the
databoundconstructor. In that case, the constructor's api is already
modified. In this theoretical example, is there a mechanism by which the
job config.xml could be updated to match the new constructor layo
27 matches
Mail list logo
