fix(termux_pkg_upgrade_version): only commit auto update version bump to repository if the bump successfully built for all enabled architectures #25483
Conversation
9323458 to
0ed047d
Compare
… to repository if the bump successfully built for all enabled architectures - Unless the package is in `big-pkgs.list`, many of which probably would fail to build 2+ times within the 6 hours GitHub Actions time limit. - Fixes termux#25481 - Additional benefit: The `-a all` argument to `build-package.sh` being in at least one CI codepath would **report currently-unreachable-in-CI errors in the edge case that could be described as "cross-target-architecture hostbuild reuse"**, encouraging all contributors to avoid closing auto-update issues without first fixing all errors _including_ errors specific to the `-a all` argument, eventually resulting in a more globally stable `-a all` argument.
0ed047d to
a592381
Compare
Do you know any of these off the top of your head, and are they already in I did think of that, but, at the moment the only check I am doing here is whether the package is in |
Something that ships their own libllvm, for example |
|
I think it is better to let the bot opened a new issue that reports the build failure, and then it is possible for maintainers to fix the build failure. |
Technically, from a certain perspective, that is already done. The issue is here, in there you will find the notification of an error about " Does this mean that the system that created that issue is sufficient to handle this problem, and the kind of change this PR has is not necessary? |
|
I don't think it's necessary to build for all architectures, as this will definitely cause the auto-update bot to often exceed the 6h limit. It is better to wait for comments from other maintainers. |
I can put out a suggestion that maybe, as a compromise, only two architectures could be tested during auto update test builds, 32-bit ARM and 64-bit ARM, and this would take much less time than building all four. That should be able to detect build failures common to both 32-bit architectures, by testing just 32-bit ARM and 64-bit ARM builds. The downside of that is that it would not be able to detect build failures that only happen for 64-bit/32-bit Android-x86. I think that it would be OK not to test x86 during auto update test builds, because I do believe that, speaking generally, x86 still has fewer build errors and is a more heavily tested architecture for CLI and X11 software, which make up the majority of packages in Termux. (and if that idea were implemented, it would be done in such a way that if the package has excluded architectures, the excluded architectures are avoided during building appropriately) |
|
I see no reason to strain the autoupdate CI for testing If you want to do this properly, split the job into 4 CI, not shoehorning 4 arches into 1 CI and pray CI to not timeout. Otherwise I still stick with the current solution of building aarch64 only and fix build issues later. |
I agree that both of those ways are better and I always wished that Termux auto updating did one of those things instead of what it currently does. Now that I know fundamentally changing what the auto updating workflow does like that would be acceptable to you, beyond just a small edit like the way this PR currently is, I will try to make a set of bigger changes that do something like that. |
|
Just as an idea so that I know whether my plan goes in the right direction, if the termux bot could:
then would that be an ideal situation, or is there any big problem with that plan? |
Unless the package is in
big-pkgs.list, many of which probably would fail to build 2+ times within the 6 hours GitHub Actions time limit.Fixes [Bug]: auto update system only tests bumps for one architecture before committing to master branch #25481
Additional benefit: The
-a allargument tobuild-package.shbeing in at least one CI codepath would report currently-unreachable-in-CI errors in the edge case that could be described as "cross-target-architecture hostbuild reuse", encouraging all contributors to avoid closing auto-update issues without first fixing all errors including errors specific to the-a allargument, eventually resulting in a more globally stable-a allargument.