docker-maven-plugin. Is it worth advising them to
switch to Testcontainers at some point as well?
Chris
On Wed, 5 Jan 2022, at 1:10 PM, 'Jesse Glick' via Jenkins Developers wrote:
> On Wed, Jan 5, 2022 at 7:41 AM Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>> wrote:
>>
I tried migrating from the docker-maven-plugin to testcontainers. The resulting
code is indeed a little cleaner, and it's nice to not have to run an
out-of-band step before running the test suite. Unfortunately the build still
fails on ci.jenkins.io, so the underlying Docker issue is probably
.
Chris
On Tue, 4 Jan 2022, at 5:01 PM, 'Jesse Glick' via Jenkins Developers wrote:
> [Somehow did not get sent to the list. Reposting:]
>
> On Tue, Jan 4, 2022 at 7:57 AM Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>> wrote:
>> org.apache.maven.lifecycle.LifecycleEx
Hi,
Timeouts related to the Docker Maven Plugin are causing some plugin builds to
fail on ci.jenkins.io. The error message is usually along the lines of:
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
io.fabric8:docker-maven-plugin:0.38.0:start (start-moto) on
, 'Daniel Beck' via Jenkins Developers wrote:
>
>
> On Mon, Sep 27, 2021 at 1:17 PM Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>> wrote:
>> However there is a problem that some 3rd party Jenkins management tools
>> (i.e. not Jenkins' own tools like Plugi
Hi,
I'm wondering what techniques people have used to safely extract features from
existing plugins into new plugins.
At first glance a phased approach intuitively makes sense:
1. Plugin A exists.
2. Extract feature from A into new plugin B. Release B.
3. Delete feature code from A. Make A
> IMHO it is time to make one step forward and to include JCasC test harness
> and into Jenkins Test Harness or to Plugin POM by default. There is wide
> adoption of JCasC test automation thanks to so many contributors, and IMHO
> there is no particular point in making users to explicitly
; there is no particular point in making users to explicitly define it these
>> days. Opinions?
>> On Tuesday, September 14, 2021 at 11:44:57 AM UTC+2 Chris Kilding wrote:
>>> Hi,
>>>
>>> I've seen the following dependency error in 2 plugins regardi
Hi,
I've seen the following dependency error in 2 plugins regarding
jenkins-test-harness:
Require upper bound dependencies error for
org.jenkins-ci.main:jenkins-test-harness:1529.v4fd5bafdcd33 paths to dependency
are:
22:20:04
I've got a plugin where I want to switch issue reporting from Jira to Github
Issues. How would I go about that?
Regards,
Chris
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails
It looks like JDK 8u302 was released in upstream OpenJDK on 20th July. I've
opened an issue about this at the place where I *think* the JDK version is set
for ci.jenkins.io: https://github.com/jenkins-infra/packer-images/issues/77
Chris
On Tue, 15 Jun 2021, at 3:10 PM, Chris Kilding wrote
emoved
> from JDK 8u292 Based on https://bugs.openjdk.java.net/browse/JDK-8266261 it
> appears the removal was inadvertent and the algorithm will be added to the
> next Open JDK release, 8u302.
>
> On Tue, Jun 15, 2021 at 3:36 AM Chris Kilding <mailto:chris%2bjenk...@chriski
Hi,
Recently I have seen the following error on ci.jenkins.io when building plugins
that use cryptography features:
java.security.KeyStoreException: Key protection algorithm not found:
java.security.UnrecoverableKeyException: Encrypt Private Key failed:
unrecognized algorithm name:
Great, thanks for confirming that.
Chris
On Thu, 6 May 2021, at 2:56 PM, Tim Jacomb wrote:
> Yes it's moved to CD releases https://www.jenkins.io/jep/229
>
> https://github.com/jenkinsci/bom/issues/510
>
> On Thu, 6 May 2021 at 11:59, Chris Kilding <mailto:chris%2bjenk..
Hi all,
The new BOM version today is 807.v6d348e44c987. This seems quite out of step
with the previous versioning pattern - 27, 28, 29 etc. Was this change
intentional?
Chris
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To
them?
Chris
On Fri, 12 Feb 2021, at 6:22 PM, Chris Kilding wrote:
> Hi Matt,
>
> Definitely agree that the various Jenkins access control solutions
> should be aware of namespaces, so that sysadmins can specify rules like
> 'this identity principal can access resources in that
ike something that belongs in an identity and access
> management solution in general since it's a common problem to be
> solved for all your other applications using those auth sources.
>
> On Fri, Feb 12, 2021 at 5:40 AM Chris Kilding
> wrote:
> >
> > Hello,
> >
&
Hello,
Interest in multi-cloud and multi-account cloud setups is increasing at my
company, and I have had correspondence from people in other companies about
this too. It's worth thinking about how Jenkins is going to work in this
scenario going forward.
There are quite a few Jenkins plugins
I enabled the native Dependabot version updates (the experimental feature) on
my plugin today. Overall it's extremely useful and working well! I expect I'll
soon wonder how I ever managed without it.
Couple of thoughts:
1. The initial splurge of PRs spawns a lot of builds, so it's helpful that
Cheers, I've taken a look, and also filed an issue
(https://issues.jenkins-ci.org/browse/JENKINS-63855) to discuss client-side
min/max constraints on number fields.
On Fri, 2 Oct 2020, at 3:19 PM, Jesse Glick wrote:
> On Fri, Oct 2, 2020 at 9:59 AM Chris Kilding
> wrote:
> > C
Hello,
I've had some users express interest in being able to namespace their
credentials, so that they can reuse credential IDs in different namespaces. The
motivation is to make it simpler to reference the same credential (e.g. an
Artifactory deploy key) across environments (e.g. staging,
Hi,
Just today I was looking at adding a new option to a plugin's configuration,
and thought that the javax.validation API would be really helpful to apply
validation constraints to plugin configuration in a single place.
For example:
@Extension
@Symbol("yourPlugin")
public class
lish a knowingly broken release and it would
>> only be known retroactively.
>>
>> What sort of convention are you thinking of? Just a recommendation of this
>> is how you should communicate it to users? A line in documentation somewhere?
>>
>> Thanks
>&g
Hi all,
While fixing a bug that I'd accidentally introduced in a previous release, I
wondered whether we should have a convention in Release Drafter to indicate
something like "known issues" or "do not use this release".
Some issues make a plugin release unusable, so users need to skip it
Hi Jesse,
Sounds interesting, I look forward to seeing it when it's written up.
Chris
On Fri, 31 Jul 2020, at 10:17 PM, Jesse Glick wrote:
> On Fri, Jul 31, 2020 at 1:49 PM Chris Kilding
> wrote:
> > The verdict was that:
> >
> > …
> >
> > And therefo
Hello,
At FOSDEM earlier this year there was a discussion about whether release builds
of plugins could be pushed from a central security-hardened box in
ci.jenkins.io, and whether this would improve the security posture of plugin
releases compared to the status quo (where incrementals builds
> On Thursday, May 7, 2020 at 8:40:00 PM UTC+2, Mark Waite wrote:
>>
>>
>> On Thu, May 7, 2020 at 12:18 PM Chris Kilding wrote:
>>> __
>>> Hi Mark,
>>>
>>> Thanks, that explains it. Off-hand thought - can AWS PrivateLink - or the
>>> Azur
workaround is to push trivial commits when I need it to try
again. That suffices during PR development, but I can’t do that in master for
the fun of it.
Chris
On Thu, 7 May 2020, at 4:12 PM, Mark Waite wrote:
>
>
> On Thu, May 7, 2020 at 8:27 AM Chris Kilding <mailto:
Hi,
I'm seeing a range of instability on the Ubuntu EC2 build agents on
ci.jenkins.io over the past week, including tests randomly taking forever and
timing out, and instances randomly being terminated mid-build.
This didn't used to happen previously when I think the builds were running in
It’ll be a while before we’ll be able to publish what we want to demonstrate
(this goes beyond just the Jenkins YAML file, there are surrounding components
that make up our in-house ‘Jenkins on AWS’ template). But any solution would
have to generate the YAML file as a starting point, so in the
Another action point from the call yesterday...
Regarding the “share your Jenkins configuration” feature, I am talking to our
core engineering team at work to see if we can publish at least a snapshot of
our shared Jenkins template repo (this is the template that our product
development teams
it passes/fails?
>
> On Wed, Feb 26, 2020 at 5:17 AM Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>> wrote:
> Hi,
>
> I see my plugin builds failing occasionally on JDK 11 on a test that uses
> BouncyCastle and the Java crypto APIs. Is there any instabili
Hi,
I see my plugin builds failing occasionally on JDK 11 on a test that uses
BouncyCastle and the Java crypto APIs. Is there any instability in those APIs
or libraries on JDK 11, or are the Jenkins infra team in the process of
modifying them?
## Details
- The test constructs a dummy
Jesse - cheers for pointing out the previous AWS packaging attempt, I will take
a look.
Re version pinning, if this can’t be done in the POM, are there any Jenkins
tools which can do this, apart from the cloudbees assured update feed? (I’m
thinking of how we could support users on Jenkins
the
> users of Jenkins distribution customise service. How do think about this?
>
> Platform-plugins.json is a good example. Thanks Jesse!
>
> Best regards,
> Rick
>
>> On 21 Feb 2020, at 00:33, Jesse Glick wrote:
>>
>> On Thu, Feb 20, 2020 at 9:51 AM Chris Kild
ected.
>
> On Thu, Jan 30, 2020 at 10:54 PM Jeff <mailto:jeff...@gmail.com>> wrote:
> I just saw this, but I would be interested in working with you on this even
> if it doesn't make it into GSoC.
>
> Rick, do you need help getting a proposal started?
}
}
The matrix-auth component seems to have a hudson.security package, but I didn’t
see the ACL class in it though.
> On 13 Feb 2020, at 14:13, Daniel Beck wrote:
>
>
>
> On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>> wrote:
> I hav
ear about?
> Point 1?
>
> Point 1 is a request based authorisation, nothing is allowed to use it by
> default, jobs request to use it and then an autrhorised person allows it
>
> On Wed, 12 Feb 2020 at 23:36, Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>>
n, before allowed to use, I.e build is run and fails
> because the credential isn’t authorised for that job but then an
> administrator can authorise it and it will be allowed to use it on the next
> run,
> 2. Credentials scoped to a single build
>
> Thanks
> Tim
>
>>
?
Chris
> On 12 Feb 2020, at 16:29, Chris Kilding
> wrote:
>
> Hello,
>
> This is the discussion thread for JEP-225: Folder-based access control for
> any credentials provider.
>
> A brief summary...
>
> The Cloudbees Folders Plugin has the ability to
Thanks Jesse, the solution was indeed to implement a custom
RootElementConfigurator in the plugin. (And then to do the translation between
the desired CasC config model and the traditional Web form config model in the
describe() method.)
Chris
> On 11 Feb 2020, at 16:54, Jesse Glick wrote:
Hello,
I'm adding an optional list property to a plugin's configuration. This is a
particularly tricky kind of property, as it results in lots of nesting in the
config data model to make the Web UI's /configure page work. I would like to
present a simpler data model to CasC without the
While there are differences of opinion on the issue *storage* problem (ie do we
store our issues in Jira or GitHub), there seems to be common ground on solving
the *access* problem for users that report issues.
If we can get a GitHub connector up and running for Jira, so that any user who
I'm inclined to agree with Joseph and Tim.
When maintaining my plugin I often wonder how many bug reports I'm losing
because users either:
- Can't find their way through our bug tracking system (and all the labels and
categories that a bug must be annotated with), compared to GH Issues which
ev wrote:
> >
> > With the current scope of Affected components JEP would be definitely great
> >
> > On Wednesday, January 29, 2020 at 5:21:20 PM UTC+1, Chris Kilding wrote:
> >>
> >> I'm currently working out the details of JENKINS-60897, an enhancement to
> >>
I'm currently working out the details of JENKINS-60897, an enhancement to
enable the folders plugin to provide an access control layer over any
credentials provider. This would affect several components (all credential
providers, credentials API, CasC, folders plugin, maybe more). It may also
servers - such
that we can’t use the interactive documentation. Lots of developers also just
don’t know about the interactive docs. As a result we still often use the
static pipeline docs.
Chris
On Wed, 22 Jan 2020, at 6:01 PM, Jesse Glick wrote:
> On Wed, Jan 22, 2020 at 10:43 AM Chris Kild
Hello,
Would the community be interested in having a Dash/DevDocs docset for Jenkins?
I’d be willing to do the packaging work for this if there is sufficient
interest.
For our part, Jenkins admins in my company utilise the Pipeline DSL reference
and the JobDSL reference quite heavily - these
The notion of a Jenkins distribution(s) sounds relevant to us.
In my company we have a central team which is trying to put together a
standardised Jenkins template to deploy on AWS, which all product teams can
then adopt instead of rolling their own. (This is part of a phased
deduplication
t would be a breaking change.
>>
>> On Wed, Dec 18, 2019 at 5:45 AM Chris Kilding
>> mailto:chris%2bjenk...@chriskilding.com>>
>> wrote:
>>> Hello,
>>>
>>> The Jenkinsfile withCredentials directive has a number of binding type
>>&
Hello,
The Jenkinsfile withCredentials directive has a number of binding type names
(like `string`, `usernamePassword`, `certificate`). Are the type names are
stable enough to reuse from other systems? Specifically, I might need to use
them as type identifiers within credentials providers, to
On Thu, 12 Dec 2019, at 2:20 PM, Jesse Glick wrote:
> On Thu, Dec 12, 2019 at 6:29 AM Chris Kilding
> wrote:
> > 1. Does it support storing the AWS Endpoint Configuration (service
> > endpoint, signing region)?
>
> What is currently defined:
>
> https://javado
Hello,
The AWS Global Configuration plugin seems to be a useful way to share config
between plugins that use the AWS SDK. I have a few questions about it:
1. Does it support storing the AWS Endpoint Configuration (service endpoint,
signing region)?
2. Should plugins inherit their AWS SDK Maven
Cool, PR submitted: https://github.com/jenkins-infra/jenkins.io/pull/2700
Chris
On Thu, 5 Dec 2019, at 5:01 PM, Marky Jackson wrote:
> That is all you would need to do
>
> > On Dec 5, 2019, at 9:00 AM, Chris Kilding
> > wrote:
> >
> > Hello,
> >
> &g
Hello,
My company has suggested I write a post about the plugin I created on the
Jenkins blog. Is it sufficient to submit it as a PR on the
jenkins-infra/jenkins.io repo, or would there be any other steps?
Regards,
Chris
--
You received this message because you are subscribed to the Google
It happened again this morning.
The recent 502 errors seemed to coincide with builds of certain Jenkins Core
components, which have a large number of (parallel) steps.
Just an initial idea - is the master being overwhelmed by either the sheer
number of steps as they enter the job queue, or the
Hello,
I’m adding certificate credentials support to my plugin, and am wondering
whether Jenkins always expects certificate creds to be PKCS12-encoded.
The direct certificate uploader source and the “file on Jenkins master” source
seem to insist on PKCS format internally.
But the
Hello,
The Git plugin has a MessageExclusion extension to skip commits matching
certain message patterns eg ‘[ci-skip]’. I have seen this reimplemented in a
few different places in the Jenkins pipeline stack, and it would make sense to
implement it only once.
The feature should probably live:
The first stable version of the plugin (0.0.1) is now available in the main
Jenkins update center.
Check it out here:
https://plugins.jenkins.io/aws-secrets-manager-credentials-provider
And if you have any feedback, feature requests, or bug reports, just reply
below - or file a Jira ticket :)
Hi Jesse,
I’ve filed an INFRA ticket for this issue:
https://issues.jenkins-ci.org/browse/INFRA-2125
Chris
On Thu, 30 May 2019, at 2:22 AM, Jesse Glick wrote:
> On Mon, May 20, 2019 at 2:05 PM Chris Kilding
> wrote:
> > It fails after a couple of minutes of uploading with 400
that either my initial alpha release or merging to master
unblocked deployments to the incrementals repo, but I’m not sure which one did
it.
On Thu, 23 May 2019, at 4:30 PM, Chris Kilding wrote:
> Found the source of the incrementals-publisher function in the end. But I
> think the lates
, 21 May 2019, at 10:59 AM, Chris Kilding wrote:
> I’ll push the plugin through to Incrementals anyway as it validates the
> archive as part of the process, which is a useful automated check to have.
>
> Unfortunately I’m seeing extremely slow upload speeds to the Incrementals
> Azu
/6
But I am still seeing ‘400 Bad Request’, this time with no explanatory message.
Chris
On Tue, 21 May 2019, at 11:23 AM, Baptiste Mathus wrote:
> What's the PR where you "incrementalified"?
>
> Le lun. 20 mai 2019 à 20:05, Chris Kilding <mailto:chris%2bjenk...@chri
this?
Chris
On Mon, 20 May 2019, at 6:19 PM, Jeff Pearce wrote:
> Hi Chris
>
> No need to publish an Alpha version for me – I’m happy to build and install
> manually
>
> Best
> Jeff
>
> *From: * on behalf of Chris Kilding
>
> *Reply-To: *"jenkinsci-dev@go
I’ve followed the guide to make a plugin upload to Jenkins Incrementals after
successful builds.
It fails after a couple of minutes of uploading with 400 Bad Request, however
the deploy step in Jenkins that runs this command actually passes.
This doesn’t seem right - any suggestions?
The
o have switched have noticed, see
> this PR: https://github.com/jenkinsci/credentials-plugin/pull/114
> Which has a commit directed for "fix spotbugs"
>
> On Friday, May 17, 2019 at 2:19:43 PM UTC+2, Chris Kilding wrote:
>> Alrighty, the manual way it is.
>>
>>
way to do this, the manual way is the
> only way.
>
> On Thu, May 16, 2019 at 10:55 AM Chris Kilding
> mailto:chris%2bjenk...@chriskilding.com>>
> wrote:
>> __
>> The plugin now has a passing CI build on its master branch.
>>
>> The next st
, at 11:03 AM, Chris Kilding wrote:
> The plugin is now hosted by @jenkinsci at
> https://github.com/jenkinsci/aws-secrets-manager-credentials-provider-plugin
>
> Jeff - could you delete and re-create your fork, so that the @jenkinsci repo
> is the authoritative root of the r
’ for the future?
Chris
On Wed, 15 May 2019, at 6:45 PM, R. Tyler Croy wrote:
> (replies inline)
>
> On Wed, 15 May 2019, Chris Kilding wrote:
>
> > Yep, that sounds reasonable. (I had suspected as much - there would be no
> > end
> > to the possible system package
to be pre-packed and hosted on a registry?
Chris
On Wed, 15 May 2019, at 5:36 PM, R. Tyler Croy wrote:
> (replies inline)
>
> On Wed, 15 May 2019, Chris Kilding wrote:
>
> > My plugin uses an external dependency, Moto (the AWS mock server) for its
> > integrat
My plugin uses an external dependency, Moto (the AWS mock server) for its
integration tests.
Moto is written in Python, installed with Pip, in a virtualenv. It can be used
either directly (where we must do the pip install ourselves) or through the
Java wrapper Localstack (which does little
r tools (like coverage and pitest).
>>
>> Examples:
>> https://github.com/jenkinsci/analysis-model/blob/master/Jenkinsfile
>> https://github.com/jenkinsci/warnings-ng-plugin/blob/master/Jenkinsfile
>>
>>
>>> Am 14.05.2019 um 19:42 schrieb Chris Kilding
>&g
The standard ‘buildPlugin()’ Jenkinsfile directive appears to capture Surefire
test reports, but not Failsafe test reports. This means that failing
integration tests in my plugin are (a) unreported and (b) don’t break the
build. This might be happening to other plugins too.
The line of code in
n your laptop that checks out the sources from GitHub?
>
>> Am 14.05.2019 um 12:42 schrieb Chris Kilding
>> :
>>
>> I’m seeing problems with localizer in plugin builds on ci.jenkins.io, and
>> wondering if other plugin authors have seen them too.
>>
>> My
I’m seeing problems with localizer in plugin builds on ci.jenkins.io, and
wondering if other plugin authors have seen them too.
My plugin generates translations (the Messages classes) before compilation just
fine on my laptop. But when the very same plugin is built on ci.jenkins.io I
see
PM, Chris Kilding wrote:
> Due to the interest in the plugin I’ve now opened a hosting request to
> transfer it to @jenkinsci at https://issues.jenkins-ci.org/browse/HOSTING-763
>
> Chris
>
> On Mon, 13 May 2019, at 12:08 AM, Chris Kilding wrote:
>> Hi Jeff,
>>
>
Due to the interest in the plugin I’ve now opened a hosting request to transfer
it to @jenkinsci at https://issues.jenkins-ci.org/browse/HOSTING-763
Chris
On Mon, 13 May 2019, at 12:08 AM, Chris Kilding wrote:
> Hi Jeff,
>
> Yep, the compile error appears to be because the Maven
for a first-time user to understand?
Regards,
Chris
On Sun, 12 May 2019, at 2:56 PM, Jeff Pearce wrote:
> I think you forgot to include some resources - when I build it can't find
> Messages.*. I can work around for my testing though
>
> On Friday, May 10, 2019 at 6:08:31 AM UTC-7, C
Hello,
I need to implement fine-grained caching of non-secret credential metadata in
my credentials provider plugin, but I’m not sure how to get the information I
need to build this cache from the CredentialsProvider interface.
The official guide did not seem to have any suggestions for
file. But if
you’d like to try it, you can check it out, install dependencies, and run ‘mvn
clean verify’ to build it (see the README).
Once the plugin is ready, I’ll get the show on the road to migrate it to
@jenkinsci and make it official.
Chris
On Tue, 7 May 2019, at 2:19 PM, Chris Kilding
, at 5:37 PM, Chris Kilding wrote:
> Hi Stephen,
>
> I did have one question that’s not covered by the guide...
>
> The guide says that a credential that fetches its secret value from a remote
> service must throw an IOException if there is a data-related problem (e
of StringCredentials#getSecret()...
- Throw an unchecked exception?
- Return null?
- Something else?
Chris
On Tue, 9 Apr 2019, at 1:41 PM, Stephen Connolly wrote:
>
>
> On Tue, 9 Apr 2019 at 11:57, Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>> wrote:
>> __
&g
On Tue, 9 Apr 2019, at 11:57 AM, Chris Kilding wrote:
> Hi Stephen,
>
> When I started building the plugin my basis was a combination of your guide
> and the Kubernetes Credentials Provider.
>
> The following sections of your guide were particularly valuable right from
&g
lementing-a-new-credentialsprovider
>
> On Thu 4 Apr 2019 at 17:10, Chris Kilding <mailto:chris%2bjenk...@chriskilding.com>> wrote:
>> __
>> Hi,
>>
>> That sounds good - we’re happy to host in jenkinsci and make the plugin
>> available through the built-i
nks for publishing it!
>
> > On 4. Apr 2019, at 16:21, Chris Kilding
> > wrote:
> >
> > We’re initially thinking it should be a Github repo under the ‘jenkinsci’
> > or ‘aws’ organisations, with our own engineers added to that repo as
> > external colla
. (These would seem to be the most natural homes for the plugin.)
But we’re open to other suggestions :)
Regards,
Chris Kilding
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails fro
86 matches
Mail list logo
