Adding a review comment for a public project shouldn't require membership

Bug #1917331 reported by Tom Haddon
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
jenkins-launchpad-plugin
Fix Released
Medium
Tom Haddon

Bug Description

Currently if you're using launchpadTrigger if you're not a member of the team that owns the code, you get the following error:

INFO: You (prod-jenkaas-is) are not authorized to review this merge proposal. CI process will now be stopped.

Launchpad itself doesn't require these, anyone can comment on Merge Proposals (for public projects), and it would be good to not require more permissions than are needed. Obviously if you want to use autoland you'll need more permissions, but not all projects want this.

It looks like this is due to https://git.launchpad.net/jenkins-launchpad-plugin/tree/jlp/jenkinsutils.py?id=016162f5a2dc89df61eeafa72bd162aea30a3222#n740 and Colin Watson took a quick look at this and suggested this "should simply be removed in favour of simply creating a comment later on in that function and letting that implicitly create a vote".

Related branches

Revision history for this message
Tom Haddon (mthaddon) wrote :

The current workflow is that as soon as the job is started, mp.nominateReviewer runs and it's visible to those looking at the MP that a review is pending from the bot account in question. When the actual CI run that tests the functionality required completes, the bot account then adds an "Approve" comment or a "Needs Fixing" comment. Depending on how long tests take to run this could be a very short or a long interval between nominating the review and adding the follow up comment. If the test run takes a long time, this is a useful indicator to reviewers that it's still in progress.

Removing this (or not failing if it fails) would mean that no longer happening.

Revision history for this message
Paride Legovini (paride) wrote :

Hi Tom, my thoughts:

Turning the mp.nominateReviewer() Unauthorized exception into a non-fatal warning looks sensible to me. J-l-p should still be able to submit a "vote" (review) to the MP, which will then appear as a community review. There will be no indicator that a CI run is in progress in this case, as you noted, but the rest should just work. I can't think of anything else that could go wrong in the jlp CI workflow because of this change, but we should definitely test in on a live MP before merging it.

One concern I have: as you know jlp has two branches at the moment: the legacy py2 branch and master, which uses Python3. Most of the deployments use the py2 branch at the moment, but I thought it as a "frozen" branch with no further development. We can certainly still land changes to it, but in this case we should make the effort of testing and committing them on master too, otherwise we'll have bad surprises in the future.

The package uses the unittest framework. I can run the tests from the master branch with:

  python3 -m unittest

IIRC running the Python 2 tests should be the same, but using the python2 interpreter and the py2 branch.

Tom Haddon (mthaddon)
Changed in jenkins-launchpad-plugin:
status: New → Confirmed
importance: Undecided → Medium
assignee: nobody → Tom Haddon (mthaddon)
Tom Haddon (mthaddon)
Changed in jenkins-launchpad-plugin:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.