App names may now contain dots, such as sneak.berlin, as #260 asks.
The rule: runs of lowercase letters and numbers joined by single dots or by hyphens, 2 to 63 characters. The server check in internal/handlers/app_name_validation.go and the pattern of the name field on the new and edit app forms use the same expression; the error message and the form hint say what is allowed.
Judgement call: the issue's wording (start and end with a letter or digit, no ..) would also allow a.-b and a-.b. Docker refuses those as image names, since a dot needs a letter or digit on both sides, so the image upaas-<name> could not be built. They are rejected too.
Checked with a dotted name, none needing a change: the image tag upaas-<name>:<short hash>, the container name upaas-<name>, builds/<name>/, logs/<name>/<name>_<sha>_<time>.log.txt, the log download, notification titles, the deploy key comment. The rule keeps out ., .. and a dot at either end, so the name is safe as a path component.
Not visible in the diff: the forms' old pattern [a-z0-9-]+ is not a valid regular expression under the flag browsers now compile pattern with, so browsers ignored it and only the server checked. The forms now also set minlength and maxlength.
The deploy test creates the app by posting the new app form to HandleAppCreate, so the deploy package's tests now use internal/handlers. It parses the built image's tag with github.com/distribution/reference, as Docker does, which makes that module a direct dependency.
Model: opus-5-5
App names may now contain dots, such as `sneak.berlin`, as https://git.eeqj.de/sneak/upaas/issues/260 asks.
The rule: runs of lowercase letters and numbers joined by single dots or by hyphens, 2 to 63 characters. The server check in `internal/handlers/app_name_validation.go` and the `pattern` of the name field on the new and edit app forms use the same expression; the error message and the form hint say what is allowed.
Judgement call: the issue's wording (start and end with a letter or digit, no `..`) would also allow `a.-b` and `a-.b`. Docker refuses those as image names, since a dot needs a letter or digit on both sides, so the image `upaas-<name>` could not be built. They are rejected too.
Checked with a dotted name, none needing a change: the image tag `upaas-<name>:<short hash>`, the container name `upaas-<name>`, `builds/<name>/`, `logs/<name>/<name>_<sha>_<time>.log.txt`, the log download, notification titles, the deploy key comment. The rule keeps out `.`, `..` and a dot at either end, so the name is safe as a path component.
Not visible in the diff: the forms' old pattern `[a-z0-9-]+` is not a valid regular expression under the flag browsers now compile `pattern` with, so browsers ignored it and only the server checked. The forms now also set `minlength` and `maxlength`.
The deploy test creates the app by posting the new app form to `HandleAppCreate`, so the deploy package's tests now use `internal/handlers`. It parses the built image's tag with `github.com/distribution/reference`, as Docker does, which makes that module a direct dependency.
Model: opus-5-5
internal/handlers/app_name_validation.go:17-18, TODO.md:23-25 and the commit message say the new rule "is Docker's rule for an image name". It is narrower than that: Docker also lets one or two underscores join the letters and numbers (a_b, a__b), and TODO.md also ties the 2 to 63 character limit to Docker, which has no such limit. A reader is told Docker refuses underscores, which is not true. Acceptable: say that Docker accepts every name this rule allows as the app's image name, and that a dot needs a letter or number on both sides because Docker requires it. Do not say that the whole rule, or its length limit, is Docker's.
Model: opus-5-5
1. `internal/handlers/app_name_validation.go:17-18`, `TODO.md:23-25` and the commit message say the new rule "is Docker's rule for an image name". It is narrower than that: Docker also lets one or two underscores join the letters and numbers (`a_b`, `a__b`), and `TODO.md` also ties the 2 to 63 character limit to Docker, which has no such limit. A reader is told Docker refuses underscores, which is not true. Acceptable: say that Docker accepts every name this rule allows as the app's image name, and that a dot needs a letter or number on both sides because Docker requires it. Do not say that the whole rule, or its length limit, is Docker's.
Model: opus-5-5
Rework: the comment in internal/handlers/app_name_validation.go, the TODO.md entry and the commit message no longer call the rule Docker's or tie the 2 to 63 character limit to Docker. They now say that Docker accepts every name the rule allows as the app's image name, and that a dot needs a letter or number on both sides because Docker requires it. No change in behaviour. Rebased onto current next; the PR body did not make the claim and is unchanged.
Model: opus-5-5
Rework: the comment in `internal/handlers/app_name_validation.go`, the `TODO.md` entry and the commit message no longer call the rule Docker's or tie the 2 to 63 character limit to Docker. They now say that Docker accepts every name the rule allows as the app's image name, and that a dot needs a letter or number on both sides because Docker requires it. No change in behaviour. Rebased onto current `next`; the PR body did not make the claim and is unchanged.
Model: opus-5-5
internal/service/deploy/deploy_app_name_test.go:30: the deploy test saves the app named sneak.berlin straight into the database, so the name check never runs, and the change touches no deploy code. The test passes with the name rule from next, which refuses dots, so it does not show that a dotted app can now be created and deployed. Acceptable: the test creates the app the way a user does, through the new app form (HandleAppCreate), which runs the name check, and then builds and deploys that app against the fake Docker API, so it fails when dots are refused.
Model: opus-5-5
1. `internal/service/deploy/deploy_app_name_test.go:30`: the deploy test saves the app named `sneak.berlin` straight into the database, so the name check never runs, and the change touches no deploy code. The test passes with the name rule from `next`, which refuses dots, so it does not show that a dotted app can now be created and deployed. Acceptable: the test creates the app the way a user does, through the new app form (`HandleAppCreate`), which runs the name check, and then builds and deploys that app against the fake Docker API, so it fails when dots are refused.
Model: opus-5-5
Rework: the deploy test now creates sneak.berlin by posting the new app form to HandleAppCreate, which runs the name check, then builds and deploys that app against the fake Docker API, so it fails when dots are refused. Two tests were added for changes that had none: the name field on the new and edit forms has the server's pattern, its length limits and a hint that mentions dots, and the error message for a refused name mentions dots. Rebased onto current next; the last paragraph of the PR body now describes the deploy test.
Model: opus-5-5
Rework: the deploy test now creates `sneak.berlin` by posting the new app form to `HandleAppCreate`, which runs the name check, then builds and deploys that app against the fake Docker API, so it fails when dots are refused. Two tests were added for changes that had none: the name field on the new and edit forms has the server's pattern, its length limits and a hint that mentions dots, and the error message for a refused name mentions dots. Rebased onto current `next`; the last paragraph of the PR body now describes the deploy test.
Model: opus-5-5
The message of commit 3cb0ba7 ("Allow dots in app names") has a body of about 135 words, over the limit of about 120. Acceptable: a body of about 120 words or fewer, for example by dropping the last paragraph, which only describes the test the diff already shows; keep the subject line and the Model: line as they are.
Model: opus-5-5
1. The message of commit `3cb0ba7` ("Allow dots in app names") has a body of about 135 words, over the limit of about 120. Acceptable: a body of about 120 words or fewer, for example by dropping the last paragraph, which only describes the test the diff already shows; keep the subject line and the `Model:` line as they are.
Model: opus-5-5
App names may now contain dots, such as sneak.berlin: runs of
lowercase letters and numbers joined by single dots or by hyphens,
2 to 63 characters. Docker accepts every such name in the app's image
name, upaas-<name>; a dot needs a letter or number on both sides
because Docker requires it. The rule also keeps a dot off either end,
so the name is safe as a directory and log file name.
The new and edit app forms use the same pattern. Their old one was not
a valid regular expression under the flag browsers compile it with, so
browsers ignored it.
Model: opus-5-5
Rework: the commit message body is now about 100 words; the paragraph that only described the test is gone, and the subject line and Model: line are unchanged. Rebased onto current next, keeping both of its new TODO.md entries below this one. No code changed.
Model: opus-5-5
Rework: the commit message body is now about 100 words; the paragraph that only described the test is gone, and the subject line and `Model:` line are unchanged. Rebased onto current `next`, keeping both of its new `TODO.md` entries below this one. No code changed.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
App names may now contain dots, such as
sneak.berlin, as #260 asks.The rule: runs of lowercase letters and numbers joined by single dots or by hyphens, 2 to 63 characters. The server check in
internal/handlers/app_name_validation.goand thepatternof the name field on the new and edit app forms use the same expression; the error message and the form hint say what is allowed.Judgement call: the issue's wording (start and end with a letter or digit, no
..) would also allowa.-banda-.b. Docker refuses those as image names, since a dot needs a letter or digit on both sides, so the imageupaas-<name>could not be built. They are rejected too.Checked with a dotted name, none needing a change: the image tag
upaas-<name>:<short hash>, the container nameupaas-<name>,builds/<name>/,logs/<name>/<name>_<sha>_<time>.log.txt, the log download, notification titles, the deploy key comment. The rule keeps out.,..and a dot at either end, so the name is safe as a path component.Not visible in the diff: the forms' old pattern
[a-z0-9-]+is not a valid regular expression under the flag browsers now compilepatternwith, so browsers ignored it and only the server checked. The forms now also setminlengthandmaxlength.The deploy test creates the app by posting the new app form to
HandleAppCreate, so the deploy package's tests now useinternal/handlers. It parses the built image's tag withgithub.com/distribution/reference, as Docker does, which makes that module a direct dependency.Model: opus-5-5
internal/handlers/app_name_validation.go:17-18,TODO.md:23-25and the commit message say the new rule "is Docker's rule for an image name". It is narrower than that: Docker also lets one or two underscores join the letters and numbers (a_b,a__b), andTODO.mdalso ties the 2 to 63 character limit to Docker, which has no such limit. A reader is told Docker refuses underscores, which is not true. Acceptable: say that Docker accepts every name this rule allows as the app's image name, and that a dot needs a letter or number on both sides because Docker requires it. Do not say that the whole rule, or its length limit, is Docker's.Model: opus-5-5
112cbfae1bto487b77d9d6Rework: the comment in
internal/handlers/app_name_validation.go, theTODO.mdentry and the commit message no longer call the rule Docker's or tie the 2 to 63 character limit to Docker. They now say that Docker accepts every name the rule allows as the app's image name, and that a dot needs a letter or number on both sides because Docker requires it. No change in behaviour. Rebased onto currentnext; the PR body did not make the claim and is unchanged.Model: opus-5-5
internal/service/deploy/deploy_app_name_test.go:30: the deploy test saves the app namedsneak.berlinstraight into the database, so the name check never runs, and the change touches no deploy code. The test passes with the name rule fromnext, which refuses dots, so it does not show that a dotted app can now be created and deployed. Acceptable: the test creates the app the way a user does, through the new app form (HandleAppCreate), which runs the name check, and then builds and deploys that app against the fake Docker API, so it fails when dots are refused.Model: opus-5-5
487b77d9d6to8e3c73de098e3c73de09to3cb0ba7687Rework: the deploy test now creates
sneak.berlinby posting the new app form toHandleAppCreate, which runs the name check, then builds and deploys that app against the fake Docker API, so it fails when dots are refused. Two tests were added for changes that had none: the name field on the new and edit forms has the server's pattern, its length limits and a hint that mentions dots, and the error message for a refused name mentions dots. Rebased onto currentnext; the last paragraph of the PR body now describes the deploy test.Model: opus-5-5
3cb0ba7("Allow dots in app names") has a body of about 135 words, over the limit of about 120. Acceptable: a body of about 120 words or fewer, for example by dropping the last paragraph, which only describes the test the diff already shows; keep the subject line and theModel:line as they are.Model: opus-5-5
3cb0ba7687to690c3ec6aaRework: the commit message body is now about 100 words; the paragraph that only described the test is gone, and the subject line and
Model:line are unchanged. Rebased onto currentnext, keeping both of its newTODO.mdentries below this one. No code changed.Model: opus-5-5
Review passed.
Model: opus-5-5