Skip to content

fix: resolve hostname/environment from plain Name tag, not just legacy prefix - #50

Merged
ErikMeinders merged 2 commits into
mainfrom
fix/plain-hostname-tag-resolution
Sep 16, 2026
Merged

ErikMeinders merged 2 commits into
mainfrom
fix/plain-hostname-tag-resolution

Conversation

@ErikMeinders

Copy link
Copy Markdown
Member

Summary

  • cloudX-instance.yaml now sets the Name tag to the plain hostname with no cloudX-{env}- prefix (that prefix was dropped at some point). get_instance_tags() only recognized the old prefixed format, so a plain Name (e.g. erix) produced no hostname at all — "does not match format" — even though cloudX:environment on the same instance was perfectly usable.
  • Name is now used as the hostname directly whenever the legacy cloudX-{env}-{hostname} pattern doesn't match. The legacy pattern is still tried first, so older/existing instances keep working exactly as before.
  • Environment resolution now prefers the explicit cloudX:environment/cloudx:environment/Environment tag over {env} parsed out of a legacy Name tag, since the tag is the current, authoritative source. A mismatch between the two (e.g. Name=cloudX-FOO-erik with cloudX:environment=BAR) is flagged as a warning, with the tag winning — this is the only case that gets flagged; the common cases (plain Name, or Name/tag in agreement) are silent.

Test plan

  • New tests/test_instance_tags.py covers: plain Name + env tag (the motivating case), legacy prefixed Name with and without a | {username} suffix, tag-vs-parsed-name conflict (warns, tag wins), agreement (no warning), env tag alone with no Name, and neither present (None, None).
  • Full suite: uv run pytest — 262 passed, no regressions.
  • uv run ruff check cloudx_proxy tests — clean.

🤖 Generated with Claude Code

…y prefix

Current cloudX-instance.yaml sets the Name tag to the plain hostname
with no cloudX-{env}- prefix (that prefix was dropped at some point).
get_instance_tags() only recognized the old prefixed format via regex,
so a plain Name tag (e.g. "erix") fell through to "does not match
format" and yielded no hostname at all, even though the
cloudX:environment tag on the same instance was perfectly usable for
environment resolution.

Now Name is used as the hostname whenever the legacy prefixed pattern
doesn't match, and the environment tag takes precedence over one
parsed out of a legacy Name tag when both are present - only warning
when they actively disagree, never in the routine case.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Copilot AI lite review requested due to automatic review settings September 16, 2026 11:56

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The implementation/tests currently conflict with the PR’s stated “warning” behavior and the test plan omits a described no-Name environment-tag case.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates CloudXSetup.get_instance_tags() to correctly derive hostname/environment from EC2 tags when the Name tag is no longer in the legacy cloudX-{env}-{hostname} format, while preserving backward compatibility for older instances.

Changes:

  • Fall back to using Name as the hostname when the legacy cloudX-{env}-{hostname} pattern doesn’t match.
  • Prefer cloudX:environment / cloudx:environment / Environment tags over {env} parsed from legacy Name, and surface conflicts.
  • Add a dedicated test module covering hostname/environment resolution scenarios.
File summaries
File Description
cloudx_proxy/setup.py Adjusts hostname parsing and environment precedence/conflict reporting in get_instance_tags().
tests/test_instance_tags.py Adds new tests for the updated tag parsing and precedence rules.
Review details

Suppressed comments (1)

tests/test_instance_tags.py:112

  • The test plan mentions covering the case where an environment tag is present but the instance has no Name tag; this file currently doesn’t exercise that scenario. Also, test_environment_tag_alone_is_sufficient isn’t actually "tag alone" because it includes a Name tag. Adding a no-Name case and renaming this test would align coverage and intent.
    def test_environment_tag_alone_is_sufficient(self, setup, monkeypatch):
        environment, hostname = get_tags(
            setup, monkeypatch, {"Name": "erix", "cloudx:environment": "dta"}
        )

        assert (environment, hostname) == ("dta", "erix")
  • Files reviewed: 2/2 changed files
  • Comments generated: 2
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread cloudx_proxy/setup.py
Comment on lines +209 to +214
if env_from_name and env_from_tag and env_from_name != env_from_tag:
self.print_status(
f"Name tag implies environment '{env_from_name}' but the environment tag says "
f"'{env_from_tag}' - using '{env_from_tag}'",
False, 2
)
Comment on lines +95 to +98
out = capsys.readouterr().out
assert "FOO" in out and "BAR" in out
assert "✗" in out

A Name-tag/environment-tag mismatch is resolved deterministically (the
tag always wins) and execution continues normally, so it's not a
failure - print_status(..., False, ...) renders the red ✗ failure
symbol, which this codebase reserves for things that actually broke
(see the "Using vault ... instead of default" warning a few lines
below for the established pattern: warning()-colored text with the
neutral ○ symbol via print_status(..., None, ...)).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@ErikMeinders
ErikMeinders merged commit dbc9105 into main Sep 16, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants