mesonbuild / wrapdb

New wrap requests
https://mesonbuild.com/Adding-new-projects-to-wrapdb.html
MIT License
76 stars 193 forks source link

Add tool to check for new upstream versions and autoupdate if possible #1555

Closed bgilbert closed 2 months ago

bgilbert commented 3 months ago

Use upstream release data from Anitya (release-monitoring.org). Anitya has a database of known software projects, a polling mechanism for identifying new releases, and a mechanism to map downstream package names to Anitya-tracked projects.

I've populated Anitya with WrapDB package names (click the names in the package name column), manually verifying in each case that the Anitya project matches the software actually shipped in WrapDB. In cases where Anitya doesn't know about a project, I have mostly not added a new record, and am not sure whether or not we should add records in all such cases.

With Anitya populated, we can query a single HTTPS endpoint to get the current versions of all our projects it knows about.

Add a tool to use this data. It can:

Add a semiweekly GitHub Actions workflow that submits individual PRs for wraps that can be autoupdated. Sample workflow run. (The wayland failure is fixed by #1554.) Sample PRs.

The update workflow doesn't run sanity checks on the updated wrap; it assumes PR CI will do that. However, that means we can't use GITHUB_TOKEN to push the PR branches, since GitHub doesn't allow actions by the token to invoke other workflows. This PR assumes the following workaround:

  1. Create a wrapdb-bot GitHub account to hold the PR branches. That account should not be given any special privileges on mesonbuild/wrapdb. Fork mesonbuild/wrapdb into the bot account.
  2. Create a Personal Access Token for the bot account and add it to mesonbuild/wrapdb as a GitHub Actions secret named BOT_TOKEN.
  3. The peter-evans/create-pull-request Action will create PRs from the bot's fork, using the bot's access token.
neheb commented 3 months ago

this is...incredible.

I tried this locally. Works great. Although something's wrong with json-glib

./tools/versions.py autoupdate
Traceback (most recent call last):
  File "/home/mangix/devstuff/wrapdb/./tools/versions.py", line 324, in <module>
    main()
  File "/home/mangix/devstuff/wrapdb/./tools/versions.py", line 320, in main
    args.func(args)
  File "/home/mangix/devstuff/wrapdb/./tools/versions.py", line 185, in do_autoupdate
    update_wrap(name, cur_ver, upstream_ver)
  File "/home/mangix/devstuff/wrapdb/./tools/versions.py", line 140, in update_wrap
    resp.raise_for_status()
  File "/usr/lib/python3.12/site-packages/requests/models.py", line 1021, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://download.gnome.org/sources/json-glib/1.8/json-glib-1.8.0-actual.tar.xz
neheb commented 3 months ago

There's also this issue: https://github.com/mesonbuild/wrapdb/issues/158

bgilbert commented 3 months ago

Yeah, there's a data error for json-glib. Upstream tagged 1.8.0 twice, as 1.8.0 and 1.8.0-actual, and there's no 1.8.0-actual tarball. I've flagged the Anitya record for admin review. Meanwhile, I changed the autoupdate subcommand to report errors at the end, rather than failing immediately.

For json (and onqtam-doctest) I've added a hardcoded list of deprecated wraps to ignore. This can be switched to use a releases.json deprecation mechanism if one is eventually added.

I've also made a few other tweaks, including to the list output format, and added the ability to produce Markdown tables (for the Actions workflow).

bgilbert commented 3 months ago

Updated the workflow to automatically delete unneeded branches created by previous runs. This closes the corresponding PR if still open, ensuring we don't leave PRs lying around for wraps that were updated manually.

Also added the infrastructure to push to a bot account's fork, specified by the HEAD_REPO variable in the workflow. Its Personal Access Token is assumed to be stored in the BOT_TOKEN repo secret.

Also added the previous version number to PR titles and commit messages, and made a couple other minor improvements.

bgilbert commented 3 months ago

I think this is in pretty good shape now. Lifting draft.

bgilbert commented 3 months ago

json-glib had a new upstream release, so that data error is no longer an issue.

Rebased.

bgilbert commented 2 months ago

I've seen transient gateway timeouts from Anitya a couple times, so added some retry logic for that case.

bgilbert commented 2 months ago

What's the plan for setting up the bot account as described in https://github.com/mesonbuild/wrapdb/pull/1555#issue-2366099390? This PR assumes the account is named wrapdb-bot, and no such account currently exists on GitHub, so the Actions workflow will fail on every run. I could create the account, but it seems better for the account to be controlled by someone with administrative access to this repo. After the account is created, a repo administrator will need to add its Personal Access Token as a repository secret here.

neheb commented 2 months ago

Probably @jpakkane needs to handle that.

jpakkane commented 2 months ago

I'll look into that once the 1.5 release is out.

bgilbert commented 2 months ago

Cool, thanks! This PR currently assumes the bot account has the email wrapdb@mesonbuild.com, though we can change that if need be. I believe the needed PAT scopes are just public_repo.

jpakkane commented 2 months ago

That can't work. There is no email service at that name. Or even MX records FWICR.

bgilbert commented 2 months ago

The GitHub account will need some email address, and the author/committer of the automated commits should be set to the same email address so GitHub can attribute them properly. The actual address can be anything; we'll just need to update the workflow here.

bgilbert commented 2 months ago

Another option is to use your-personal-email+wrapdb@yourdomain.com as the GitHub account email, if your email provider treats + extensions as still referring to your mailbox. Then the commit author/committer emails could use the email address GitHub autogenerates for its email privacy feature. That's not as pretty visually, but it avoids having to set up a new email address.

bgilbert commented 2 months ago

@jpakkane Do you have some time to look at this? I think it shouldn't take more than 10-15 minutes to set up, and the resulting automation would be very useful in this repo. I can PR the updated email address if you let me know what address to use.

bgilbert commented 1 month ago

Since there doesn't seem to be much interest here, I've posted https://github.com/mesonbuild/wrapdb/pull/1618 to remove the GitHub Actions workflow from this repo.