I've pulled together some code that does roughly what I think Jesse is looking for by: 1. Listening on #jenkins-commits channel on IRC 2. Watching for a message with 'prepare release' in it (the standard Maven release string), pulling the version number and commit ID from that 3. Call the GitHub API to list all tags from the affected repository to try and find the tag name prior to the current version number (e.g. try and see if jenkins-1.500 is a tag if jenkins-1.501 is listed in the current commit message). Flag an issue if the previous tag can't be found (i.e. it was created with a different naming style) 4. Call the GitHub API to compare the previous tag with the commit ID from step 2 (same as using 'git log tag1...tag2') 5. Parse the commit messages for 'FIXED JENKINS-n+' (fixed issue) or 'JENKINS-n+' (changed issue) to build a list of commit messages per issue 6. Call the Jira API to add comments to the affected issues (this step hasn't been properly tested as I don't want to comment on the live defects)
Whilst doing this, it got me thinking: Jira supports a 'fixed in' field for each issue, which we don't currently set since we don't maintain a list of Jenkins release numbers in Jira (I think this is just because it's historically required too much manual effort). However, Jira allows managing of version details through the REST API, so it would be possible for my IRC Bot to create the version number in Jira as it sees the release commit note and then set the correct release per issue. This also then also allows users to set the 'affects versions' field, meaning it would be easy to view which issues are still relevant at any point in time. Does anyone have any thoughts on this being investigated further? As #jenkins-commits also shows messages for plugin commits, my code should also work against releases of plugins, although it would be easy enough to stop it doing that if there was wide-spread objection to such an action. This does introduce some complexity with version numbers (inconsistent naming conventions, skipped releases, major vs minor increments etc) which I still need to work round, but these could also theoretically impact Jenkins core if we're not consistent about our release naming convention. I'm happy to put my code into GitHub at some point, although the following items currently block that: 1. I'm using a snaphost version of Kohsuke's Java Github API where I've added support for the 'compare' and 'refs' interfaces. I'll create a pull request for these today but I'm relying on Kohsuke accepting them before my code could be used properly. 2. My code currently uses my personal details for connecting to Jira which would cause comments to appear under my ID. I'd like to get a generic user account created (like I assume the SCM Issues bot has) and an OAUTH token provided for the bot to use. Does anyone have any comments on this (especially Kohsuke since you know more about how all the infrastructure interacts just now)? Thanks, Michael -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
