Automatically track upstream version

[jlaine]

Just a heads up that https://github.com/google/libphonenumber/releases/tag/v8.13.17 is out.

Do you think it would make sense to contribute a PR to automatically make PRs when new upstream releases come out?

Thanks for maintaining the phonenumbers package!

Jeremy

[daviddrysdale]

Hmm, maybe.

I have a small shell script that handles most of the update/release process, but the main problem is getting a reliable trigger to run it. (Releases are also gated on my availability, but in practice I usually get the Python code updated within a day or two of becoming aware of a new upstream release.)

The main trigger is the email to the mailing list, but that's a bit laggy and unreliable (e.g. they forgot to announce v8.13.12). I also used to get notifications of a new Maven release, but the system that generated those notifications got turned down.

So if you can suggest a more reliable trigger, that would be great, thanks.

However, I don't think that it's worth going as far as auto-generating a metadata update PR – I couldn't review such a PR and would always want to recreate the changes myself anyway.

[jlaine]

Concerning the trigger, would polling the github release API help?

https://api.github.com/repos/google/libphonenumber/releases/latest

[daviddrysdale]

The GitHub API seems like a sensible input; any thoughts on the rest of the infrastructure? Are there any easy to set up cron to email services?

[jlaine]

Cron jobs are supported by Github Actions so I suppose a first step would be to run a daily or weekly job which:

• succeeds if the phonenumbers version matches the upstream version
• fails otherwise => this should trigger a notification

We could then look into going a step further and generate a PR for you to review (something like dependabot).

I'm pretty sure I saw a Python project which goes all the way and does automated releases, I'll try to find which one it was.

[daviddrysdale]

That sounds perfect, thanks. I sometimes get emails if I'm more than a day or two behind the upstream release, so maybe set the run interval to every 12 hours?

We could then look into going a step further and generate a PR for you to review (something like dependabot).

Maybe, but I'm not entirely convinced that step is necessary/useful. It wouldn't be possible to manually review a PR with metadata updates, so I'd need a mechanism that I could be 100% convinced is only running the current version of the tools against the right version of the upstream code.

Even if that were the case, the actual update would still be blocked on my availability to press the merge button and then perform the PyPI update. So given that there would still be a couple of manual/human steps, I might as well keep running my small shell script as it doesn't take much more effort.

(I've also raised #274 to think about the more general problem of a bus factor of 1).

[jlaine]

Fixed in PR #275

[daviddrysdale]

Hmm, when the recent v8.13.18 release happened the action failed as expected, but I didn't get a notification on either of the email accounts linked to my GitHub account.

The docs say that "Notifications for scheduled workflows are sent to the user who initially created the workflow." – @jlaine did you get a notification?