[MacPorts] #66705: Portfile autoupdate: is it possible to setup GitHub actions to avoid manual updates

[MacPorts]

#66705: Portfile autoupdate: is it possible to setup GitHub actions to avoid manual
updates
----------------------------+---------------------
  Reporter:  esbugz         |      Owner:  admin@…
      Type:  enhancement    |     Status:  closed
  Priority:  Normal         |  Milestone:
 Component:  buildbot/mpbb  |    Version:
Resolution:  wontfix        |   Keywords:
      Port:                 |
----------------------------+---------------------

Comment (by ryandesign):

 Replying to [comment:5 jmroot]:
 > This wouldn't be a base feature. More of a CI/buildbot feature request.

 It could be a base feature. Base already has part of it in the form of
 [https://man.macports.org/port-bump.1.html port bump] to update checksums.
 Currently, a developer manually updates the version before running `port
 bump`. The ability to automatically update the port's version to the one
 livecheck identifies could be added. (A long time ago I wrote and used
 [https://github.com/ryandesign/macports-user-
 ryandesign/blob/master/scripts/portcheckup a script] to automatically do
 this and the equivalent of `port bump`.) So could a feature for creating a
 commit and from that a pull request. And as the reporter said, this
 feature could be useful for ports collections other than ours, so having
 the feature tied to our CI/buildbot infrastructure wouldn't be as useful
 as something in base that anyone could use.


 Replying to [comment:8 esbugz]:
 > The rationale makes little sense - a bot is perfectly capable of
 verifying that a port builds, and nothing in the current process
 guarantees that the human doing the manual version update chore actually
 verifies that it "works", so the potential benefit is purely imaginary

 We can leave the ticket open if you like, and of course even if the ticket
 is closed nothing prevents anyone from implementing it. I'll just leave a
 few more thoughts and examples here that might clarify why I didn't think
 this idea would get implemented. This has gotten long so don't feel
 obligated to respond, but if someone did want to implement something like
 this, I think it would be useful for them to carefully consider these
 issues in their implementation, and starting a discussion about it on the
 mailing list to get more input might be a good idea before spending too
 much time writing code.

 The most minimal steps to update a port would be to update the version,
 reset the revision to 0, and update the checksums. That would work for the
 very simplest ports. But it wouldn't guarantee that the port builds. And
 if the port builds, that doesn't guarantee that it works.

 Having a green check mark on our CI builds is also not a guarantee of a
 correct or functional build. If a port is incompatible with an
 OS/architecture combination, CI will skip it and mark the build
 successful. And I've seen some ports with less-good build systems that
 simply continue on after an error, installing the parts that could be
 built (which is sometimes nothing) and not installing the parts that
 couldn't be built, which may not have been what was intended. One example
 of that is #35528. Of course those build systems should be fixed, and/or
 the port should have code to detect a failed build, but those fixes can
 only happen if the problem is noticed, and if a human is the one doing the
 update, they may notice a missing file or they may read the log and notice
 the errors and investigate and fix the problem before submitting the PR.

 This simplest kind of update isn't hard to do manually or with a local
 script, especially if you're going to test the program locally before
 committing. If a simple update like this were submitted as a PR by an
 automated bot, a human would still (ideally) have to download the diff or
 check out the branch to build it locally and test it before approving the
 PR.

 The notion that we would like a human to sign off on the reasonableness of
 a change is not new. It's a promise to our users that at least someone,
 somewhere, thought this software worked, so it might work for them too.
 It's not just stuff we put out without testing it at all. I'm not sure if
 it's explicitly stated in the Guide. If not, that would be a good
 addition. The Guide could really use an overhaul, but that has been the
 case for a long time.

 For a command line utility, it would be nice for a human to verify that at
 least `foo --version` works. If a program crashes or prints an error
 instead of launching, that would warrant further investigation prior to
 submitting a PR.

 For a GUI, at least check that the app launches and that its about box
 displays. If an app opens but all the icons are missing or the font is
 garbled or windows are totally blank or it displays an error that it can't
 find its data files, that needs attention as well. I'm sure you can think
 of other examples of ways that programs can function incorrectly, despite
 having built without an error message.

 For a library, it would be prudent to check if another port that uses that
 library still works. And Ken already mentioned the library versioning
 issue. An update to a library port might increase its major version. That
 requires all ports using the library to have their revisions increased,
 ideally in the same PR as the one that updates the library, and ideally
 only after it has been verified that all of those dependencies still build
 and work with the new library version. There is currently no tooling that
 automatically detects when this is necessary nor any official script to
 increase the revisions of a bunch of ports, although for the latter many
 scripts have been offered over the years with varying degrees of success
 and correctness.

 Ken also already mentioned that it would be nice for a human to read the
 release notes and see if anything relevant has changed. For example, is
 there a new optional feature that requires a new library dependency that
 should be added? Has the need for some library been removed so that we
 should remove the dependency?

 We often leave comments in Portfiles, telling the next person who updates
 the port to do something. Updating one port might always require the
 revision of some other port to be increased. [source:macports-
 ports/net/curl/Portfile curl] and [source:macports-
 ports/lang/sbcl/Portfile sbcl] are examples of this. Or a patch might no
 longer be necessary in the next version. If the patch failed to apply and
 caused the build to fail, you'd notice that right away, but the patch
 could still apply successfully yet no longer do anything useful (or,
 worse, it could unfix whatever the problem was or cause a new runtime
 problem). A note in the Portfile, left by a human and read and acted upon
 by a human, avoids this problem.

 Many port updates are not this simple. The distfile URL might contain a
 unique asset ID that needs to be updated with each version. The distfile
 naming scheme might have changed. The port might have multiple distfiles,
 not all of which are updated with each version. The web site URL might
 have changed. Patchfiles might need to be updated or removed or added.
 Dependencies might need adjusting. A port might have subports, which
 probably requires a human to decide whether and how those subports get
 updated. The port might contain a workaround for an upstream bug, with a
 comment that includes the bug report URL, which a human should check to
 see if the bug has been fixed yet in this version so that the workaround
 can be removed.

 All of this is to say that there is a lot more to most port updates than
 just the mechanical task of updating the version, revision, and checksums.
 Currently, we hope our pull request queue is full of PRs where the above
 considerations have been taken into account. It takes time to review a PR
 and decide whether it's ready to be merged. It helps to know that the
 submitter has considered the above issues. We even have checkboxes in the
 pull request template for a few of them. The increased use of AI has
 increased the number of PRs we receive that are not ready to merge. If we
 added an automated process to submit port update PRs, many of those would
 not be ready to merge either. This makes the job of our PR reviewers
 harder.

 And I think you're proposing not automated PR submissions, but a complete
 bypassing of the PR system and committing automated changes direct to
 master with no human oversight. I think fewer people review commits than
 PRs, so that means more problems would go unnoticed longer than if they
 had been submitted as PRs. That makes it more likely that a problem is
 encountered by a user, which I'd like to avoid. I'd rather a problem be
 encountered by a developer who can fix it before it's pushed out to users.

-- 
Ticket URL: <https://trac.macports.org/ticket/66705#comment:9>
MacPorts <https://www.macports.org/>
Ports system for macOS