[tooling] Simplify avalanchego build script

[maru-ava]

Why this should be merged

Previously the scripts/build.sh script delegated responsibility for actually building avalanchego to
scripts/build_avalanche.sh. This change incorporates build_avalanchego.sh into build.sh to simplify maintenance.

How this was tested

CI

Need to be documented in RELEASES.md?

N/A

[maru-ava]

This conditional block was not working as intended - the path could have been populated from a previous invocation, and set -e ensures that an error would result in an exit before this conditional would be evaluated.

[tsachiherman]

Given that it's a no-op change, I shouldn't be critic here, so I'll approve it as is.
However, I'd like to provide few notes I've taken while reviewing this. There notes might be controversial, so please take these as a "open ended remarks":

1. could we add the ability for the script to work from non-avalanche-path ? i.e. change directory to where we want to be, and then pop directory when we're done.
2. When building the “*.go” isn’t needed, since a package is being built anyway.
3. Why does the “go mod download” is even needed ? Wouldn’t the go build automatically do that ?
4. When building, we’re writing out the go version with which we’ve built the binary. That’s perfectly fine. However, if it’s meaningful enough for us to print this out, shouldn’t we also embed that into the binary itself ( same as with the git commit hash ). I also think that we might want to embed the platform and build date & time into the binary ( for telemetry )

[maru-ava]

Given that it's a no-op change, I shouldn't be critic here, so I'll approve it as is. However, I'd like to provide few notes I've taken while reviewing this. There notes might be controversial, so please take these as a "open ended remarks":

1. could we add the ability for the script to work from non-avalanche-path ? i.e. change directory to where we want to be, and then pop directory when we're done.

afaict this script can be invoked from any path. Is there an issue I'm missing with discovering the repo root from the script path?

Note that task will enable building (via scripts/run_task.sh build or task build if task is installed manually or provided via the nix shell) from anywhere in the tree without having to specify the script path (e.g. having to execute with ../../scripts/build.sh if in the tests/fixtures path).

2. When building the “*.go” isn’t needed, since a package is being built anyway.

Fair point, I'll fix.

3. Why does the “go mod download” is even needed ? Wouldn’t the go build automatically do that ?

For sure, go build will download automatically. Maybe someone cared about having a separation between module download and compilation? I'm just maintaining the existing behavior, I don't have a strong opinion either way since there is no functional difference created by this separation.

4. When building, we’re writing out the go version with which we’ve built the binary. That’s perfectly fine. However, if it’s meaningful enough for us to print this out, shouldn’t we also embed that into the binary itself ( same as with the git commit hash ). I also think that we might want to embed the platform and build date & time into the binary ( for telemetry )

My intention in writing out the go version was mainly to give developers an indication of what version they are using since it is common to install different golang versions (i.e. to kick the tires on features of newer versions). It probably does make sense to embed the golang version used to compile for similar reasons.

Edit:

The go version is already included in the version string:

avalanchego/1.13.0 [database=v1.4.5, rpcchainvm=39, go=1.23.6]

For our release binaries and images we can always find out when they were built and with what version since we only build in CI for release with the version in go.mod and CI provides traceability for when a job ran. So while potentially useful, I'm not sure there's a non-devel need for more traceability.

As far as embedding the platform, do you mean the host or target arch/os? I'm not entirely sure of the value of providing the host details, and I'm even less sure of the value of the target given that it wouldn't be possible to run a binary on an os/arch that it wasn't built for.