Re: Builds email notifications
> Jenkins does have this functionality: with "E-mail Notification" > configuration under the "Post-build Actions" section. Emails are sent > when a build fails, becomes unstable or returns to stable, to a > specified ML and the authors of the breakage. > > Is there any objection if I configure this for our > `cassandra-*-artifacts` builds? > And if I create a builds@ ML where these get cc'd? Done. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[GitHub] [cassandra-builds] michaelsembwever opened a new pull request #10: Configure so emails are sent when a build fails…
michaelsembwever opened a new pull request #10: Configure so emails are sent when a build fails… URL: https://github.com/apache/cassandra-builds/pull/10 **I have no idea how to test or deploy this change.** --- Configure so emails are sent when a build fails, becomes unstable or returns to stable, to the builds@ ML and the authors of the breakage. ref: - https://lists.apache.org/thread.html/e170de03f9b89e4dff06a5f524c7fb0ede6790f9f08c75aa50320889@ - https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.helpers.publisher.PublisherContext.extendedEmail This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[GitHub] [cassandra-builds] michaelsembwever commented on issue #10: Configure so emails are sent when a build fails…
michaelsembwever commented on issue #10: Configure so emails are sent when a build fails… URL: https://github.com/apache/cassandra-builds/pull/10#issuecomment-527966144 @mshuler @spodkowinski This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Builds email notifications
On 9/4/19 8:33 AM, Mick Semb Wever wrote:
Jenkins does have this functionality: with "E-mail Notification"
configuration under the "Post-build Actions" section. Emails are sent
when a build fails, becomes unstable or returns to stable, to a
specified ML and the authors of the breakage.
Is there any objection if I configure this for our
`cassandra-*-artifacts` builds?
And if I create a builds@ ML where these get cc'd?
Done.
Was this done by hand in Jenkins? I don't see any new commits to the job
DSL, so the changes will get overwritten on the next cassandra-build
push when the job configs are rebuilt.
https://gitbox.apache.org/repos/asf?p=cassandra-builds.git
Job DSL configs are in jenkins-dsl/cassandra_job_dsl_seed.groovy and DSL
API reference can be viewed in Jenkins at
https://builds.apache.org/plugin/job-dsl/api-viewer/index.html
This is going to be a job('Cassandra-template-artifacts') {publishers
...} step in the template, if I recall. Not sure what email plugins are
installed. I'd be happy to look at a PR.
--
Kind regards,
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Builds email notifications
> This is going to be a job('Cassandra-template-artifacts') {publishers
> ...} step in the template, if I recall. Not sure what email plugins are
> installed. I'd be happy to look at a PR.
Quick or the dead around here :-)
It has been done manually, and a separate PR opened here:
https://github.com/apache/cassandra-builds/pull/10
But I need some help on testing and deploying it, so a review/input would be
most appreciated!
cheers,
Mick
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
[GitHub] [cassandra-builds] mshuler commented on a change in pull request #10: Configure so emails are sent when a build fails…
mshuler commented on a change in pull request #10: Configure so emails are sent
when a build fails…
URL: https://github.com/apache/cassandra-builds/pull/10#discussion_r320851818
##
File path: jenkins-dsl/cassandra_job_dsl_seed.groovy
##
@@ -105,6 +105,19 @@ job('Cassandra-template-artifacts') {
javadocDir 'build/javadoc'
keepAll false
}
+extendedEmail {
+recipientList('bui...@cassandra.apache.org')
+triggers {
+stillUnstable {
Review comment:
stillUnstable is defined as:
// Triggers an email if the build status is "Unstable" for two or more
builds in a row.
I think we're going for failure{} and fixed{}? These triggers would send on
every build failure - there is an alternate firstFailure{} trigger, so only one
email would be sent in the case of repeated build failures. I can't remember if
we used regression{} in other jenkinses, but that might suit the needs for this
without spamming every failure{} too. I'll see if I can find some old DSL foo
to see what we used.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Builds email notifications
On 9/4/19 9:01 AM, Mick Semb Wever wrote:
This is going to be a job('Cassandra-template-artifacts') {publishers
...} step in the template, if I recall. Not sure what email plugins are
installed. I'd be happy to look at a PR.
Quick or the dead around here :-)
It has been done manually, and a separate PR opened here:
https://github.com/apache/cassandra-builds/pull/10
But I need some help on testing and deploying it, so a review/input would be
most appreciated!
I'm sure we were typing at the same time :) (PR comments went to dev@,
so we all saw that, too..)
Testing DSL changes is a PITA and needs some sort of non-functional
meta-DSL job to configure dummy jobs. Just committing, watching for
errors in the seed job and fixing them isn't very problematic. The
existing jobs are not touched, if the DSL does not parse correctly, and
the errors are usually pretty clear where the issue might be. Just do it
in prod, once it looks about what we want. ;)
--
Michael
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: 4.0 alpha before apachecon?
Quick update on 4.0-alpha1 builds: - tar artifacts are published to maven[0] and sha d4054e0c tagged as 4.0-alpha1-tentative (thanks to Marcus Eriksson for asking this morning to look at a cassandra-diff PR for maven publish, which gave me a fresh idea on fixing .m2/settings.xml for new-laptop publish problems.. Fix worked!) - debs built locally, but upload to people.a.o failed, which we've documented a change for this to go to a new svn pre-release location, but I need to work this out in the release prep. - rpm upload to new svn location, too, once debs are done. Once I have the packages uploaded, we can start a (quick?) vote! I'll have some time to keep banging on the uploads later this afternoon and see how far I can get. I'm on a mobile hotspot with a decent connection at the moment :) [0] https://repository.apache.org/content/repositories/orgapachecassandra-1174/org/apache/cassandra/apache-cassandra/4.0-alpha1/ Michael On 8/29/19 2:30 PM, Joseph Lynch wrote: We hashed this out a bit in slack and I think the current rough consensus (please speak up if you don't agree) is that we update our release guidelines [1] to allow API changes between alpha and beta as the common artifact is useful for testing and we will probably end up finding API breakage while testing that must be fixed. Benedict helped out by creating 4.0-alpha [2] and 4.0-beta [3] fix versions so we can track what tickets are (roughly) blocking the next alpha/beta release. If you feel that something you're working on should block the alpha or the beta please help out and tag it with the proper fix version. The idea is that we know which outstanding tickets exist and are impacting the next alpha/beta, even if we ignore it and cut anyways at least we can separate "this has to happen before beta" from "this has to happen before release candidates". I think the next decision is should we just cut 4.0-alpha1 now given that Michael has some cycles regardless of the known issues and start using the new fix versions for the 4.0-alpha2 release? I personally feel we should cut 4.0-alpha1 with every imaginable "expect this release to break" disclaimer and start working towards 4.0-alpha2. [1] https://docs.google.com/document/d/1bS6sr-HSrHFjZb0welife6Qx7u3ZDgRiAoENMLYlfz8/edit [2] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-alpha [3] https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%204.0-beta What do people think? -Joey On Wed, Aug 28, 2019 at 10:58 AM Michael Shuler wrote: Thanks for the reminder :) I have a few days of availability to prep a 4.0 alpha release. It's an alpha, so I don't have a problem with known issues needing work. I will have an internet-less period of time starting roughly Tuesday 9/3 through about Friday 9/13. I might get lucky and have a little network access in the middle of that time, but I'm not counting on it. -- Michael On 8/28/19 10:51 AM, Jon Haddad wrote: Hey folks, I think it's time we cut a 4.0 alpha release. Before I put up a vote thread, is there a reason not to have a 4.0 alpha before ApacheCon / Cassandra Summit? There's a handful of small issues that I should be done for 4.0 (client list in virtual tables, dynamic snitch improvements, fixing token counts), I'm not trying to suggest we don't include them, but they're small enough I think it's OK to merge them in following the first alpha. Jon - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[GitHub] [cassandra-builds] michaelsembwever commented on a change in pull request #10: Configure so emails are sent when a build fails…
michaelsembwever commented on a change in pull request #10: Configure so emails
are sent when a build fails…
URL: https://github.com/apache/cassandra-builds/pull/10#discussion_r320936973
##
File path: jenkins-dsl/cassandra_job_dsl_seed.groovy
##
@@ -105,6 +105,19 @@ job('Cassandra-template-artifacts') {
javadocDir 'build/javadoc'
keepAll false
}
+extendedEmail {
+recipientList('bui...@cassandra.apache.org')
+triggers {
+stillUnstable {
Review comment:
Fixed.
> These triggers would send on every build failure - there is an alternate
firstFailure{} trigger, so only one email would be sent in the case of repeated
build failures.
Let's start with `failure {}`, as no one should be committing on top of a
broken HEAD. (In a perfect world, that should be as bad as breaking it to begin
with.)
(If/When we change to `firstFailure{}` then `culprits()` looks like it can
be removed.)
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
