o/ Comments in-line
----- Original Message ----- > From: "Tristan Cacqueray" <[email protected]> > To: [email protected] > Sent: Tuesday, December 6, 2016 8:32:12 AM > Subject: [Softwarefactory-dev] Commit hook trigger and gerrit comment links > > Hello, > > as part of story 3 task 11 I'd like to start the discussion on $topic. > > There are a couple of things to achieve: > > 1/ Link in commit message of gerrit webui needs to point at the correct > issue tracker. > 2/ Commit trigger needs to update issue tracker on patchset-created and > change-merged event. > > Here are my proposals: > > For the webui link, it seems trivial to use simple replacement rules > such as: > (Closes|Related)-(Story|Task): [0-9]+ > => resolves to internal link e.g. /storyboard/$number What about deployments with redmine but without storyboard? Or with both (which makes sense to me; one place for planned stories and one place for bug tracking) > (Closes|Related)-(Issue|Bug): TAG#[0-9]+ -> external > => resolves to external link, e.g. LP: bugs.launchpad.net/$number I'd be in favor of this pattern for the above reasons. SB and RM could be default tags for our deployments. > Then this is all user managed through config/gerrit/commentlinks.yaml > > > Then for the trigger part I recommend we keep it simple and do the > following: > > When there is no TAG, managesf assumes it's pointing at the internal > storyboard and it does the task update automatically. FYI the hooks REST API supports passing the name of the service as an argument, meaning we can trigger specific hooks as we see fit. > For external issue tracker, managesf would look up an issue trackers > configuration per tag such as endpoint address, username and password. > That's assuming a "normal" auth scheme. What if the tracker supports only OAuth or OpenID, like upstream launchpad? Ditto with Kerberos, SAML, API token in a specific header, etc ... I'd suggest doing the sane thing: let's not support anything external. But let's allow power users to define their own hook scripts, in the config repo. These scripts, in hooks.d/<event-name>/ for example, would be copied to the gerrit hooks/ directory at update, and run with each event. But there's an other problem, that we'd have all the time: storing the credentials safely ... Especially if they land in the resources yaml backend. So actually, let's not support anything external - the end. > > Ideally, issue tracker configuration and per project settings would be > defined in the resources yaml description, however I'm afraid gerrit > webui won't be able to easily produce the correct comment links. > Hence the trivial above proposals. > > External issue tracker aren't addressed by this Story 3, and it shall be > implemented in a follow-up story. > > > TL;DR; > Closes-Task: 3 => Put the task in review on patchset-created, > Put the task in merged on patchset-merged > "Closes-" is optional > Related-Task: 3 => Put the task in review on patchset-created, > Doesn't update the task on patchset-merged > > Bug: LP#3 => Web-ui link resolves to launchpad.net > Doesn't update the task (yet) > > > Regards, > -Tristan > > > _______________________________________________ > Softwarefactory-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev > _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
