How can I query for changes that can be submitted?

[Matthew Webber]

I want to get from Gerrit for a list of changes that are ready to submit, but I could not find any search operator that does this. In other words, I want a list of all changes where a user (with submit privileges) would see the "Submit" button in the UI.

The closest I could come up with is:

is:open label:Code-Review+2 label:Verified+1 NOT label:Code-Review-2 NOT label:Verified-1

However, that query assumes a standard setup with label:Verified and label:Code-Review set up in the normal way.

Any suggestions?

My use case: at our site, the change owner is responsible for submitting his/her changes. I want to have an automated email that reminds developers when they have submittable changes waiting.

Thanks

Matthew

[Khai Do]

I think 'label:Code-Review+2 label:Verified+1' should do it as long as you are using 'Code-Review' and 'Verified' labels.  If you've setup custom labels then you will need to search with 'custom labels+max vote value' because the max vote value is the thing that allows submission[1].  For example if you setup a Foo-Review with range -3..+3 then your query would be 'label:Foo-Review+3 ..'.  

[1] https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_Code-Review

-Khai

ssh -p 29418 localhost gerrit query --submit-records label:Code-Review+2 label:Verified+1

[Matthew Webber]

Hi Khai,

Yes, I understand how to modify my query if I use custom labels.

The problem with that is that the knowledge about the labels needs to be specified in 2 different places: where they are defined, and again in the query.

Since Gerrit knows whether or not a change is ready to be submitted, it would be nice if it would tell me!

Thanks

Matthew

[Khai Do]

Ahh, so what you are looking for is a search predicate, 'is:submittable', where a change is in a state where it can be submitted?  I don't see that in the documentation so i would suggest you enter a feature request to the gerrit issue tracker.    

[Nick Talbot]

I would like to see this too.

We currently merge all submittable reviews in a nightly Jenkins pipeline and autosubmit all reviews if all of our tests pass with all reviews cherry picked onto the master branch. Without the "is:submittable" query we have to replicate the rules/votes (we have quite a few) configured in the project config and possibly also prolog rules. It is error prone as the rules are duplicated.

[Edwin Kempin]

You can use the new "is:submittable" [1] query operator.

[1] https://gerrit-review.googlesource.com/Documentation/user-search.html

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Webber]

>> You can use the new "is:submittable" [1] query operator.

That's certainly better than trying to mimic the prolog rules, but it's fairly limited. From the docs:

This operator only takes into account one change at a time, not any related changes, and does not guarantee that the submit button will appear for matching changes

We often have chains of related changes (i.e. a change has another change as its git parent), and "is:submittable" deosn't handle that (yet!).

[Nick Talbot]

Thanks for the feedback. I realised after I posted that this would also not work well for us. We use the cherry-pick submit strategy so often dependent reviews *are* submittable according to Gerrit if they don't have conflicts. For cases where there are conflicts with parent reviews submittable would be false but we'd like to include these reviews. We currently query for and autosubmit chains of dependent reviews using custom queries. The submittable check wouldn't give the same results. Having said that, earlier reviews in the chain are likely to be ready for submit earlier so it may be uncommon enough not to worry about so not having to maintain rules in two places would probably outweigh the downsides.

[Björn Pedersen]

Hi,

there is a change still pending to improve the checks for submittabiliyt: https://gerrit-review.googlesource.com/#/c/79461/
It probably needs some love to finish for all possible cases...

Björn

[Matthew Webber]

I think I should learn to read. The documentation for the new "is:submittable" [1] query operator says:

To check whether a submit button appears, use the Get Revision Actions API.

Although that's not available as a search query operator, it can be used in scripts, and for me anyhow is exactly what I want.

Thanks to whoever added it!

[Shosh]

Hi Matthew,

Can you explain how you use it in scripts? (because indeed it is not working as a search query)

[Matthew Webber]

On Monday, January 22, 2018 at 8:12:30 AM UTC, Shosh wrote:

Hi Matthew,

Can you explain how you use it in scripts? (because indeed it is not working as a search query)

You need to use the REST API. Documentation is here: https://gerrit-documentation.storage.googleapis.com/Documentation/2.14.5.1/rest-api-changes.html#get-revision-actions

So something like:

# example for a change that CAN be submitted
$ curl -K ~/passwords/http-password_Gerrit_for-curl.txt "https://gerrit.diamond.ac.uk/a/changes/10088/revisions/current/actions"

)]}'
{
  "cherrypick": {
    "method": "POST",
    "label": "Cherry Pick",
    "title": "Cherry pick change to a different branch",
    "enabled": true
  },
  "submit": {
    "method": "POST",
    "label": "Submit",
    "title": "Submit patch set 18 into master",
    "enabled": true
  },
  "description": {
    "method": "PUT",
    "label": "Edit Description",
    "enabled": true
  },
  "rebase": {
    "method": "POST",
    "label": "Rebase",
    "title": "Rebase onto tip of branch or parent change"
  }
}


# example for a change that CANNOT be submitted
$ curl -K ~/passwords/http-password_Gerrit_for-curl.txt "https://gerrit.xxx.com/a/changes/10668/revisions/current/actions"
)]}'
{
  "cherrypick": {
    "method": "POST",
    "label": "Cherry Pick",
    "title": "Cherry pick change to a different branch",
    "enabled": true
  },
  "description": {
    "method": "PUT",
    "label": "Edit Description",
    "enabled": true
  },
  "rebase": {
    "method": "POST",
    "label": "Rebase",
    "title": "Rebase onto tip of branch or parent change"
  }
}

I'm using curl just as a way of driving it from the command line. For a real script, you probably want to use something else from your programming language of choice. 

Note that you can only query for a specific change. So I would do a query to get all the changes numbers of interest (using the examples earlier in this thread), and then loop through those changes.

Hope that helps

Matthew