Conversation
martinothamar
left a comment
martinothamar
left a comment
There was a problem hiding this comment.
Nice, this addresses the why but not the how. Is that also the topic for ADRs?
- What should the repo be called
- Migration of issues
- Migration of code (what to do about git history)
- Migration of GitHub Actions workflows
|
martinothamar
added
backport-ignore
📝 WalkthroughWalkthroughAdds new ADR at doc/adr/004-monorepo.md proposing consolidating frontend and backend into a monorepo. Includes status (Proposed), deciders, date, SDLC ADR reference, problem context, decision drivers, alternatives, pros/cons with mitigations, and a conclusion to implement monorepo focus in isolation. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
doc/adr/004-monorepo.md (1)
56-65: Complete sentence fragments and clarify the “single repo issues” mitigation.
- Bullet sub‑items starting with “Can be mitigated …” are fragments—make them sentences.
- Reword the “1 repo with issues …” item and propose concrete labelling.
- Increased complexity in initial project setup and build processes. - - Can be mitigated with good tooling and documentation. + - This can be mitigated with good tooling and documentation. - Risk of larger PRs containing frontend and backend changes, potentially complicating reviews. - - Can be mitigated by having multiple people review if necessary, keep PRs specific. + - This can be mitigated by having multiple people review when necessary; keep PRs specific. -- 1 repo with issues related to both frontend and backend - - Can be mitigated by labelling issues for example +- A single repository will contain issues related to both frontend and backend. + - Mitigate with path/area labels (e.g., area/frontend, area/backend, stack/*) and CODEOWNERS‑based triage.
🧹 Nitpick comments (4)
doc/adr/004-monorepo.md (4)
5-5: Use an unambiguous ISO-8601 date format.Switch to YYYY-MM-DD to avoid ambiguity across locales.
-- Date: 15.11.2024 +- Date: 2024-11-15
17-24: Normalize list indentation and tighten phrasing.
- Current nested bullets are over‑indented (MD007).
- Minor clarity nits.
-- Frontend and backend development work is disjoint - - Leads to less cohesive code, worse APIs - - Slower development time due to handover - - Worse testing (parts of the stack are tested in isolation, as opposed to the whole of a feature/fix) - - Team members have expressed desire to work full-stack - - Repo separation inhibits tooling and automation across the full stack (e.g. integration tests across frontend and backend within a PR/feature branch) - - Apps used for e2e testing should be part of the monorepo to be able to see the full extent of the PR +- Frontend and backend development work is disjoint + - Leads to less cohesive code and worse APIs + - Slower development due to handovers + - Poorer testing (parts of the stack are tested in isolation instead of end‑to‑end per feature/fix) + - Team members have expressed a desire to work full‑stack + - Repo separation inhibits full‑stack tooling/automation (e.g., integration tests across frontend and backend within a PR/feature branch) + - Apps used for E2E testing should be part of the monorepo to validate the full extent of a PR
68-68: Tighten a repetitive conclusion.The paragraph repeats itself; propose a concise, non‑duplicative version.
-Moving to a monorepo directly addresses the inefficiencies and challenges created by the separation of repositories. By unifying the codebase, the team can achieve faster development cycles, improved collaboration, streamlined testing, and a more efficient release process, ultimately leading to a more cohesive and productive workflow. By unifying the frontend and backend into a single repository, the team can improve collaboration, streamline workflows, and achieve a more consistent and efficient development process. While initial setup is more complex, the long-term benefits justify the change. +Moving to a monorepo addresses inefficiencies from separate repositories by enabling faster development, improved collaboration, streamlined testing, and a more efficient release process. While initial setup is more complex, the long‑term benefits justify the change.
36-45: Add concrete operational mitigations to the ADR.Strengthen the decision by listing specific practices that de‑risk the move.
- CI/CD
- Path‑filtered workflows; matrix builds per folder; concurrency groups; required checks per area.
- Cache dotnet restore and npm/yarn/pnpm installs by lockfiles; split build/test jobs to enable partial reruns.
- Repo structure
- .NET solution filters (.slnf); Directory.Packages.props for Central Package Management; shared .editorconfig; global.json.
- CODEOWNERS per folder; GitHub labeler for area/* and stack/*; templates for PRs that require both stacks to sign off.
- Testing
- E2E apps in-repo; ephemeral test environments per PR; contract tests (OpenAPI/typed clients) generated in CI.
- Versioning & releases
- Changesets or conventional commits; release notes per area; artifact version alignment where needed.
- Developer experience
- Sparse checkout/partial clone docs; devcontainer with both SDKs; pre‑commit hooks (format/lint) per stack.
If helpful, I can contribute a short “Operational Mitigations” subsection to this ADR.
Also applies to: 46-55, 56-65
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
doc/adr/004-monorepo.md(1 hunks)
🧰 Additional context used
🪛 LanguageTool
doc/adr/004-monorepo.md
[grammar] ~3-~3: There might be a mistake here.
Context: ...Moving to a Monorepo - Status: Proposed - Deciders: Team - Date: 15.11.2024 ## Re...
(QB_NEW_EN)
[grammar] ~4-~4: There might be a mistake here.
Context: ...epo - Status: Proposed - Deciders: Team - Date: 15.11.2024 ## Result This ADR bu...
(QB_NEW_EN)
[grammar] ~21-~21: There might be a mistake here.
Context: ... feature/fix) - Team members have expressed desire to work full-stack - Repo ...
(QB_NEW_EN)
[grammar] ~29-~29: There might be a mistake here.
Context: ...loyment workflows in a unified pipeline. - M05: Reduce the overhead of managing s...
(QB_NEW_EN)
[grammar] ~41-~41: There might be a mistake here.
Context: ...a single repository. - Align versioning between frontend and backend for consistent rel...
(QB_NEW_EN)
[grammar] ~41-~41: There might be a mistake here.
Context: ...end and backend for consistent releases. - Enable PR-based full-stack testing and d...
(QB_NEW_EN)
[style] ~59-~59: To form a complete sentence, be sure to include a subject.
Context: ... project setup and build processes. - Can be mitigated with good tooling and docu...
(MISSING_IT_THERE)
[style] ~61-~61: To form a complete sentence, be sure to include a subject.
Context: ..., potentially complicating reviews. - Can be mitigated by having multiple people ...
(MISSING_IT_THERE)
[grammar] ~61-~61: There might be a mistake here.
Context: ... review if necessary, keep PRs specific. - Higher potential for repository-wide iss...
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
doc/adr/004-monorepo.md
9-9: Bare URL used
(MD034, no-bare-urls)
18-18: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
19-19: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
20-20: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
21-21: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
22-22: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
23-23: Unordered list indentation
Expected: 2; Actual: 4
(MD007, ul-indent)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: Analyze (csharp)
- GitHub Check: Static code analysis
- GitHub Check: Run dotnet build and test (windows-latest)
- GitHub Check: Run dotnet build and test (ubuntu-latest)
- GitHub Check: Run dotnet build and test (macos-latest)
| This ADR builds on the broader SDLC ADR: https://github.com/Altinn/app-lib-dotnet/pull/860 | ||
|
|
||
| It narrows down to focus on monorepo so that can be improved and implemented in isolation. | ||
|
|
There was a problem hiding this comment.
Fix bare URL and grammar in Result section.
- Avoid bare URLs (markdownlint MD034).
- Minor grammar: add “it” and tighten phrasing.
-This ADR builds on the broader SDLC ADR: https://github.com/Altinn/app-lib-dotnet/pull/860
-
-It narrows down to focus on monorepo so that can be improved and implemented in isolation.
+This ADR builds on the broader [SDLC ADR](https://github.com/Altinn/app-lib-dotnet/pull/860).
+
+It narrows the scope to the monorepo so that it can be improved and implemented in isolation.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| This ADR builds on the broader SDLC ADR: https://github.com/Altinn/app-lib-dotnet/pull/860 | |
| It narrows down to focus on monorepo so that can be improved and implemented in isolation. | |
| This ADR builds on the broader [SDLC ADR](https://github.com/Altinn/app-lib-dotnet/pull/860). | |
| It narrows the scope to the monorepo so that it can be improved and implemented in isolation. |
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
9-9: Bare URL used
(MD034, no-bare-urls)
🤖 Prompt for AI Agents
In doc/adr/004-monorepo.md around lines 9 to 12, the Result section currently
contains a bare URL and a minor grammatical issue; replace the bare URL with a
markdown link (e.g., [SDLC
ADR](https://github.com/Altinn/app-lib-dotnet/pull/860)) to satisfy markdownlint
MD034, and edit the sentence to add the missing "it" and tighten phrasing (for
example: "This ADR builds on the broader SDLC ADR (link) and narrows the focus
to the monorepo so that it can be improved and implemented in isolation.").
|
2 participants
Description
Adds a separate ADR for monorepo that builds on the SDLC ADR.
Summary by CodeRabbit