Project

General

Profile

Feature #9719

Feature #9614: Automated builds: complete phase two

Configure Jenkins notifications to our ticket tracker

Added by bertagaz about 4 years ago. Updated 3 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Continuous Integration
Target version:
-
Start date:
07/10/2015
Due date:
% Done:

10%

Starter:
No
Affected tool:

Description

We specified in the automated builds specifications that Jenkins should be able to notify a branch ticket on Redmine:

Otherwise if the build fails I *need* to see the build logs
      And the developer who proposed the merge must be notified
      And the ticket should be reassigned to the branch submitter
      And QA check should be set to "Dev needed" 

There's no Redmine plugins for Jenkins out there.

But Redmine offers two ways to do that:

  • By email
  • Using its API

The first solution can use Jenkins abilities to send emails with configurable/scriptable subjects and bodies with the email-ext plugin. This shouldn't require much complex setup to work on, only in the Jenkins{,-job-builder} side, as there's probably nothing to do on Redmine.

The second solution can make use of the python-redmine package in Debian. This requires yet another homebrewed script, with little setup in Redmine.

Note that changing the ticket state is easy, but assigning a different owner might be a bit more difficult. All that Jenkins knows about is a commit author email, not a Redmine username, so maybe the email solution won't be able to cover every bits of the specification.

Let's try to setup the first one to see if it's that easy, and if not so useable we can still fallback on the API implementation.

In this thread we had pretty good discussions about what we need and how to get it:


Related issues

Related to Tails - Feature #11355: Re-enable Jenkins notifications on ISO build/test failure In Progress 08/28/2017
Related to Tails - Feature #12715: Decide what builds we will try to reproduce in Jenkins Resolved 06/15/2017
Blocked by Tails - Feature #15878: Switch to GitLab Confirmed 08/30/2018

History

#1 Updated by bertagaz about 4 years ago

  • Subject changed from Configure Jenkins to notify Redmine to Configure Jenkins notifications to Redmine
  • Parent task set to #9614

#2 Updated by intrigeri about 4 years ago

Note that changing the ticket state is easy, but assigning a different owner might be a bit more difficult. All that Jenkins knows about is a commit author email, not a Redmine username, so maybe the email solution won't be able to cover every bits of the specification.

Indeed, good catch.

