> 1. The ability to install Jenkins as a service[1] when it is running (by
java -jar) on a windows machine
I forgot to mention - which potentially valid - I would argue that the user
should just download the MSI package for this instead, afterall we do not
attempt to install a systemd file
Hi all,
the j-interop and jcifs libraries only appear to be used for very narrow
use cases
1. The ability to install Jenkins as a service[1] when it is running (by
java -jar) on a windows machine
2. for installing windows agents via dcom etc (which is deprecated[2])
There are a couple of uses
Hi Gavin,
I just tried this now and it failed with "GraphqlError: Nullability
mismatch on variable $color1 and argument color (String / String!)"
/James
On Friday, March 31, 2023 at 3:58:49 PM UTC+1 ga...@gavinmogan.com wrote:
> I made https://plugins-self-service-3ir4b.ondigitalocean.app/ a
> 2.415 appears to have a regression in the dialog handling that I just
found with a minimal amount of testing, so possibly too new to have had
exposure :-(
https://issues.jenkins.io/browse/JENKINS-71699
On Monday, July 24, 2023 at 3:31:21 PM UTC+1 jn...@cloudbees.com wrote:
> Than
bug in 2.414 has been fixed.
>
> On Sat, 22 Jul 2023 at 00:21, Basil Crow wrote:
>
>> On Fri, Jul 21, 2023 at 10:42 AM 'jn...@cloudbees.com' via Jenkins
>> Developers wrote:
>> > 2.414 has a regression in the plugin manager.
>> > I would be -1 on this unless that i
2.414 has a regression in the plugin manager.
I would be -1 on this unless that is fixed (currently missing a Jenkins bug
but has been the cause of a lot of ATH failures)
https://github.com/jenkinsci/acceptance-test-harness/issues/1284 for the
current status/investigation, I will file a Jenkins
> Please do not troll
that too but I meant roll this out.
On Wednesday, April 12, 2023 at 2:06:02 PM UTC+1 jn...@cloudbees.com wrote:
> Please do not troll this out until
> https://github.com/diffplug/spotless/issues/1559 is fixed - this causes
> all code to fail for windows
Please do not troll this out
until https://github.com/diffplug/spotless/issues/1559 is fixed - this
causes all code to fail for windows users using checkout-as-is and
checkin-as-is which is not uncommon for windows users who also share code
with the Linux subsytem for windows.
I have battled
Hi all,
When modernising a plugin I find the tedious part is to create all the
labels for both CD releases and the release notes.
it's time consuming to find a reference repo and then duplicate the labels
(and their colours) to the repo I am updating.
As this is not an uncommon task I was
PM UTC jn...@cloudbees.com wrote:
> the package names are still the same as far as I understand, and this
> would still have issues due to the nature of the dependencies.
>
> as k8s has dependencies on both -creds and -api if the creds where
> updated to use the new -6-api
the package names are still the same as far as I understand, and this would
still have issues due to the nature of the dependencies.
as k8s has dependencies on both -creds and -api if the creds where updated
to use the new -6-api when the classess that k8s would see would be a bit
"iffy"
Hi all,
Does anyone use the HTMLUnit browser in the jenkins acceptance-test-harness
suite?
I am doing some cleaning and I know that chrome and firefox are used, but
looking at the others also.
I think it is safe to nuke InternetExplorer support from orbit, and I would
be amazed if HTMLUnit
> But this chain of reasoning led me to another conclusion as well: if
we can hide SLF4J, then why not also hide Bouncy Castle in similar
fashion? (Context: Bouncy Castle is the only obvious way to implement
the --httpsPrivateKey and --httpsCertificate options for Java 17,
since the Java Platform
Hi,
> - could it be because I'm running on Gradle?
:-) well you are in the minoroty and the least tested path.
However I do not see any dependency for cloudbees-folder
in
https://github.com/jenkinsci/job-dsl-plugin/blob/defect/org-folder-secrets/build.gradle#L21-L27
(but I admit I am not
HI,
If I understand your question correctly, you just need to return non-null
for getDisplayName and getIconFileName in your Action[1]
/James
[1] https://javadoc.jenkins.io//hudson/model/Action.html
On Thursday, June 16, 2022 at 12:17:40 AM UTC+1 mukhammadno...@gmail.com
wrote:
> Is there
/52326318/maven-javadoc-search-redirects-to-undefined-url
On Wednesday, June 15, 2022 at 5:29:12 PM UTC+1 jn...@cloudbees.com wrote:
> I am seeing some issues with the actual jenkins java11 javadoc too.
> Smells like bugs in javadoc - but it may be out invocation of it is not
> correct.
>
I am seeing some issues with the actual jenkins java11 javadoc too. Smells
like bugs in javadoc - but it may be out invocation of it is not correct.
The search seems to be broken - when you follow a link to a type you get
linked to a page that starts https://javadoc.jenkins.io/undefined
e.g.
f the javadoc was published for the plugin or if there's any
> issue with it?
>
> We can test it out on the test plugin
> <https://github.com/jenkinsci/jenkins-infra-test-plugin> to not impact
> users.
>
> Thanks
> Tim
>
> On Tue, 14 Jun 2022 at 14:26, 'jn...@cloudbee
Hi all
Just released a plugin and I have the following warning
[WARNING] javadoc: warning - Error fetching URL: https://javadoc.jenkins.io/
The javadoc for jenkins was recently switch to Java11 (seems a week early)
and this means that plugins can no longer link correctly when
HI James
Have your test setup works ok before you introduced vault (ie with the
standard credential helper?).
I would hazard a guess that your git installation was installed and
configured to use a credential helper.
git config --system --unset credential.helper
Regards
/James
On
le
> struggle to report issues.
>
> I have started writing a draft JEP to put some more words together but
> interested in any feedback on the above.
> (I'm aware EPIC links are not included in the export, I plan to fix that)
> (Web links exporting doesn't work unfortunately
> htt
022 at 10:38:36 AM UTC+1 ullrich...@gmail.com wrote:
> Am 13.06.2022 um 11:11 schrieb 'jn...@cloudbees.com' via Jenkins
> Developers :
>
> Hi Ulli,
>
> Can you clarify what these guidelines are and where they are (I did not
> see anything in a scan of the ML, nor on jenkins.
https://groups.google.com/g/jenkinsci-dev/c/9sZipk1PHns/m/mqtV7K8uAAAJ
would report there is the opposite.
Whilst Jira is a PITA, GitHub issues for me has more drawbacks.
We seem to be missing some improvements to Jira that would make it much
nicer day to day,
e.g.
Hi Ulli,
Can you clarify what these guidelines are and where they are (I did not see
anything in a scan of the ML, nor on jenkins.io)?
With my Jenkins user hat on I would be somewhat annoyed if I had to upgrade
Jenkins to get a small bug fix for a plugin.
Upgrading to every `.1` LTS is ok -
Going back to the earlier premise
> It seems to me that a number of problems are caused by ATH tests being
in a separate repository from the code under test
I would say the biggest problem is not so much that - rather that we do not
run enough of these tests for the code that is affected, early
What do we need to do to formalize this? Is it just a case of
a https://github.com/jenkins-infra/helpdesk ticket or something else?
Regards
/James
On Monday, February 14, 2022 at 9:30:21 AM UTC timja...@gmail.com wrote:
> Sounds good to move it to Jenkinsci very few usages by the looks of
s this also used for the windows agents?
I just merged a PR that had a passing CI only for master to fail
C:\Jenkins\workspace\ns_promoted-builds-plugin_master\target\tmp\j
h5732164843774452221\workspace\test1>powershell -command "Invoke-WebRequest
I found https://issues.jenkins.io/browse/JENKINS-67885 and have filed
https://github.com/jenkinsci/jenkins/pull/6305
On Wednesday, February 23, 2022 at 6:20:09 PM UTC Cathy Chan wrote:
> Hello everyone,
>
> Latest LTS RC was made public and it is ready to be tested. Final release
> is
Hi all,
A point raised in a permission update for a plugin in RPU is that we are
still granting users permission to Artifactory for deployment of a plugin
that they maintain even if the plugin is using CD.
> While I understand the reasoning for using the latest patch version of
an LTS I think this increases the number of unneeded version upgrades for
plugin authors.
warning: unpopular optinion follows
as does accepting *any* update to the BOM in your plugin when you do not
need a new API
> Thanks, James. For the login plugin we have a pinned dependency in our
pom.xml, so we plan on updating that so folks get a fixed version of Mailer
if that isn't present on their Jenkins instance.
you do not need to do that - they would get a fixed version of mailer if it
was not installed
> There's been a request for https://issues.jenkins.io/browse/JENKINS-67635 to
be backported
> Just merged in https://github.com/jenkinsci/jenkins/pull/6193
Given this area code area has proved to be a hot potato and the fix is not
in a weekly yet, I would be hesitant to say "go for it" on
The only issue I would have in early removal is if a plugin dropped
compatability whilst it was still supported for a supported LTS version,
that said we have no stake in what a plugin does or does not do. So I
guess I have no issue with dropping IE today and promoting Edge to T1.
it could
>> Using MRP as I described would not confuse any tool
>Depends on the tool. The problem would be that a source checkout at the
commit/tag would, if loaded as a project rather than a deployed artifact,
have a version different from the artifact. (Also true in JEP-229
components by default,
there is possibility of something part way between the current CD flow (no
junk pushes) and m-r-p.
m-r-p does not have to just take the current version and remove snapshot
and increment the last digit, nor does it need to push the commits back
(just the tag) (which I believe are your main
Hi all,
So thanks Baptiste for creating the team which I now have maintainership of
so can add users.
One issue I have is that users that are not currently a member of the
jenkinsci organisation can not be added to the team.
I guess normally adding a user to a plugin group via IRC would also
Hi all,
CloudBees has a number of plugins in jenkins-ci organisation that we are
maintainers of.
Currently when our internal teams change we need to modify multiple GitHub
repo settings and associated permissions RPU. This is cumbersome (and
error prone) for us, and for the reviewers of the
Hi Jamie,
incase you are not aware, there are a few acceptance tests for the Job DSL
plugin that have been failing for a while. If you would like to pick them
up to ensure the plugin stays healthy that would be great!
ooh maybe use some of our digital ocean credits to expand build capacity
>>>
>>> On Fri, Sep 10, 2021 at 10:00 AM Jesse Glick
>>> wrote:
>>>
>>>> On Fri, Sep 10, 2021 at 11:32 AM jn...@cloudbees.com <
>>>> jn...@cloudbees.com> wrote
If you do not want to go the stubbing route then if you want multi-branch
projects then you could possibly use something other than GitHub in a
container.
Atlassian has some code (but it is a pain to setup) - You may have some
luck with GitEa or GitLab containers, but I have not personally
version.
>- The project is uploading a new build, and this file is not there
>yet. Try again later.
>
> Any body can help me for this issue?
>
> Thank you.
> --Carol
> On Monday, October 4, 2021 at 5:39:44 AM UTC-4 jn...@cloudbees.com wrote:
>
>> &
> 2.1, Which JDK is good for this pulgin development, JDK 8 or JDK 11?
I would use JDK8. the plugin's parent POM should set things up correctly
that it should not matter - but JDK8 will give you fewer suprises for the
moment.
> 2.2, I want to use Eclipse. Which Eclipse can I install,
Hi all,
as Hacktober-fest is coming I may naively expect (hope!) some greater load
on the CI infrastructure.
I at least hope to find some time to get the ATH to zero failures at some
point.
Is there a plan to increase the capacity (temporarily or not) for this
period, or are the auto scaling
https://github.com/jenkins-infra/jenkins.io/pull/4547#pullrequestreview-747378748
On Monday, September 6, 2021 at 6:25:41 PM UTC+1 jn...@cloudbees.com wrote:
> > This is already covered as far as I can tell:
>
> I think Tim was referring to the "subject to risk"
ng some dependency updates (e.g. xstream),
>> as security scanners pick them up even though we know we aren't vulnerable.
>>
>> Do you think that's enough? Or some more specific wording on that page?
>>
>> Thanks
>> Tim
>>
>>
>>
>> On
You just beat me to it!
creating the PRs.
On Monday, September 6, 2021 at 5:28:34 PM UTC+1 m...@basilcrow.com wrote:
> It's jenkinsci/jenkins#5703, which pulled in jnr/jnr-ffi#252, which
> updated JUnit from 4 to 5 in jnr-ffi without putting the new JUnit 5
> JAR in the test scope. That means
Hi all,
something is looking very fishy with the incrementals built recently.
basically no tests run for plugins (at all)
It is not that they do fail, but that maven executes zero tests.
e.g.
mvn -U clean test -s "c:\Users\jnord\.m2\settings_no_mirror.xml"
-DfailIfNoTests
> see no reason in separating their versioning from the Jenkins LTS
releases.
what would the rationale be as to why this does this necessitate a bump in
the LTS? (
the docker images are (where) published with several tags
`lts` `lts-jdk8` ok so maybe the `2.203.1` tag you don't want to
, where the "fear"
>> dominates the market :-)
>>
>> Thanks James for the suggestion, great idea.
>>
>> Wadeck
>>
>> On Tuesday, August 31, 2021 at 3:58:38 PM UTC+2 jn...@cloudbees.com
>> wrote:
>>
>>> Hi all,
>>
Hi all,
I would like to propose that we add to the list of eligible criteria for
backporting the following
* is a dependency update with a known security issue
The reason for this if we have a dependency with a security issue that is
exploitable from Jenkins we already do include that as a
r backport
>>
>> I would suggest filing a backport PR
>>
>> On Fri, 20 Aug 2021 at 10:12, jn...@cloudbees.com
>> wrote:
>>
>>> Hi Basil et al,
>>>
>>> We have discovered a regression in the LTS caused by the commons-io
>
Hi Basil et al,
We have discovered a regression in the LTS caused by the commons-io upgrade
to 2.10.0. (from 2.8.0)
https://issues.apache.org/jira/browse/IO-741
This was fixed in 2.304 (https://github.com/jenkinsci/jenkins/pull/5623) in
commons-io 2.11.0
Whilst the regression was detected by
Hi all,
Can anyone pass some pointers onto a plugins CD failure?
https://github.com/jenkinsci/caffeine-api-plugin has some unreleased changes
https://github.com/jenkinsci/caffeine-api-plugin/releases
The status of the last commit is all green in GitHub
[image: caffeine.png]
yet the cd action
> James are you still against this API going in given
https://github.com/jenkinsci/jenkins/pull/5599?
my vote would still be against that PR, I had a large answer on the PR but
I am no longer sure where to have that discussion and how to make it
productive so have not published it.
I also
Hi Bill (et al) for those that are running nonstop or the like and have an
update / test cycle in the order of 6 months :
I would recommend that your customers probably want to start the planning /
validation to update to Java11 now even if this LTS version still runs on
Java8. Java11 is
https://issues.jenkins.io/browse/JENKINS-66139
/ https://github.com/jenkinsci/jenkins/pull/5621 that made it into 2.304
fixes a bug and should be eligible for backporting (it was missed as the
issue was not closed and missing the tag).
On Wednesday, August 11, 2021 at 10:04:41 AM UTC+1 jn
I do not think that this should go into the LTS. I would have been a -1
earlier on the PR itself had seen the PR but well that bird has flown (and
I left a comment in the PR as to why).
The LTS was selected a while ago, there has been a not insignificant amount
of work done in preparation for
Thanks!
On Wednesday, June 16, 2021 at 1:50:59 PM UTC+1 timja...@gmail.com wrote:
> I fixed the tag
>
> On Wed, 16 Jun 2021 at 13:29, jn...@cloudbees.com
> wrote:
>
>> Something looks wrong to me.
>>
>> based on https://github.com/jenkinsci/jenkins/pull
Something looks wrong to me.
based on https://github.com/jenkinsci/jenkins/pull/5573
and https://github.com/jenkinsci/jenkins/commits/jenkins-2.289.2-rc
the former looks reasonable for a .2 LTS, the latter looks like it is the
same as the last weekly release.
/James
On Wednesday, June 16,
would no
longer be observed.
On Thursday, June 10, 2021 at 6:34:29 PM UTC+1 jn...@cloudbees.com wrote:
> Let me try and rephrase this.
>
> We can not be stuck with 10 year old versions of thing, we all agree on
> that, but we also agree we can not just upgrade something and
of plugins we can break and the nature of them (10
installs vs 1000 etc etc) may vary from person to person
On Thursday, June 10, 2021 at 6:03:41 PM UTC+1 jn...@cloudbees.com wrote:
> > 1. Exclude the library on the plugin side (e.g. how Token Macro
> excludes ASM)
> 2. Mask the library's
> 1. Exclude the library on the plugin side (e.g. how Token Macro excludes
ASM)
2. Mask the library's classes (e.g. how JaCoCo masks ASM classes)2 ->
3. Shade the library into the plugin
1 -> Which is fine until the library evolves in a binary incompatible way..
and the ASM library is KNOWN
> . Even if you shade in ASM, you trade one problem
for another in that newer Java releases are unable to run Jenkins (I'd
give a pass for Java 16 since they changed some stuff related to
poking at internals).
How so, you upgrade the shaded library. You can also keep the original
shaded
Hi all,
I have just noticed a few PRs (some merged) to change ASM in core or
libraries that core depdns on (stapler).
I think we need to revert these and have a bigger think about ASM.
ASM historically (and I believe still true) evolved in a non compatible way.
In the past I have seen that
There is a regression with CLI SSH auth (sorry for saying this late, I
thought it was already reported).
I have a PR that fixes this (at least the CLITest in the 3.0.3 sshd-plugin
passes with https://github.com/jenkinsci/jenkins/pull/5506 cherry picked in
to the LTS branch).
Would be good to
bridge-method-injector 1.21
<https://github.com/infradna/bridge-method-injector/releases/tag/bridge-method-injector-parent-1.21>
has been released.
On Tuesday, May 11, 2021 at 12:34:27 PM UTC+1 jn...@cloudbees.com wrote:
> https://issues.jenkins.io/browse/JENKINS-65605 for tracking
oks abandoned? We may need to fork it
> to release a fix
>
> On Tue, 11 May 2021 at 11:00, jn...@cloudbees.com
> wrote:
>
>> There are 2 regressions that I know of currently in 2.288, one is a
>> blocker and the other possibly so.
>>
>> 1. the `WithBridgeMet
There are 2 regressions that I know of currently in 2.288, one is a
blocker and the other possibly so.
1. the `WithBridgeMethods` annotation no longer works and so we would break
compatibility with plugins using bridge methods from core PR to fix the
injector is
Hi all,
The jenkins-test-harness uses the default HTMLUnit CSS Error handle which
logs two warning for every CSS error it encounters.
Does anyone actually care about these errors? I am about to file a PR to
silence them, but thought someone may care and may have a use for them?
For example
omb wrote:
>
>> FTR I've removed guava in all maintained azure plugins today (except
>> azure-ad, needs a follow up to move to caffeine cache)
>>
>> Hopefully it's easy to generate your list again, is there a script?
>>
>> On Fri, 7 May 2021 at 11:09, jn..
Hi all,
So I have some strong opinions here and these are that nothing should ever
be auto applied.
Whatever format you have defined it will produce worse code in some
situations, and this results in code littered with
//AUTO_FORMAT_IGNORE:next_10_lines which does not aid to the readability
> is there any advantages in java 11 your looking forward to
Personally I would change my code to use a HTTP client library that has
async support, SNI, (all the things you expect) and not rely on a third
party API that does not have stellar backwards compatibility :)
Hi all,
I was looking for the ATH javadoc, but noticed it is not published
at https://javadoc.jenkins.io/component/
Is this purely a case that I need the ATH to bundle and publish a
`-javadocs` artifact to artifactory for it to show up, or is there
something else that needs to happen?
just to clarify as there are some points on this subject:
yes the breaking changes are already in a weekly release, but they are not
in the upcoming LTS (2.263.1).
So yes I was proposing to change the version to 3.x before the new LTS.
People using the weeklies are probably[1] already a bit
Hi all,
I would like to co-maintain the ATH. I've been trying to reduce it's
flakyness over time and its smooth running is fundamental to my day job.
I already have access on the GH repo - so this is a request for release
permissions.
75 matches
Mail list logo
