[JIRA] (JENKINS-55037) Allow configuration/filtering of detected Changes

0 views
Skip to first unread message

peter.vanzetten@gmail.com (JIRA)

unread,
Dec 5, 2018, 11:32:02 AM12/5/18
to jenkinsc...@googlegroups.com
Peter van Zetten created an issue
 
Jenkins / New Feature JENKINS-55037
Allow configuration/filtering of detected Changes
Issue Type: New Feature New Feature
Assignee: lucamilanesio
Components: gerrit-code-review-plugin
Created: 2018-12-05 16:31
Priority: Minor Minor
Reporter: Peter van Zetten

Our developers make heavy use of the WIP and Private flags for their Changes. Currently, the plugin finds and attempts to build these changes a bit too eagerly.

Some configurability in the scanned and filtered changes would be extremely useful. For this use case, a simple control for the search query being used would be sufficient, e.g. we could use status:open -is:wip -is:private.

Controlling the query would also be immediately extensible to more granular workflows, e.g. using a user-set "ready-for-test" review label as a gate on the Jenkins jobs.
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

lucamilanesio@java.net (JIRA)

unread,
Dec 12, 2018, 1:03:02 PM12/12/18
to jenkinsc...@googlegroups.com
lucamilanesio commented on New Feature JENKINS-55037
 
Re: Allow configuration/filtering of detected Changes

Looks like a very good idea. How would you propose to expose the feature? An SCMTrait that says "Filter out WIP and Private" ?

peter.vanzetten@gmail.com (JIRA)

unread,
Dec 13, 2018, 12:26:01 PM12/13/18
to jenkinsc...@googlegroups.com

I think a trait is the right way to handle it. Maybe a single trait with toggles for "Exclude WIP Changes", "Exclude Private Changes" and "Exclude Changes without Jenkins as a Reviewer". From my perspective the latter is just a nice-to-have; some high-traffic projects I've worked on expect the devs to manage their review flow by explicitly adding reviewers for different labels.

I did briefly look at the code to see if I could add this quickly. That fell off my radar, but I remember wondering how much info is available through the branch/git API and how much will require a REST call to filter branches out after the fact.

lucamilanesio@java.net (JIRA)

unread,
Jun 14, 2019, 11:32:02 AM6/14/19
to jenkinsc...@googlegroups.com

Yes, traits would be very easy to add and implement.

One extra thing that could be useful is the propagation of the event JSON into the Pipeline, so that you could take it into account during validations.

Example: a WIP change may need some validation but possibly NOT run the expensive integration tests, because the change it's going to get amended anyway.

WDYT?

peter.vanzetten@gmail.com (JIRA)

unread,
Jun 18, 2019, 7:03:02 AM6/18/19
to jenkinsc...@googlegroups.com

That sounds great! It would be pretty useful if we could access the Gerrit event attributes dynamically in the pipeline code. I don't personally have a need for it right now, but I could certainly incorporate it in the future.

I'm not really knowledgable about Jenkins extensions, so how would it look from the pipeline perspective? A new object/map variable, or a variable whose value is a JSON string which has to be parsed into an object if required?

So I guess there are two independent parts to this feature: a trait on the branch source which can filter changes, then an injection of extra info which can provide more granular stage management or step configuration.

luca.milanesio@gmail.com (JIRA)

unread,
Jan 5, 2020, 2:24:03 PM1/5/20
to jenkinsc...@googlegroups.com

If you look at the latest version (0.4.1) the WIP state is in the list of environment variables available to the job: https://github.com/jenkinsci/gerrit-code-review-plugin/blob/master/BUILD.md

Would that be enough to cover your use-case?

I would also add a trait for skipping WIP changes altogether, WDYT?
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

peter.vanzetten@gmail.com (JIRA)

unread,
Jan 7, 2020, 9:23:01 AM1/7/20
to jenkinsc...@googlegroups.com

The env vars are good enough for now - we can handle the WIP/Private state and omit stages or shortcut the entire build.

A trait to completely prevent the build job creation would be even better!

luca.milanesio@gmail.com (JIRA)

unread,
Jan 7, 2020, 9:25:02 AM1/7/20
to jenkinsc...@googlegroups.com

Looks good, thanks again Peter van Zetten for raising this, I'll work on that for next release, it should be easy enough to do.

johannes.carlsson@acconeer.com (JIRA)

unread,
Jan 31, 2020, 9:42:02 AM1/31/20
to jenkinsc...@googlegroups.com

We already avoid building changes marked as private by making sure that the Jenkins user don't have the "View Private Changes" access right. We also have configured Gerrit so that changes are private and wip when uploading:

[change]
	privateByDefault = true
	workInProgressByDefault = true

 
Reply all
Reply to author
Forward
0 new messages