The sanest and easiest way I see to handle this is to assume that whatever is on the left of '@' in the email address is the Redmine account name (it works for most of our usual committers); and for exceptions, maintain a file somewhere that maps committers email address to Redmine accounts name. Notes about this idea:

  • What to do when reassigning the ticket fails because we guessed the Redmine user account wrongly (and there's no corresponding entry in the override mapping file)? With the email solution, Jenkins won't even know it has failed. And actually, nobody will, since Redmine doesn't tell you when some email command fails. So the ticket will stay on the reviewer's plate, which is fine: at this stage of the branch dev/review process, the reviewer is the one who is looking at the ticket, so they're the best placed person to notice that it failed to be reassigned, and then 1. do it themselves; 2. notify us so that we add an entry in the override mapping file. Bonus: the branch's developer will be notified of the build failure, so maybe they can make sure that the ticket is reassigned to them (unlikely it works, but who knows). Still, this leaves one corner case open: when the ticket is Ready for QA, but no assignee is set (which is our default, at least in theory). In that case we have to rely on the current RM regularly looking at unassigned Ready for QA tickets (which is part of their duty), and/or on the branch's developer to notice that the build failed, and reassign the ticket to themselves. All that is kinda suboptimal, but let's try without any special handling first, and readjust if it doesn't work, OK? A simple improvement could be to Cc the last committer when emailing Redmine, which should be trivial and possibly useful; and also, perhaps Cc the current assignee (reviewer), but I expect it will be hard to find out their email address, so let's forget that one.
  • Perhaps some heuristics that use the committer's name (as opposed to their email address) could optimize this a bit, and make the fallback to the mapping file less often needed, but IMO that's premature optimization.

Other (crazy) ideas I've discarded:

  • query Redmine for user account names matching a given email address; I doubt that it's possible without writing (and maintaining) a custom Redmine plugin
  • set up a LDAP directory with all needed info about project members, such as email address, Redmine account name, etc.: totally overkill in the current state of our needs

Let's try to setup the first one to see if it's that easy, and if not so useable we can still fallback on the API implementation.

Full ACK!

#3 Updated by intrigeri about 4 years ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10
  • QA Check deleted (Info Needed)

#4 Updated by bertagaz almost 4 years ago

  • Target version changed from Tails_1.5 to Tails_1.6

postponing

#5 Updated by intrigeri almost 4 years ago

As written over email:

It seems that this ticket strongly relies on our branches name containing the ticket number. That's merely a "SHOULD" in our specs, but it seems quite easy and useful, and you flagged it for 1.5, so I'm assuming you want to take care of it soon anyway.

So, should we:

  • make it clear(er) in our contributors doc that branches must be named this way?
  • rename existing active branches that don't satisfy this requirement?

Another idea: do we want to enforce this? It could be painful sometimes, but perhaps that's still the easiest way to get a consistent dev. experience?

#6 Updated by bertagaz almost 4 years ago

  • Target version changed from Tails_1.6 to Tails_1.7

Delaying, I won't realistically have time to work on this during this release iteration.

#7 Updated by intrigeri almost 4 years ago

Keep it mind that this one is merely a should => I would postpone it a bit further.

#8 Updated by bertagaz almost 4 years ago

Yes, I'll see during the 1.7 release cycle.

#9 Updated by bertagaz almost 4 years ago

  • Target version changed from Tails_1.7 to Tails_1.8

Postponing, I won't have time to work on this during this cycle I think.

#10 Updated by bertagaz over 3 years ago

  • Target version changed from Tails_1.8 to Tails_2.0

Postponing

#11 Updated by bertagaz over 3 years ago

  • Target version changed from Tails_2.0 to Tails_2.2

Postponing, too much on my plate for 2.0

#12 Updated by intrigeri over 3 years ago

  • Description updated (diff)

Added pointers to relevant discussion that may partly surpesede what's on the ticket description / blueprint.

#13 Updated by bertagaz over 3 years ago

  • Target version changed from Tails_2.2 to Tails_2.3

Postponing: won't have time during this release to work on that.

#14 Updated by intrigeri over 3 years ago

  • Target version changed from Tails_2.3 to Tails_2.5

I think that #11355 is way higher priority than this one: let's fix the MUST:s first, and then we can add the SHOULD:s :)

#15 Updated by intrigeri about 3 years ago

  • Related to Feature #11355: Re-enable Jenkins notifications on ISO build/test failure added

#16 Updated by bertagaz about 3 years ago

  • Target version changed from Tails_2.5 to Tails_2.6

Can wait one release for me to focus on something else.

#17 Updated by anonym almost 3 years ago

  • Target version changed from Tails_2.6 to Tails_2.7

#18 Updated by bertagaz almost 3 years ago

  • Target version changed from Tails_2.7 to 2017

#19 Updated by bertagaz about 2 years ago

  • Related to Feature #12715: Decide what builds we will try to reproduce in Jenkins added

#20 Updated by BitingBird almost 2 years ago

  • Target version deleted (2017)

#21 Updated by intrigeri 3 months ago

  • Subject changed from Configure Jenkins notifications to Redmine to Configure Jenkins notifications to our ticket tracker
  • Assignee deleted (bertagaz)

We'll migrate our ticket tracking to GitLab soonish so I don't think it's worth implementing a Redmine-specific thing here right now ⇒ deassigning as this is currently not actionable.

And in passing, if we also migrated our CI to GitLab, we would get this for free.

#22 Updated by intrigeri 3 months ago

Also available in: Atom PDF