Update to latest tagged release instead of tracking main

[f-barth]

Summary

• Default updates (ETH_DOCKER_TAG empty or latest) now fetch tags and check out the most recent release instead of git pull origin main
• Pinned updates (ETH_DOCKER_TAG set to a specific version) are unchanged
• Falls back to pulling main if no tags exist

Motivation

Production staking systems benefit from running tested, tagged releases rather than tracking main. Currently, ethd update pulls whatever is on main at the time, which may include untested or in-progress changes. By defaulting to the latest tagged release, operators get stable versions that have been explicitly cut as releases.

The existing ETH_DOCKER_TAG pinning mechanism already uses this exact pattern (fetch tags, checkout on a local tag-* branch) — this change simply applies it to the default path as well, automatically selecting the latest tag via git tag --sort=-v:refname.

Test plan

• ethd update with ETH_DOCKER_TAG= (default): should fetch tags and check out the latest one (currently v26.4.1)
• ethd update with ETH_DOCKER_TAG=v26.3.0: should still pin to that specific tag (unchanged behavior)
• Edge case: repo with no tags falls back to git pull origin main

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR changes ethd update so that when ETH_DOCKER_TAG is unset/empty or latest, it updates to the most recent Git tag (latest release) rather than pulling whatever is currently on main, with a fallback to main if no tags exist.

Changes:

• Default update path now fetches tags and checks out the newest tag by version sort.
• Adds a no-tags fallback message and falls back to pulling main.
• Leaves pinned-tag behavior (ETH_DOCKER_TAG=<version>) as-is.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

__value is computed via git tag ... without ${__as_owner}. When ethd update is run under sudo/root, this can hit Git's “dubious ownership” checks (or a different HOME/config) and result in an empty tag list, incorrectly triggering the “No tags found” fallback. Run the git tag pipeline via ${__as_owner} (and consider redirecting stderr / checking the fetch+tag exit codes) so the tag selection uses the same user context as the other git commands.

Suggested change

	__value=$(git tag --sort=-v:refname | head -1)
	__value=$(${__as_owner} bash -c 'git tag --sort=-v:refname 2>/dev/null | head -1')

[Copilot]

In the no-tags fallback, the code runs git pull origin main without first ensuring the working branch is actually main. If the repo is currently on a different branch (or detached), this will merge origin/main into that branch instead of updating main. Consider checking out main (or resetting to origin/main) before pulling in this fallback path to guarantee the repo ends up on main.

Suggested change

	echo "No tags found, falling back to main branch"
	echo "No tags found, falling back to main branch"
	${__as_owner} git checkout main || ${__as_owner} git checkout -B main origin/main

[yorickdowne]

"Production staking systems benefit from running tested, tagged releases rather than tracking main."

Agreed. That is what ETH_DOCKER_TAG is for. Production staking systems also tag client releases, and blindly pulling an Eth Docker release will break things when Eth Docker relies on the behavior of a new client release.

Either

• Tag all client releases and eth docker itself; read all release notes before deciding to bump tag
  OR
• Don't tag eth docker or client releases (latest, stable), ./ethd update pulls something in that's very likely to work with all-updated releases

This half-way-between idea would, I fear, make things worse

[yorickdowne]

On further thought. Can you change your code so it picks up on ETH_DOCKER_TAG=stable. Grabs the tag that Github thinks is latest with something like latest_tag=$(curl -s https://api.github.com/repos/ethstaker/eth-docker/releases/latest | jq -r .tag_name) - the host might not have curl or jq, check for that and install as needed - then sets the __value to that tag and continues as now from there.

Document the tag in default.env, keep ETH_DOCKER_TAG= as the default and make clear that the default is to update the code to the current development state.

[yorickdowne]

This is a bit of an issue: __value=$(${__as_owner} git tag --sort=-v:refname | head -1) .. this would also pick up on pre-release tags, and that's likely not your intent

That's why the curl idea. There might be a better way tbh - but latest release is not a git feature, it's a github feature