I wanted to send an broader email to the dev list indicating that I will be
changing the name of what we have thus far referred to as "Jenkins Essentials"
to "Evergreen." The latter has been the name of the distribution system since
day one, and as we near completion on "Milestone 1", which will
On Tue, Aug 14, 2018 at 11:43 AM Michael Fowler
wrote:
> FATAL: execution failed
I do not recognize where this message line is coming from.
Throwing an `AbortException` is the correct response to a foreseeable,
user-level error condition. It should not be displayed as a stack
trace.
>From a
Hi Baptiste,
I don't know the implications of becoming a maintainer and I don't have a
lot of time to offer to this plugin since I work on something else now, but
if you feel that would work why not !
Le mardi 14 août 2018 17:56:23 UTC+2, Baptiste Mathus a écrit :
>
> Hello Gabriel,
> Did you
I agree with Alex. I believe that plugin maintainers should be default
assignees.
Maintainers should be triaging the issues, verifying their validity and
then unassigning themselves when they do not plan to work on them.
Otherwise we get to the case when many issues are invalid or mis-reported.
I also disagree. I reckon the best way is to assign the maintainer (however,
this word seems rather loaded in Jenkins world). If the assignee doesn’t want
to work on it for whatever reason they could free it up by unassigning and
labelling the issue appropriately.
This seems like a separate
I somewhat disagree with this, as I generally only see emails about issues
if I am assigned to it (maybe my settings are setup incorrectly
somewhere?). If I don't get emails, the issue will sit without me looking
at it for a fairly long period of time, which means the person could get
discouraged
Hey folks,
If, as you seem to, would like your work to get a bigger audience, you
probably want to look into how to host it under the official Jenkins update
center.
We generally kindly ask people to do a best effort to add features to
existing plugins, but in case this proves impractical, we
Le jeu. 9 août 2018 à 23:47, Jesse Glick a écrit :
> On Thu, Aug 9, 2018 at 12:57 PM Oleg Nenashev
> wrote:
> > Should I also change the default assignee in JIRA?
>
> I have no opinion about that. Generally I find the default assignee
> option to be a bad idea—you should assign an issue to
Hello,
You can file an issue in the Jenkins jira for this purpose. In the
'HOSTING' project.
Google for "Jenkins hosting plugin" to find the associated docs on the wiki.
Cheers!
Le mer. 8 août 2018 à 18:48, Mustafa Kuloglu <
mustafa.kulo...@generalmobile.com> a écrit :
> Hi,
> Of course we
Hello Gabriel,
Did you consider adopting this plugin and take over its maintenance? Didn't
check for that plugin, but if you didn't get an answer since long, then
maybe it's time to start the process.
Cheers
Le mar. 14 août 2018 à 14:44, Gabriel Augendre a
écrit :
> Hello,
>
> I made several
Thanks for the update, Tyler!
On Tue, Aug 14, 2018 at 5:38 PM R. Tyler Croy wrote:
> (replies inline)
>
> On Tue, 07 Aug 2018, Oleg Nenashev wrote:
>
> > Hi Tyler,
> >
> > Thanks for the feedback!
> >
> >
> > > I believe the only think which needs to be resolved which is likely
> just an
> > >
(replies inline)
On Tue, 07 Aug 2018, Oleg Nenashev wrote:
> Hi Tyler,
>
> Thanks for the feedback!
>
>
> > I believe the only think which needs to be resolved which is likely just an
> > obsolete part of the example YAML. The root `status` key in the YAML for a
> > "realized" BOM I don't
Hi Oleg,
I just created a Jenkins JIRA ID: Alien_Fromspace
My Github account: alienfs
Kind regards,
Hugo Boog
Op zaterdag 11 augustus 2018 15:57:57 UTC+2 schreef Oleg Nenashev:
>
> Hi Hugo,
>
> In order to complete ownership transfer, we need your GitHub and Jenkins
> JIRA IDs.
>
> Thanks in
Thanks Tyler, Daniel & Mark for the feedback so far.
I've updated the JEP based on this:
https://github.com/jenkinsci/jep/pull/176
Please review and let me know any further thoughts.
Tracy
On Mon, Aug 13, 2018 at 8:22 PM, R. Tyler Croy wrote:
>
> Following up on this thread, Tracy's taken
> On 12. Aug 2018, at 13:40, Dário Nascimento wrote:
>
> I want to execute a plugin using Jenkinsfile pipeline and I want that plugin
> to have the context (branch & job) without user interference. This plugin
> generates a token identifying the job so we can authenticate with other
>
I am using Jenkins for my works every day and searching the documentation
from jenkins.io. I also use Kubernetes to handle some work, and it provides
the multi-language version including Chinese, that is very nice. Found this
topic and interested in this proposal, hope this proposal can
be
Hello,
I made several changes to the Docker Swarm plugin (
https://github.com/jenkinsci/docker-swarm-plugin) and proposed them as pull
requests.
However I didn’t get an answer one month after contacting the original
author.
Please note that I have an integration branch where all features
Hi,
I want to execute a plugin using Jenkinsfile pipeline and I want that
plugin to have the context (branch & job) without user interference. This
plugin generates a token identifying the job so we can authenticate with
other services.
If I allow users to set the branch as env var, then the
> On 14. Aug 2018, at 05:34, Michael Fowler wrote:
>
> It's in a pipeline. No exception was thrown, that line was removed. The
> pipeline stopped on the next line. I checked the source for that plugin, it
> throws an exception. There's got to be a better way than having a stack trace
> in
19 matches
Mail list logo