Going back to Jesse's original email: I've committed my Issue Update Bot code to Github [1], although am waiting for my pull request on Github-API [2] to be accepted before anyone else could build this (unless they build a snapshot version of my changes [3]).
The jenkins-issues bot is currently listening on* #jenkins-commits* for Github's IRC commit messages, and on *#jenkins* for admin messages. The bot is set in listen only mode for now so will not update Jira. I'll keep an eye on what it does for the next week to see if it's identifying previous release number properly before I then see if we want to put it in update mode. Does anyone have any comments on my suggestion of getting such a system to automatically create release numbers in Jira as releases are made and to then link fixed defect to that release number? I no-one comments here then I'll add it to the next Governance Meeting agenda. The bot is currently running from one of my test servers using my Jira login. If it is to be used long term then I'd recommend hosting it somewhere more permanent (i.e. alongside jenkins-admin or even integrating it into jenkins-admin) and providing it with its own Jira login (or using the SCM/Jira link deamon's account). Could I get any comments or improvements on the code for finding the previous release number: it works for the simple use cases I've tested but is reallytoo accepting of previous version numbers being the one that's wanted. Thanks, Michael [1] https://github.com/mc1arke/JenkinsReleaseIssueBot [2] https://github.com/kohsuke/github-api/pull/30 [3] https://github.com/mc1arke/github-api On 18 February 2013 19:20, Jesse Glick <[email protected]> wrote: > On 02/17/2013 05:23 AM, Christoph Kutzinski wrote: > >> Another nuisance are the frequent merge conflicts on changelog.html >> > > Yes, this complicates pull requests, and makes backporting fixes to the > stable branch painful too. > > > A rough idea would be to create a new single file (XML or so) for each >> changelog entry and let the release process merge this into a single >> changelog.html. >> > > Better to not store changelog.html in Git at all. Just provide a tool to > generate target/changelog.html from the Git changelog leading up to the > revision you have checked out—the only real truth, after all. Commit > messages including keys such as ‘[FIXED JENKINS-12345]’ or ‘[SECURITY-99]’ > or ‘Merged pull request #1001’ would produce sensible hyperlinks. > autochangelog-maven-plugin [1] could probably be adapted to this purpose. > > > [1] > https://github.com/cloudbees/**autochangelog-maven-plugin<https://github.com/cloudbees/autochangelog-maven-plugin> > > > -- > 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+unsubscribe@**googlegroups.com<jenkinsci-dev%[email protected]> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > > > -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
