Preserve custom SDK code
1
Edit the generated code
Change generated files or add new ones in the linked SDK repository. Commit to scalar-next, the integration branch. Do not commit to scalar-generated, which holds pristine output.
2
Rebuild the SDK
The next build regenerates from the latest OpenAPI document and merges the new output with the current state of scalar-next.
3
Review and merge
Scalar keeps the release pull request open from scalar-next against the default branch. Most changes merge automatically; only conflicts need attention.
Resolve conflicts#
A conflict occurs when regenerated output changes the same lines you edited. Scalar parks the merge on scalar-merge-conflict.
- Dashboard — Open the target's conflicts view and choose the generated or your version for each file.
- GitHub — Resolve the conflict on the
scalar-merge-conflictpull request like any other merge conflict.
After resolution, the merge lands on scalar-next and the release pull request reflects the result.
Keep custom code maintainable#
- Prefer new files for helpers and extensions. Files in their own paths never conflict.
- Treat CI workflows as custom code. Workflows under
.github/workflows/are carried forward, including workflows for private registries. - Review the release pull request. It is the single place where generated changes and customizations meet.
- Remember the scope. Customizations belong to each target's repository.