Thanks Andrea,

I’ve actually realised it’s much easier to solve with GraphQL. In case it helps anyone in future, the following query does the trick:

query($repo\_owner:String!, $repo\_name:String!, $deployment\_env:String!) {  
 repository(owner: $repo\_owner, name: $repo\_name) {  
 deployments(environments: [$deployment\_env], first: 30) {  
 edges {  
 cursor  
 node {  
 state  
 commit {  
 oid  
 }  
 }  
 }  
 }  
 }  
}

And then it’s just a case of finding the first node in the returned result that has state === ‘ACTIVE’.

Obviously this could also be done with a smaller page size and then load the next page in the unlikely event there’s loads of failed / pending / whatever deployments since the last successful one but it was simpler for me to just assume it’s not going to be more than 30 deployments ago and take a bigger page in a single request.

One thing that did trip me up was that at first running the GraphQL query with my app’s installation token was just producing a “Could not resolve to a Repository with the name ‘…’” error.

After a bit of trial and error, I realised that although the app had access to deployments and code, it didn’t have access to repository metadata.

This isn’t an issue with REST - you can call /repos/foo/bar/deployments etc even though the /repos/foo/bar method isn’t accessible.

But it seems with GraphQL it prevents the query finding the repo at all, even if you don’t ask for any metadata and just want to traverse through into the collection of deployments.

Granting read access to repository metadata cleared the error.