request hosting for Build Result Publisher plugin

[Alex]

source code: https://github.com/alexeyOnGitHub/jenkins-publisher-plugin

I'm the author. name on GitHub: alexeyOnGitHub

Plugin summary: Publish notifications for all completed builds to a RabbitMQ instance.

(hoping to have more publishers than just RabbitMQ in it, that's why didn't call it "RabbitMQ Publisher Plugin"

the Git repo name could be build-result-publisher-plugin

Sample notification message:

{
  "jenkins_url": "http://localhost:8080/",
  "job_name": "check-coverage",
  "build_number": 61,
  "result": "FAILURE",
  "id": "61",
  "test_results": {
    "total_count": 7,
    "skip_count": 1,
    "fail_count": 2,
    "failed_tests": [
        "com.company.Class2Test.anotherBrokenTest",
        "com.company.Class2Test.thisWillBeBroken"
    ]
  }
}

[Oleg Nenashev]

Did you consider contributing to existing plugins instead of creating new ones?
There're several plugins addressing your use.case. Example: https://wiki.jenkins-ci.org/display/JENKINS/Notification+Plugin

понедельник, 13 июля 2015 г., 23:11:31 UTC+3 пользователь Alex написал:

[Alex]

I saw that plugin. it does something similar indeed. but it has the following differences:

1. it operates on the Job level. you need to add a step for a job to publish its results. my plugin operates on Jenkins level: all builds are published. we have a large Jenkins install with thousands(++) of build jobs and dozens of workers. 

2. this plugin has a timeout (30 seconds as I see). this means tasks can be blocked for up to 30 seconds. my plugin puts notifications into a queue that is later processed in a separate thread. this way we don't block Jenkins if the publishing mechanism is slow or even broken for whatever reason. e.g. in the case of RabbitMQ, publishers will be blocked when target RabbitMQ "exchange/queue" is full - say, due to no free disk space. we don't want Jenkins to block all jobs when this happens. and using timeouts for this would mean notifications will be lost if  not completed in 30 seconds. so.. if the target system is temporary clogged and does not accept messages, Notification Plugin will

1) spend extra 30 seconds for each job plus     2) probably drop messages after that (I assume, have not checked that yet). 

in our case with a heavily loaded Jenkins server with thousands of jobs we cannot add extra 30 seconds to each build.

[Oleg Nenashev]

IMO it would be better to merge the functionality into the Notifications plugin.
Both mentioned cases can be addressed in the existing plugin, which may be helpful for the current plugin users.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/ets64nbrcxY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ca932216-b6f7-4c34-ab7a-c27f84ac130f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alex]

I see your point. but this would not be simply adding functionality really. 

more like rewriting the whole Notifications plugin and then integrating its http/tcp/udp publishers into the new code. take a look at the source code of both plugins.

I totally see value in what is in Notifications plugin now (like HTTP/UDP/TCP publishers). I would probably want that in my new plugin (even though I personally don't need this now).

who is the "gatekeeper" for that plugin? who would approve/reject changes in it? would those authors be okay with those massive changes (which would essentially produce a completely new plugin)?

[Alex]

don't see a way to edit the Topic name. I would want it to be called "Build Publisher Plugin" rather than "Build Result Publisher Plugin".

[Oleg Nenashev]

Added Notification plugin owners to Cc. They can provide a better feedback on the features feasibility.

IMHO there's no merge showstoppers in the code. Background monitoring and submissions would be a nice feature for Notifications plugin, so I thinks we could try this way.

Another applicable way would be to build such reporting system on the top of the Metrics plugin functionality. Such approach could provide much more extensibility.

2015-07-14 0:17 GMT+03:00 Alex <als...@gmail.com>:

don't see a way to edit the Topic name. I would want it to be called "Build Publisher Plugin" rather than "Build Result Publisher Plugin".

--

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/ets64nbrcxY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0a75f995-f27c-4d2e-93a8-607dd9d432a9%40googlegroups.com.