Hi,
bertagaz wrote (16 Feb 2015 14:37:56 GMT) :
> On Thu, Feb 12, 2015 at 12:22:45AM +0100, intrigeri wrote:
>> Here's one more: the proposed notification mechanism makes sense to me
>> for topic branches. But for "base" branches, it's more complicated:
>>
>> * when building after a Git push, [...]
>>
>> * when building daily, on failure I don't see how it can be useful to
>> notify the last person who merged something to into a base branch;
>> so, who is responsible to keep these branches in a buildable
>> state? [...]
>> Thoughts?
> Agree with that as stated in my previous email.
OK, good. Then I'll let you capture in the specification that problem,
and our currently preferred solution.
What follows is only interesting for Jenkins folks. I guess almost
everyone but DrWhax and bertagaz can stop here.
> I think it is doable to differenciate them, by splitting the daily
> and on git push job definiton maybe.
Looks a bit ugly a solution, and it would make the Jenkins config,
interface and reporting perhaps a bit too complicated. And we would
have two separate sources of information to answer the "does branch B
currently build fine?" question, which feels conceptually wrong.
E.g. consider the following scenario:
1. Someone pushes something that breaks the build
2. The post-push job is triggered, fails, and the person who pushed
gets notified; so far, so good, except the daily job still
pretends everything is fine
3. The person who pushed doesn't fix their stuff before the next
daily build
4. The next daily build fails, and then the RM is notified; in the
case of a base branch, this may be good to have the RM as
a fallback here. But then, we have two jobs in fail state in
Jenkins. Weird.
5. The RM fixes the build and pushes.
6. The post-push job is triggered, passes, and then the RM (who just
pushed) is notified that the build is back to normal, *but* the
person who pushed initially isn't notified that the problem has
been fixed (so might do duplicate work), and the daily job is
still in failing state until it is run again.
=> I think this trick would make the overall thing hard to understand
and draw conclusions from, for anyone not deeply involved in our
Jenkins stuff.
> Having a look at plugins might help, as well as how other projects
> do that (as you stated elsewhere).
Yep. At least the obvious candidate (Email-ext plugin) doesn't seem
able to email different recipients depending on what triggered the
build out-of-the-box. But apparently, one can set up two 'Script -
After Build' email triggers in the Email-ext configuration: one emails
the culprit, the other emails the RM. And then, they do something or
not depending on a variable we set during the build, based on what
triggered the build. Likely the cleaner and simpler solution.
Otherwise, we could have Jenkins email some pipe script that will
forward to the right person depending on 1. whether it's a base
branch; and 2. whether the build was triggered by a push or by
something else. This should work if we can get the email notification
to pass the needed info in it. E.g. the full console output currently
has "Started by timer" or "Started by an SCM change", but this is not
part of the email notification. Could work, but a bit hackish and all
kinds of things can go wrong.
Also, I've seen lots of people documenting crazy similar things with
some of these plugins: "Run Condition", "Conditional BuildStep",
"Flexible Publish" and "Any Build step". But then it gets too
complicated for me to dive into it right now.
If you prefer, in the future I can dump such research results into the
blueprint instead of here. Just tell me where it should go.
Cheers,
--
intrigeri
