search

armbian / build

Armbian Linux build framework generates custom Debian or Ubuntu image for x86, aarch64, riscv64 & armhf
https://www.armbian.com
GNU General Public License v2.0
3.84k stars 2.15k forks source link

[Bug]: bsp-cli package isn't being rebuilt #6817

Closed SteeManMI closed 1 day ago

SteeManMI commented 5 days ago

What happened?

PR #6797 made changes to the bsp-cli for aml-s9xx-box preinst script. However that change isn't being picked up by the build framework and the nightly builds are using a cached older version of that package. The change in the board config file isn't being detected as a change invalidating the cached version of the package. Is there anyway to force a new version of the package to be built so the nightlies pick up this change?

How to reproduce?

Looked at the contents of the latest nightly builds.

Branch

main (main development branch)

On which host OS are you running the build script and observing this problem?

Ubuntu 22.04 Jammy

Are you building on Windows WSL2?

Relevant log URL

No response

Code of Conduct

github-actions[bot] commented 5 days ago

Jira ticket: AR-2389

SteeManMI commented 5 days ago

Actually, I suspect that the change I made in PR #6803 today (since in that PR I changed an actual file in the bsp) that the next nightly will finally pick up my change from PR #6797 finally.

But the underlying issue remains, that the caching logic isn't invalidating the cache when the only change is in the preinst script.

rpardini commented 5 days ago

Hey @SteeManMI you're correct.

There's limits to "how deep" we can inspect the changes to calculate hashes.

In this case, what is hashed is the post_family_tweaks_bsp hook -- especifically post_family_tweaks_bsp__config_aml-s9xx-box_bsp() function. The hashing uses declare -f, which dumps the contents of that function and hashes it.

Since that function refers to aml-s9xx-box-bsp-cli-preinst, and preinst_functions isn't hashed, the system considers nothing has changed.

This can happen with any hook that delegates to another function, and while that function might have changed, the hook didn't. I've still to come up with some general-enough solution for that...

For now, a workaround would be to change something (comments, even) in the hook function; eg

# ...
preinst_functions+=('aml-s9xx-box-bsp-cli-preinst') # change this when function changed! 001
# ...
SteeManMI commented 5 days ago

@rpardini Thanks for the explanation and the workaround. Given as you said you can't make the hashes catch all cases, this can probably be closed. But I leave that for you to decide if this is worth your time to attempt to fix. For me the workaround is good enough now that I know what to do.

SteeManMI commented 4 days ago

@rpardini I have an update. It appears the issue is even deeper than discussed above. So I mentioned that I thought that my changes in the second PR that was committed yesterday would work around the problem, but that change is also not being picked up. The first PR #6797 is the change to the preinst file. The second PR #6803 changes a file in the bsp. The changed file (extlinux/extlinux.conf.template) also is not triggering a new hash and the old cached package is still being used. So if changing the contents of a file in the bsp doesn't trigger a new hash, what does? And is there a workaround for that case as well?

rpardini commented 3 days ago

@SteeManMI let me review. Files that are (unconditionally) included in the bsp-cli should be hashed. Keep in mind the hashing happens before any hooks are actually run, so things that are conditionally included/excluded might be troublesome.