feat: 4107 onboarding use case selection - #4539
Conversation
|
@BloggerBust is attempting to deploy a commit to the Hatchet Team on Vercel. A member of the Team first needs to authorize it. |
github-actions
Bot
added
engine
mnafees
left a comment
mnafees
left a comment
There was a problem hiding this comment.
since there are changes to the UI here, I'd like to request some screenshots please
There was a problem hiding this comment.
What's the use case of having this test? To me it seems like every time we make changes to the quickstart repo / examples we will need to keep updating this which seems like some wasted work?
There was a problem hiding this comment.
@mnafees thanks for the feedback. I wanted to clarify a few things and suggest a design improvement for a follow-up PR.
If the quickstart repo's implementation changes but the contract does not, the only hatchet repo update is bumping go.mod and go.sum to the new release. Have a look at the recent v0.3.1 bump in this PR (fc3768b) as an example. It changed the scheduled TypeScript template's input handling, and the only edits here in that commit are a test rename and comment cleanup.
The intent of selection_test is to validate what the CLI depends on, which use cases and languages exist and which selections validate. The CLI automatically discovers which use cases the embedded quickstarts includes. In contrast, new languages are not automatically discovered, because the CLI hardcodes the language list and each language's package managers. The assertions only catch removals. Without them if a release dropped a language from a use case, the CLI would silently stop offering it while the dashboard onboarding would continue to print commands for it.
The design should be improved. If hatchet-quickstarts published a manifest of use cases, languages, and package managers alongside the templates, the CLI could derive everything from it and any tests would move to the quickstarts repo where the changes actually happen. Neither adding nor removing a language would require CLI code change. That is a design change though, so I would like to implement it in a follow-up PR.
There was a problem hiding this comment.
same question on this test file as well
There was a problem hiding this comment.
@mnafees Mostly the same answer as above. However, this file belongs in the CLI because it tests that the released CLI generates the project, starts the worker, and completes the trigger. While content edits do not touch this file either, adding or removing a combination currently does require a one-line list update. With my proposed manifest follow-up PR its lists can be derived from the manifest, i.e. that maintenance is removed.
The Overview onboarding now opens with a use-case and language picker, derives the quickstart scaffold and trigger commands from that selection, and completes on a run created after the selection was confirmed. Workers and runs from an earlier selection never satisfy the current one; the confirmation timestamp that scopes both persists for each tenant in localStorage, while completion itself is always re-derived from the runs API. Skip and Finish both hide onboarding behind a confirmation dialog, and the tenant General settings page offers Restart onboarding while it is hidden. useLocalStorageState now reloads when its key changes, so a tenant switch cannot carry another tenant's stored state across. jsdom was added as a dev dependency to test that hook under node:test.
The onboarding picker now lists all three languages for scheduled. The quickstarts dependency is temporarily pinned to the head commit of the hatchet-quickstarts PR that adds these templates. Replace it with the v0.3.0 tag once that PR merges and is tagged, then this PR can be taken out of draft.
The CLI now embeds hatchet-quickstarts v0.3.1, which fixes the scheduled TypeScript template failing on every cron firing. The quickstart e2e matrix is now derived from a language and package-manager list crossed with the use-case triggers, so adding either updates every combination. Also, I fixed a typo in the Overview onboarding heading: "Setup" -> "Set up".
14b0ca3 to
fc3768b
Compare
BloggerBust
added
enhancement
The CLI worker and trigger displayed in onboarding now include the `--profile <tenant name>` to help prevent the person onboarding from running these commands against the wrong tenant.
2 participants
Description
Draft until hatchet-dev/hatchet-quickstarts#16 merges. The quickstarts dependency is temporarily pinned to that PR's head commit and must be replaced with the v0.3.0 tag before this is marked ready.
The Overview onboarding now opens with a use-case and language picker. Workers and runs from an earlier selection never satisfy the current one; the confirmation is scoped for each tenant in localStorage, while completion itself is always re-derived from the runs API. Skip and Finish display a modal that explains how to restart onboarding. The Scheduled use-case offers the same language options as Simple.
Refs #4107. This completes the final Phase 4 task.
Type of change
What's Changed
Checklist
Changes have been:
Testing
Frontend: lint, prettier, typecheck, and unit tests pass under Node 24. Go: templater and CLI unit tests pass and the extended e2e suite compiles. Live validation against a local backend covered scheduled Python, TypeScript, and Go generated by
a CLI. The onboarding itself was manually validated in the browser.
馃 AI Disclosure
I acknowledge that an LLM was used in the creation of this Pull Request, in accordance with Hatchet's AI_POLICY.md.
Details: Claude Code (Opus 4.8) implemented tests, ran validation and fixed issues as they came up.
Screen Shot: Overview - 1. Choose use-case:
Screen Shot: Overview - 2. Install the CLI:
Screen Shot: Overview - 3. Set your profile:
Screen Shot: Overview - 4. Project quickstart:
Screen Shot: Overview - 5. Run a task:
Screen Shot: Overview - 6. Finish:
Screen Shot: Modal - Skip Onboarding:
Screen Shot: Overview - Skipped Onboarding:
Screen Shot: Settings - Restart Onboarding Setting: