Netbeans plugin support for Jenkins plugin dev
Hi all, I wonder if there are any Netbeans users who have tried Jenkins plugin dev user the Stapler plugin for Netbeans. I have installed and used the plugin successfully a while ago but am having trouble recently with getting a new project started. NB using Netbeans 8.2. Console output: BUILD FAILURE Total time: 01:25 min Finished at: 2018-12-05T08:52:57+02:00 Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.0.1:generate (default-cli) on project standalone-pom: The defined artifact is not an archetype -> [Help 1] Settings.xml http://maven.apache.org/SETTINGS/1.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd";> org.jenkins-ci.tools jenkins true repo.jenkins-ci.org https://repo.jenkins-ci.org/public/ repo.jenkins-ci.org https://repo.jenkins-ci.org/public/ repo.jenkins-ci.org https://repo.jenkins-ci.org/public/ m.g.o-public Thanks very much in advance Jon -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BMPq%3DW4ZZCRmgfZi1Y6LVt-EHS07Qr6v%2BNWOSBJS4LyznUuTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Disposable Jenkins & GitOps do not make a good match
On Mon, Dec 3, 2018 at 8:11 AM domi wrote: > Thanks James, thats an interesting path, but it does look like we would > have to build quite a lot around this to make it a good replacement of our > current infrastructure. We also did have a look at jenkins-x, but to be > honest, it is just way to much for us: first of all we don’t use k8s (we > use cloud foundry) and I would say that running jenkins-x cost us more then > our production environment, because of the number of pods (yes, we don’t > have a micro service architecture) > BTW CloudFoundry is pretty expensive compared to k8s ;). You should be able to host Jenkins X for a few hundred bucks a month with plenty of room for builds + preview environments. The footprint of Jenkins X is pretty small - other than a Nexus, we only run a few tiny pods when you're not running a build and we can turn many of those truly into serverless mode - so that you can use per second billing on some of the better cloud providers. > /Domi > > On 30 Nov 2018, at 15:02, James Strachan wrote: > > we solved this in Jenkins X through the use of Prow for handling webhooks > & orchestrating the serverless jenkins pod and then using kubernetes custom > resources to maintain state (pipeline activities, environments, teams, > releases etc) > https://jenkins-x.io/news/serverless-jenkins/ > > we then use an immutable docker image of jenkins that starts up (thanks to > the custom war packager) and processes each pipeline execution in a > separate container. > > > On Fri, Nov 30, 2018 at 1:51 PM domi wrote: > >> Hi, >> >> Since we now have JCasC and the job-dsl plugin it is easier then ever to >> treat jenkins as a disposable resource and just recreate it from scratch >> whenever you feel the need for it. >> We do have build everything around this idea and reinstall our whole >> build infrastructure every time we need to update jenkins or even just a >> plugin (we create a docker image with all required plugins preinstalled). >> >> But there are two issues which hurt us quite a bit: >> >> 1. Pipeline jobs do not listen on any commit webhooks before the job was >> not executed at least once (in our case Bitbucket, but the same is true for >> Github) >> 2. A multi branch pipeline (organizationFolder, *-branch-source-plugin) >> job will trigger a build for every single branch just discovered. This is >> quite a problem in case you have build your processes around git (some call >> it GitOps). e.g. if every time your master branch gets build something >> special happens: build a new release version of a library or even install >> something to some environment. >> >> These two issues together cause us quite some problem, because every time >> we setup a new environment the following happens: >> >> The branch source plugin (in our case Bitbucket) scans the whole >> organisation for branches, will trigger builds and therefore: new releases >> of libraries and artefacts get build and some stuff gets installed because >> the builds for many of our ‘master’ branches are triggered too. >> Then I somehow have to trigger a build for all other pipelines (not >> managed by the branch-source-plugin) which should listen on any git >> webhooks, because otherwise they will never be triggered >> >> >> Does anyone have the same experience? How do you work around them? >> >> I have some ideas on how to solve/ workaround it: >> - problem 1: write a plugin which is able to abort the build in case it >> is the first run and the job is configured to listen on webhooks (e.g. >> Bitbucket or GitHub), then after installing the fresh environment, just >> loop through all jobs (with groovy) and trigger all which have a hook >> configured and let the first run fail on purpose. >> - problem 2: extends >> https://github.com/jenkinsci/basic-branch-build-strategies-plugin to >> some how skip some branches at the initial organisation scanning, I already >> created an issue for this: >> https://issues.jenkins-ci.org/browse/JENKINS-54861 >> >> But to be very honest, most of this sound some how hackisch and I hope >> someone else has a better idea on how to do this stuff properly. >> >> Many thanks >> Domi >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jenkinsci-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/FA18D443-D4CA-4512-BAD1-255D6E3385C8%40fortysix.ch >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > James > --- > Twitter: @jstrachan > Blog: https://medium.com/@jstrachan/ > > Jenkins X: a CI/CD solution for modern cloud applications on Kubernetes > http://jenkins-x.io/ > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails f
Re: embeddable-build-status-plugin orphaned?
Thanks for the response, Marius! Hi Thomas, I have granted you the write permissions to the repo and made you a default assignee in JIRA. Thanks again for your interest, and welcome aboard! To get the release permissions, please submit a pull request to https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-embeddable-build-status.yml Best regards, Oleg On Tuesday, December 4, 2018 at 3:39:45 PM UTC+1, Thomas Döring wrote: > > > Oh. I forgot: My GitHub username is "thomas-dee". My Jenkins-ID is > "thomas_dee". > > Am Montag, 3. Dezember 2018 20:13:26 UTC+1 schrieb Thomas Döring: >> >> Hello again, >> >> Well then: I hereby request adoption for the >> embeddable-build-status-plugin. >> And Marius: There will be no new release until January. >> >> Greetings, >> Thomas. >> >> Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas: >>> >>> Hi! >>> >>> I have no interest in maintaining embeddable-build-status-plugin, so if >>> my opinion matters, anyone else is welcome to step up! >>> >>> (I have some slight interest in having the plugin continue working, and >>> in having it produce badges in the common shields.io style, until end >>> of >>> December, when I plan to shut down my Jenkins instance.) >>> >>> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: >>> > Added [1]Marius Gedminas to Cc. >>> > Since Jesse Glick says he is not a maintainer, Marius is the last >>> contributor >>> > to release 2 versions of the plugin before Jesse. >>> > >>> > Let's set a standard 2-week timeout. >>> > >>> > BR, Oleg >>> > >>> > >>> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net> >>> wrote: >>> > >>> > Is there any way to "adopt" the plugin if there is no current >>> maintainer >>> > (since I can ask no one to approve). >>> > >>> > Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse Glick: >>> > >>> > On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev < >>> o.v.ne...@gmail.com> >>> > wrote: >>> > > I will ask the maintainers >>> > >>> > I do not know if there _are_ any maintainers. Not me. >>> >>> Marius Gedminas >>> -- >>> Q: How many IBM CPU's does it take to execute a job? >>> A: Four; three to hold it down, and one to rip its head off. >>> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/10021d04-161d-4623-becf-59067be1c740%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Alternative directory implementation of ArtifactManager?
On Tue, Dec 4, 2018 at 3:48 AM Staffan Forsell wrote: > How are moves and renames handled? E.g. if a admin moves a job to a folder? > How does the ArtifactManager handle this? For `StandardArtifactManager`, that would be implicit in the job directory itself moving. For others, including `artifact-manager-s3`, this is not handled automatically. `JCloudsArtifactManager.key` could perhaps be made non-`transient` to track the originally stored location, or there could be an `ItemListener.onLocationChanged` to physically relocate the blob(s), or the `unique-id` plugin could be relied on for another key which persists across moves. For now we decided to keep things simple and transparent—there is a predictable blob location based on what you see in Jenkins—and just punt on the use case of historical builds preceding a move/rename. (On a related note, by default `artifact-manager-s3` declines to remove artifacts after build deletion in Jenkins, on the grounds that AWS retention policies and Glacier migration are likely better, and we want the Jenkins master to require minimal IAM permissions: a compromised master should not be able to destroy or alter cloud data.) -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Wii6KnaMpkz_oAsLyH74JbkP%3Da4MEk8-twJHgWRu7tA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: embeddable-build-status-plugin orphaned?
Oh. I forgot: My GitHub username is "thomas-dee". My Jenkins-ID is "thomas_dee". Am Montag, 3. Dezember 2018 20:13:26 UTC+1 schrieb Thomas Döring: > > Hello again, > > Well then: I hereby request adoption for the > embeddable-build-status-plugin. > And Marius: There will be no new release until January. > > Greetings, > Thomas. > > Am Montag, 3. Dezember 2018 14:30:30 UTC+1 schrieb Marius Gedminas: >> >> Hi! >> >> I have no interest in maintaining embeddable-build-status-plugin, so if >> my opinion matters, anyone else is welcome to step up! >> >> (I have some slight interest in having the plugin continue working, and >> in having it produce badges in the common shields.io style, until end of >> December, when I plan to shut down my Jenkins instance.) >> >> On Mon, Dec 03, 2018 at 08:39:08AM +0100, Oleg Nenashev wrote: >> > Added [1]Marius Gedminas to Cc. >> > Since Jesse Glick says he is not a maintainer, Marius is the last >> contributor >> > to release 2 versions of the plugin before Jesse. >> > >> > Let's set a standard 2-week timeout. >> > >> > BR, Oleg >> > >> > >> > On Mon, Dec 3, 2018 at 8:13 AM Thomas Döring <[2]thoma...@gmx.net> >> wrote: >> > >> > Is there any way to "adopt" the plugin if there is no current >> maintainer >> > (since I can ask no one to approve). >> > >> > Am Freitag, 30. November 2018 16:01:58 UTC+1 schrieb Jesse Glick: >> > >> > On Thu, Nov 29, 2018 at 3:33 PM Oleg Nenashev < >> o.v.ne...@gmail.com> >> > wrote: >> > > I will ask the maintainers >> > >> > I do not know if there _are_ any maintainers. Not me. >> >> Marius Gedminas >> -- >> Q: How many IBM CPU's does it take to execute a job? >> A: Four; three to hold it down, and one to rip its head off. >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b7f0d860-5589-4f9d-afa7-1c1a8f0aeb84%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Jenkins 2.150.1 LTS RC testing started
Hello, ATH does not show any regression connected to the LTS. Regards, Lucie On Friday, November 23, 2018 at 12:35:46 PM UTC+1, ogondza wrote: > > Hello everyone, > > Latest LTS RC was made public and it is ready to be tested. Final > release is scheduled for 2018-12-05. > > Please, report your findings in this thread. > > Download bits from > http://mirrors.jenkins-ci.org/war-stable-rc/2.150.1/jenkins.war > > Thanks! > -- > oliver > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e7c70ab5-c06b-4a3f-917c-0e28a13903e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: GSoC proposal about the Multi-branch for Gitlab
Hi Rick, Thanks for starting this discussion! I think it is good to be published as a draft project idea on jenkins.io. I suggest to also bring up this topic in the Pipeline Authoring SIG (e.g. just adding it to CC). Best regards, Oleg On Tuesday, December 4, 2018 at 2:52:54 AM UTC+1, Rick wrote: > > hi: > > I made a proposal about the Multi-branch support for Gitlab. > > Here is the doc link. > > https://docs.google.com/document/d/1Gqz4LyU5sw6I50OdAVsQSW_WPNDlvXg4Ic9NdcYj4Ts/edit?usp=sharing > > Any comments are welcome. > > Thanks, > Rick > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d922ea0c-b372-4da2-b85f-7616c8fd6d95%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Fail to pass jenkins infra ci
This was a temporary infra issue, try again. > On 4. Dec 2018, at 04:52, 黄索远 wrote: > > hi, guys: > > I am trying to publish my plugin to jenkins infra > > The git repo is https://github.com/jenkinsci/list-git-branches-plugin > > Hosting Request is https://issues.jenkins-ci.org/browse/HOSTING-672 > > related MR is > https://github.com/jenkins-infra/repository-permissions-updater/pull/948 > > However the ci told me that > https://ci.jenkins.io/blue/organizations/jenkins/Infra%2Frepository-permissions-updater/detail/PR-948/1/pipeline/15 > > > Exception in thread "main" java.lang.IllegalStateException: User name not > known to Artifactory: huangsuoyuan > > > > > But I actually login to https://repo.jenkins-ci.org > > I am not sure what is going wrong here. Can somebody help me on this? > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/1fc87092-61a6-4f55-ae48-15c93fa3639e%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/8C33778B-C928-46B8-9CF5-58847F509FFF%40beckweb.net. For more options, visit https://groups.google.com/d/optout.
Re: concurrent security in role-strategy-plugin plugin
I have already submitted a PR for this question. Can someone give me some advice? https://github.com/jenkinsci/role-strategy-plugin/pull/48 在 2018年12月2日星期日 UTC+8下午10:53:48，夏润泽写道： > > Hello > I want to try to fix the concurrency issue of the role strategy > plugin. How should I achieve this step? > https://issues.jenkins-ci.org/browse/JENKINS-54900 > I think this part of the work mainly needs to achieve the following > two goals. > 1.Requests for add/delete/modify API calls need to ensure thread > security > 2.Jenkins will perform the authentication of the system by obtaining > the ACL. Therefore, it should be ensured that the role can be read while > the role is being modified to ensure that the performance of the system is > not reduced. > My initial idea is > 1. to replace some data structures to ensure that reading and writing > can be done simultaneously. > 2. The API that writes to the grantedRoles object of > RoleBasedAuthorizationStrategy needs to be synchronized. > > > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/267cffc2-281e-4dc5-8c9f-e9391d4033c3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Alternative directory implementation of ArtifactManager?
I started and got the basic function and configuration working. How are moves and renames handled? E.g. if a admin moves a job to a folder? How does the ArtifactManager handle this? I was thinking of saving the redirected artifact build dir in the build.xml in order to be able to keep the artifacts working in case of a move. The alternative is to move the artifacts so they match the new build dir structure in the alternative location, but I don't know where I would do this... I found StashAwareArtifactManager.copyAllArtifactsAndStashes() from the s3-plugn implementation, but this implies handling stashes also which is not in the scope for my ArtifactManager. Is there a correct way of handling artifacts when jobs are moved? /S On Friday, 30 November 2018 20:06:28 UTC+1, Jesse Glick wrote: > > On Fri, Nov 30, 2018 at 8:59 AM Staffan Forsell > wrote: > > artifact-manager-s3 seems to contain examples of most of the things > needed. > > Too complicated for your purpose. Creating a plugin with a lightly > edited clone of `StandardArtifactManager` would suffice. (Use the > Maven archetype for a plugin with global configuration, so the user > can pick the location in the GUI or using configuration-as-code.) > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a4d2e037-43a1-4f2c-abe3-286717cce3bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
