+
Skip to content

Conversation

mcoulombe
Copy link
Contributor

Fixes #192

The issue is not affecting all runners. I was only able to reproduce the issue on MacOS runners.

This PR addresses 2 different scenario wrt the hostname the GH workflows use when joining a tailnet:

  • The default hostname generated internally could be - or become due to a GitHub internal update - an invalid DNS label, causing previously valid workflow definitions to fail out of nowhere
  • The hostname provided via the input arguments could be invalid but only cause a failure much later during the workflow, sometimes with non-obvious error messages

To address the 1st point we proactively sanitize internally generated hostnames to make them valid DNS labels. Example of a hostname that was proactively sanitized on a MacOS runner:

Screenshot 2025-09-23 at 3 09 21 PM

To address the 2nd point, we validate the hostname input is a valid DNS label and fail early with a clear error message if not:

Screenshot 2025-09-23 at 3 07 32 PM

@mcoulombe
Copy link
Contributor Author

@oxtoacart could this be the cause of the build failures on #194?

i got a very similar error on the build for #195 and on this PR the TS client is still v1.82.0

@mpminardi
Copy link
Member

@oxtoacart could this be the cause of the build failures on #194?

i got a very similar error on the build for #195 and on this PR the TS client is still v1.82.0

Would be very suspicious that this is indeed what is causing the issues there

@mcoulombe mcoulombe merged commit 0263d9e into main Sep 23, 2025
9 checks passed
@mcoulombe mcoulombe deleted the max/sanitize-hostnames branch September 23, 2025 19:36
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.

Hostname is not a valid DNS label

2 participants

点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载