Replacing omahaproxy.appspot due to deprecation

[PF4Public]

Thanks @rany2.

[Ahrotahn]

This looks good to me.

The only consideration might be how we select the fraction. I don't have a clue how that could change in the future, but it's possible that ratio might vary more significantly. We'll just have to see what happens.

The results can be ordered, so if that ends up being a problem we could maybe add &order_by=fraction%20desc to the URL and select the first entry:
https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions/all/releases?filter=endtime=none&order_by=fraction%20desc

On a side note, is there any reason for having the check run every six hours? Would it cause problems to have it run more frequently?

[PF4Public]

The only consideration might be how we select the fraction. I don't have a clue how that could change in the future, but it's possible that ratio might vary more significantly. We'll just have to see what happens.

The results can be ordered, so if that ends up being a problem we could maybe add &order_by=fraction%20desc to the URL and select the first entry: https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions/all/releases?filter=endtime=none&order_by=fraction%20desc

We all know by now that Google plays on its own rules, so all we can do is just observe and adapt :)

On a side note, is there any reason for having the check run every six hours? Would it cause problems to have it run more frequently?

The value was taken randomly IIRC. I was thinking that if we are to be notified of a new release with the maximum delay of 6 hours, that would be acceptable. Also I had no idea which rate limits are there on omahaproxy, so this value was taken almost randomly. We can try increasing the frequency of the check. Another limiting factor I can think of could be GitHub rate-limiting since there is some logic in issue-creation that pulls GitHub API. Every hour then maybe?

[rany2]

The value was taken randomly IIRC

The value was not taken randomly. According to Google's documentation, fraction is the ratio of users who were pushed the update. So if it's 0.9 then 90% of users on the stable channel were/will be sent the update by Google which I think is a good enough metric for it to be "stable."

Edit: It's a sort of A/B testing by Google.

[PF4Public]

@rany2 The value I was referring to was 6 hours interval for a check, not the fraction.

[rany2]

@PF4Public Ah sorry, I wasn't following very well 😅

[rany2]

Would it cause problems to have it run more frequently?

IMO an interval of one hour isn't too abusive. (Both for Github Actions and Google themselves)

Edit: for example Flathub's GA action runs every 30 minutes, so one hour is OK for sure.

[PF4Public]

I've changed it to be every hour instead of 6.

Sorry, this dismissed all reviews.

[rany2]

P.S. I liked @Ahrotahn's proposal. Not sure if it's too late to switch this to: curl -so- 'https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions/all/releases?filter=endtime=none&order_by=fraction%20desc' | jq -rc '.releases | first | .version'

[PF4Public]

@rany2 Why not :) It does not matter, who is filtering :)

[PF4Public]

I wonder if there is a desire to make all commits signed? @networkException Was last merged commit a hint or just a random trial?

[networkException]

I mainly wanted to see if and how it is possible with our workflow. Improved verifiability is definitely something I'd like to advance in the project though

[rany2]

Something I'm quite a fan of is the new ssh-based commit signing. Previously I wasn't too invested in signing git commits because I hate GPG but having it use ssh keys instead is very convenient!

[Ahrotahn]

If I recall correctly, using the squash and merge option in the github web interface will have the commit signed by github's key. That would be an easy way of having the commit verified when you don't mind having only one commit for the PR.

[PF4Public]

If I recall correctly, using the squash and merge option in the github web interface will have the commit signed by github's key.

… partially signed :)

PS: this also requires several commits to squash. Will it work with a single one?

[Ahrotahn]

I didn't expect the mac releases to be rolled out so slowly. Would it be a good idea to order by the version number instead?

[PF4Public]

order by the version number instead

What do you mean?

[rany2]

He means like this:

curl -s 'https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions/all/releases?filter=endtime=none' | jq -rc '.releases | .[] | .version' | sort -Vr | head -1

[PF4Public]

Will it bring betas in the list?

[rany2]

No

[PF4Public]

I could do it later today.

[rany2]

Just keep in mind -V is a GNU extra, on FreeBSD it behaves differently

[PF4Public]

Could jq do the sorting then? GitHub runners are definitely Linux though.

[Ahrotahn]

Sorry I should have mentioned that the api can do it! All you would have to do is change order_by=fraction%20desc to order_by=version%20desc in the URL.

[rany2]

Sorry I should have mentioned that the api can do it! All you would have to do is change order_by=fraction%20desc to order_by=version%20desc in the URL.

Are you sure it's natural sort?

[rany2]

Answering my own question: yes, it is. @PF4Public Just replace fraction with version and it works just fine!