Description
The change in 8bd32c2 introduces a regression where (at least on Gitlab) the right target cannot be find, and the first one that matches OS / ARCH is returned instead.
This introduces an issue when a release contains assets for both x86_64-unknown-linux-musl and x86_64-unknown-linux-gnu. Both contain linux and x86_64, so even though the first part of the if statement does not match, the second one always does.
If we really want a fallback to a less specific asset target when no specific one can be found, we should first check all assets to determine if one can be found. As it stands now, the check is short circuited because .find stops after the first match, which will most likely be the OS / ARCH check.
Personally I don't think the logic introduced in 8bd32c2 is positive in any way, because this also allows accidental upgrades to another target. For instance, if I'm self updating on an OS that only has musl (like Alpine), and the first entry found is x86_64-unknown-linux-gnu, the current logic will happily update to a binary that requires libc that cannot be run. This is bad, because the right target might be later in the list, or might be omitted intentionally for a specific version.