Skip to content

feat(tool): dotskit init describes a solution made without dotskit, checked by generating it again - #116

Merged
Vovanda merged 1 commit into
devfrom
feat/dotskit-init
Oct 6, 2026
Merged

Vovanda merged 1 commit into
devfrom
feat/dotskit-init

Conversation

@Vovanda

@Vovanda Vovanda commented Oct 6, 2026

Copy link
Copy Markdown
Collaborator

Closes #99.

dotskit init reads a solution made with the template alone, or before 2.8, into .dotskit/manifest.json: the version from Directory.Build.props, the names from All.sln and build-images.sh, the solution's choices and flags from the files only they generate, each service by its appsettings.json sections, the lines a flag writes and its port. Then it generates the solution again by that reading and reports how many of the template's files it reproduces; the manifest is written after a yes, nothing else.

Every row of the issue's table is a unit test (InitCommandTests); the reading has its own (SolutionReaderTests). Four scenarios on the template run in template.yml on three OSes: flags spread over three services, mssql/k8s/xunit/opencode with a gateway, a service the template added to a solution of dotskit, and a solution of 2.7.0 from nuget.org - each reproduced whole, and dotskit new adds to the first.

Found on the way and fixed: a base of a version before 2.8 was generated with --allow-scripts, which such a version refuses (exit 127) - it would have broken init and upgrade on every 2.7 solution.

Where the branch differs from the issue, on purpose:

  • a service of another version than the solution is refused with the way out named (--template-version), not recorded with its own version: the manifest keeps one version;
  • without Common, the manifest is written without the check, and dotskit new does not rebuild Common - the merge takes it for removed by the team.

The DoD line "dotskit new adds a service to a 2.7.0 solution" goes with #100: new on an older manifest names dotskit upgrade, and the upgrade's scenario does 2.7.0 -> init -> upgrade -> new. That PR follows this one; both go into 2.8, which is released only with both.

Reviewed before the PR by an agent without context, two rounds: seven findings, all taken, then closed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Vefp3uznXHA37YYMCkUouw

…hecked by generating it again

- reads the version from Directory.Build.props, the names from All.sln and build-images.sh, the solution's choices and flags from the files only they generate
- reads each service with its own API project: flags by its appsettings.json sections and the lines a flag writes, its port by launchSettings.json
- generates the solution again by the reading and reports how many of the template's files it reproduces, and which differ
- writes .dotskit/manifest.json, nothing else, after a yes; a manifest that lacks a service gets it
- refuses with one line and what to do: no solution, no version, sources, newer than the tool, an earlier major, a service of another version (--template-version describes it)
- takes only -N and -P of the template's parameters; --template-version belongs to init alone
- a version before 2.8 is generated without --allow-scripts, which it refuses, and with the first service its script names
- dotskit new without a manifest names dotskit init, on an older one dotskit upgrade
- tests: the reading and every row of the table as unit tests; four scenarios on the template, 2.7.0 from nuget.org among them
- docs/getting-started/dotskit EN and RU: the reading, the check and the table; the roadmap marks init done
@Vovanda
Vovanda merged commit 7866ba4 into dev Oct 6, 2026
17 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.

dotskit init: describe a solution made without dotskit, and check the description against it

1 participant