GitLab Account factory docs #2677
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
WalkthroughThis change adds and updates GitLab pipeline docs and sidebars, groups Tabs in several docs, implements persistent task-list checkboxes and anchor-scrolling for closed with supporting CSS and utilities, updates Root to call those utilities on navigation, and removes a minimal Babel config file.
Changes
Sequence Diagram(s)sequenceDiagram
participant Browser as User (Browser)
participant Root as Site Root
participant Checkbox as utils/checkbox
participant Storage as localStorage
participant Anchor as utils/anchor
rect #E8F6FF
Note over Browser,Root: Navigation (pathname or URL hash)
end
Browser->>Root: Navigate (pathname or hash)
alt pathname changed
Root->>Checkbox: interactivePersistentCheckboxes()
Checkbox->>Storage: read states (key: pathname+label)
Browser->>Checkbox: click checkbox
Checkbox->>Storage: update stored state
end
alt URL has hash
Root->>Anchor: scrollToAnchorInClosedSection(location)
Anchor->>Browser: if inside closed <details>, click <summary> to open
Anchor->>Browser: after delay, smooth-scroll target into view
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests
🪧 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
🧹 Nitpick comments (3)
docs/2.0/docs/pipelines/installation/scm-comparison.md (1)
10-10: Table now reflects GitLab beta support – LGTMThe ✅ for “Account Factory Integration” matches the new feature rollout.
Consider adding a brief footnote or “(Beta)” qualifier in the table cell to signal limited support, mirroring the header.sidebars/docs.js (1)
266-270: Minor consistency nitLabel reads “Creating a New GitLab repository with Pipelines” (lower-case r in “repository”). The sister GitHub item uses “Repository”. Recommend capitalising for consistency:
- label: "Creating a New GitLab repository with Pipelines", + label: "Creating a New GitLab Repository with Pipelines",docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (1)
9-9: Bare URL; convert to Markdown linkMarkdownlint flags this. Suggest:
-https://github.com/gruntwork-io/terraform-aws-architecture-catalog/tree/main/templates/devops-foundations-infrastructure-live-root +[Architecture-catalog template](https://github.com/gruntwork-io/terraform-aws-architecture-catalog/tree/main/templates/devops-foundations-infrastructure-live-root)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
babel.config.js(0 hunks)docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md(1 hunks)docs/2.0/docs/pipelines/installation/scm-comparison.md(1 hunks)docs/2.0/docs/pipelines/installation/viamachineusers.md(2 hunks)docs/2.0/docs/pipelines/tutorials/deploying-to-aws-gov-cloud.md(3 hunks)sidebars/docs.js(1 hunks)
💤 Files with no reviewable changes (1)
- babel.config.js
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
PR: gruntwork-io/docs#0
File: .cursor/rules/gitlab-background.mdc:0-0
Timestamp: 2025-07-23T21:18:35.163Z
Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
📚 Learning: applies to docs/**/*.mdx : whenever presenting information that diverges between github and gitlab, ...
Learnt from: CR
PR: gruntwork-io/docs#0
File: .cursor/rules/gitlab-background.mdc:0-0
Timestamp: 2025-07-23T21:18:35.163Z
Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
Applied to files:
docs/2.0/docs/pipelines/installation/viamachineusers.mddocs/2.0/docs/pipelines/tutorials/deploying-to-aws-gov-cloud.mddocs/2.0/docs/pipelines/installation/scm-comparison.mdsidebars/docs.js
📚 Learning: in the gruntwork-io/docs repository, document ids should match the filename (without extension) rath...
Learnt from: ZachGoldberg
PR: gruntwork-io/docs#2663
File: docs/2.0/docs/pipelines/architecture/change-types.md:1-6
Timestamp: 2025-07-17T18:43:27.029Z
Learning: In the gruntwork-io/docs repository, document IDs should match the filename (without extension) rather than being namespaced. For example, a file named "change-types.md" should have `id: change-types` in the front matter.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
🪛 markdownlint-cli2 (0.17.2)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
9-9: Bare URL used
(MD034, no-bare-urls)
⏰ 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). (2)
- GitHub Check: Validate generated content
- GitHub Check: validate_build
🔇 Additional comments (5)
docs/2.0/docs/pipelines/tutorials/deploying-to-aws-gov-cloud.md (3)
58-83: Tabs now grouped – 👍Adding
groupId="platform"is correct and aligns with the new docs convention for GitHub/GitLab switching. No further action required.
87-98: Consistent value casingDouble-check that the
value="GitHub"/value="GitLab"strings are capitalised identically in allTabs groupId="platform"blocks across the page (they appear to be, but worth one last grep before merge). Inconsistent casing silently breaks tab sync in Docusaurus.
133-146: Group-ID addition looks goodSame comment as above: the grouping attribute is correct and should improve UX.
docs/2.0/docs/pipelines/installation/viamachineusers.md (1)
39-40: Nice: platform tab grouping addedNo issues spotted. Tabs on this page will now sync with the other platform tabs.
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (1)
125-128: TODO must be resolved before mergeThe template ref currently points at a feature branch. Either pin to a released tag or update the comment to track a future tag before dropping the
[WIP]prefix on this PR.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (1)
1-1: Missing Docusaurus front-matterThe missing front-matter issue was already identified in previous review comments. This needs to be addressed to ensure proper document routing and sidebar integration.
🧹 Nitpick comments (3)
utils/anchor.ts (1)
15-17: Consider making the delay configurable.While 500ms is generally sufficient for browser rendering, different content complexities might benefit from adjustable timing.
Consider making the delay configurable:
-export const scrollToAnchorInClosedSection = (location: Location) => { +export const scrollToAnchorInClosedSection = (location: Location, delay: number = 500) => { const hash = location.hash if (hash) { const id = hash.substring(1) const element = document.getElementById(id) if (element) { const details = element.closest("details") if (details && !details.open) { const summary = details.querySelector("summary") if (summary) { summary.click() - const timeoutId = setTimeout(() => { + const timeoutId = setTimeout(() => { element.scrollIntoView({ behavior: "smooth", block: "start" }) - }, 500) // 500ms to allow for browser to render the element + }, delay) // Allow configurable delay for browser renderingutils/checkbox.ts (1)
30-33: Consider improving key uniqueness.The current key generation using only the first 10 characters of text content might not be unique enough for complex documents with similar checkbox labels.
Consider using more content or a hash for better uniqueness:
checkboxes.forEach((checkbox, index) => { const label = - `${index}:${checkbox?.closest("li")?.textContent?.substring(0, 10)}` || + `${index}:${checkbox?.closest("li")?.textContent?.substring(0, 20)}` || `checkbox-${index}`Or consider using a hash of the full text content for even better uniqueness while keeping keys short.
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (1)
258-258: Fix markdown heading alignment.The static analysis correctly identifies that this heading should start at the beginning of the line.
- ### **Steps to grant access** +### **Steps to grant access**
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
docs/2.0/docs/overview/getting-started/index.md(1 hunks)docs/2.0/docs/pipelines/installation/addinggitlabrepo.md(1 hunks)docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md(1 hunks)sidebars/docs.js(1 hunks)src/css/custom.css(3 hunks)src/theme/Root.js(2 hunks)utils/anchor.ts(1 hunks)utils/checkbox.ts(1 hunks)
✅ Files skipped from review due to trivial changes (3)
- docs/2.0/docs/overview/getting-started/index.md
- docs/2.0/docs/pipelines/installation/addinggitlabrepo.md
- src/theme/Root.js
🚧 Files skipped from review as they are similar to previous changes (1)
- sidebars/docs.js
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
PR: gruntwork-io/docs#0
File: .cursor/rules/gitlab-background.mdc:0-0
Timestamp: 2025-07-23T21:18:35.163Z
Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
📚 Learning: in the gruntwork-io/docs repository, document ids should match the filename (without extension) rath...
Learnt from: ZachGoldberg
PR: gruntwork-io/docs#2663
File: docs/2.0/docs/pipelines/architecture/change-types.md:1-6
Timestamp: 2025-07-17T18:43:27.029Z
Learning: In the gruntwork-io/docs repository, document IDs should match the filename (without extension) rather than being namespaced. For example, a file named "change-types.md" should have `id: change-types` in the front matter.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
📚 Learning: applies to docs/**/*.mdx : whenever presenting information that diverges between github and gitlab, ...
Learnt from: CR
PR: gruntwork-io/docs#0
File: .cursor/rules/gitlab-background.mdc:0-0
Timestamp: 2025-07-23T21:18:35.163Z
Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
🪛 LanguageTool
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
[style] ~33-~33: Consider using “inaccessible” to avoid wordiness.
Context: ...g a self-hosted GitLab instance that is not accessible from the public internet. If you are us...
(NOT_ABLE_PREMIUM)
🪛 markdownlint-cli2 (0.17.2)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
24-24: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
50-50: Bare URL used
(MD034, no-bare-urls)
75-75: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
88-88: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
102-102: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
193-193: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
201-201: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
230-230: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
236-236: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
242-242: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
248-248: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
258-258: Headings must start at the beginning of the line
(MD023, heading-start-left)
287-287: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
293-293: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
299-299: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
305-305: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
314-314: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
320-320: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
326-326: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
332-332: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
341-341: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
347-347: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
353-353: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
359-359: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
365-365: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
371-371: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
⏰ 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). (3)
- GitHub Check: Validate generated content
- GitHub Check: Pull Request has non-contributor approval
- GitHub Check: validate_build
🔇 Additional comments (8)
utils/anchor.ts (1)
1-24: Well-structured utility function with good error handling.This function elegantly handles the common UX issue of linking to content inside collapsed details sections. The implementation includes proper null checks and early returns, making it robust against various edge cases.
The 500ms timeout is reasonable for most browser rendering scenarios, and the cleanup function is a nice touch for preventing memory leaks.
src/css/custom.css (2)
170-170: Good addition of theme-aware checkbox border variables.The CSS variables for checkbox border colors properly support both light and dark themes, maintaining consistency with the existing theming approach.
Also applies to: 183-183
703-742: Excellent custom checkbox implementation.This is a well-crafted custom checkbox design that:
- Removes native styling for consistent cross-browser appearance
- Uses proper sizing (1.15em) that scales with font size
- Implements smooth transitions for the checkmark
- Uses an embedded SVG for the checkmark (scalable and crisp)
- Integrates seamlessly with the theme's color system
The implementation follows modern CSS best practices and provides a polished user experience.
utils/checkbox.ts (2)
1-52: Well-structured persistent checkbox implementation.This function provides a clean solution for maintaining checkbox states across page loads. The implementation includes proper error handling, unique key generation, and cleanup mechanisms.
4-10: Robust error handling for localStorage.The try-catch block properly handles potential JSON parsing errors and localStorage access issues, providing a sensible fallback to an empty object.
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (3)
3-43: Excellent comprehensive setup guide.This documentation provides a thorough, step-by-step approach to GitLab project creation with clear prerequisites and proper handling of both standard GitLab.com and custom instance scenarios. The use of collapsible sections for custom instance instructions keeps the main flow clean while providing necessary details when needed.
224-378: Well-structured manual deployment checklist.The checklist format with nested checkboxes provides an excellent user experience for tracking progress through the multi-account deployment process. The inclusion of specific commands, AWS console instructions, and important notes about Service Catalog permissions shows attention to common user pain points.
192-195: Update template reference to a stable release before mergingThe boilerplate command is still pointing at the
ore/dev-1024-extend-account-factory-templates-for-gitlabbranch. Please replace that with a stable release tag once it’s available.Files to update:
- docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (lines 192–195)
Suggested change:
- boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-root/?ref=ore/dev-1024-extend-account-factory-templates-for-gitlab" --output-folder . --var-file vars.yaml --non-interactive + boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-root/?ref=<STABLE_TAG>" --output-folder . --var-file vars.yaml --non-interactivePlease confirm which stable tag (e.g.,
vX.Y.Z) should be used here.
oredavids
changed the title
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (1)
1-2: Front-matter still missing &importstatement is in the wrong place
The document is still missing the mandatory Docusaurus front-matter (id,title). In MDX theimportline must come after that front-matter; otherwise the build will fail.+--- +id: addingnewgitlabrepo +title: Creating a New GitLab Project with Pipelines +--- + import CustomizableValue from '/src/components/CustomizableValue';This is the same issue flagged in the previous review—please address before continuing.
🧹 Nitpick comments (1)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (1)
234-377: Mixed ordered lists and task-list syntax
Lines like1. [ ] Apply infrastructure changes…are neither valid ordered-list items nor GitHub-style task list items (the numeral cancels task-list detection). Use either:- [ ] Apply infrastructure changes in the **management** accountor a plain ordered list without the checkbox.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md(1 hunks)docs/2.0/docs/pipelines/installation/scm-comparison.md(1 hunks)utils/anchor.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- docs/2.0/docs/pipelines/installation/scm-comparison.md
- utils/anchor.ts
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: CR
PR: gruntwork-io/docs#0
File: .cursor/rules/gitlab-background.mdc:0-0
Timestamp: 2025-07-23T21:18:35.163Z
Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
📚 Learning: 2025-07-17T18:43:27.029Z
Learnt from: ZachGoldberg
PR: gruntwork-io/docs#2663
File: docs/2.0/docs/pipelines/architecture/change-types.md:1-6
Timestamp: 2025-07-17T18:43:27.029Z
Learning: In the gruntwork-io/docs repository, document IDs should match the filename (without extension) rather than being namespaced. For example, a file named "change-types.md" should have `id: change-types` in the front matter.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
📚 Learning: 2025-07-23T21:18:35.163Z
Learnt from: CR
PR: gruntwork-io/docs#0
File: .cursor/rules/gitlab-background.mdc:0-0
Timestamp: 2025-07-23T21:18:35.163Z
Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
🪛 LanguageTool
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
[style] ~33-~33: Consider using “inaccessible” to avoid wordiness.
Context: ...g a self-hosted GitLab instance that is not accessible from the public internet. If you are us...
(NOT_ABLE_PREMIUM)
🪛 markdownlint-cli2 (0.17.2)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
24-24: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
50-50: Bare URL used
(MD034, no-bare-urls)
75-75: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
88-88: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
107-107: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
197-197: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
206-206: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
240-240: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
246-246: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
252-252: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
258-258: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
268-268: Headings must start at the beginning of the line
(MD023, heading-start-left)
297-297: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
303-303: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
309-309: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
315-315: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
324-324: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
330-330: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
336-336: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
342-342: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
351-351: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
357-357: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
363-363: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
369-369: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
375-375: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
381-381: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
413-413: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
448-448: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
461-461: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
496-496: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
529-529: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
537-537: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
⏰ 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). (4)
- GitHub Check: Pull Request has non-contributor approval
- GitHub Check: validate_build
- GitHub Check: Validate generated content
- GitHub Check: Pull Request has non-contributor approval
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (2)
docs/2.0/docs/pipelines/installation/addinggitlabrepo.md (2)
115-116: Pin the sample vars.yaml link to the same released tag (avoid “main”).This keeps the example reproducible and consistent with the pinned template version in Step 3.
-4. Download the sample [vars.yaml file](https://github.com/gruntwork-io/terraform-aws-architecture-catalog/blob/main/examples/gitlab-pipelines/vars.yaml) to the root of <CustomizableValue id="REPOSITORY_NAME" /> +4. Download the sample [vars.yaml file](https://github.com/gruntwork-io/terraform-aws-architecture-catalog/blob/v3.1.0/examples/gitlab-pipelines/vars.yaml) to the root of <CustomizableValue id="REPOSITORY_NAME" />
160-166: Correct path order for importing an existing OIDC provider.The example flips account/_global. The earlier commands use “$$ACCOUNT_NAME$$/_global/…”, so keep it consistent.
- cd _global/$$ACCOUNT_NAME$$/gitlab-pipelines-openid-connect-provider/ + cd $$ACCOUNT_NAME$$/_global/gitlab-pipelines-openid-connect-provider/
🧹 Nitpick comments (4)
docs/2.0/docs/pipelines/installation/addinggitlabrepo.md (4)
43-44: Grammar: use “JWTs” (plural) instead of “JWT's” (possessive).Minor correction for professionalism.
-This is necessary for both Gruntwork and the AWS OIDC provider to access the GitLab OIDC configuration and JWKS when authenticating JWT's generated by your custom instance. +This is necessary for both Gruntwork and the AWS OIDC provider to access the GitLab OIDC configuration and JWKS when authenticating JWTs generated by your custom instance.
81-88: Persist the boilerplate tool with mise for better UX.Use the global flag so the version persists across sessions without relying on the current shell only.
- mise use boilerplate@0.6.0 + # Make the tool version persistent for all shells: + mise use -g boilerplate@0.6.0
149-150: Fix typo: remove extra word in IAM roles bullet.Small wording polish.
- - IAM roles for your the account (`root-pipelines-plan` and `root-pipelines-apply`) + - IAM roles for your account (`root-pipelines-plan` and `root-pipelines-apply`)
173-174: Grammar: remove the article before “CI/CD variables.”Minor correction for clarity.
-2. Ensure that `PIPELINES_GITLAB_TOKEN` and `PIPELINES_GITLAB_READ_TOKEN` are set as a CI/CD variables in your group or project if you haven't already (see the [Machine Users setup guide](/2.0/docs/pipelines/installation/viamachineusers#gitlab) for details). +2. Ensure that `PIPELINES_GITLAB_TOKEN` and `PIPELINES_GITLAB_READ_TOKEN` are set as CI/CD variables in your group or project if you haven't already (see the [Machine Users setup guide](/2.0/docs/pipelines/installation/viamachineusers#gitlab) for details).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
docs/2.0/docs/pipelines/installation/addinggitlabrepo.md(2 hunks)sidebars/docs.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- sidebars/docs.js
⏰ 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). (3)
- GitHub Check: Pull Request has non-contributor approval
- GitHub Check: validate_build
- GitHub Check: Validate generated content
🔇 Additional comments (3)
docs/2.0/docs/pipelines/installation/addinggitlabrepo.md (3)
3-3: Title refinement improves clarity (LGTM).Clearer differentiation between “new” vs “existing” project flows. Nice.
14-14: Prerequisite simplification (LGTM).Limiting required access to the architecture catalog reduces friction while staying accurate.
121-122: Pinned template version (v3.1.0) — good step towards reproducibilityThis aligns with the PR objective to use a released version instead of main. Thanks for pinning.
I attempted to verify that the tag v3.1.0 exists in gruntwork-io/terraform-aws-architecture-catalog and that examples/gitlab-pipelines/vars.yaml is present at that tag, but received an unexpected API response. Please manually confirm:
- The repository has a tag named v3.1.0
- The file examples/gitlab-pipelines/vars.yaml is accessible at that tag
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (5)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (5)
271-286: Keep nested heading, but silence markdownlint MD023 at this spot.You intentionally nested this heading under a list item; add a one-line suppression to keep linters happy.
- #### **Steps to grant access** + <!-- markdownlint-disable-next-line MD023 --> + #### **Steps to grant access**
1-3: MDX components in a .md file will not render; rename to .mdx and add front matter at top.This file imports a React component and uses JSX tags, but the extension is .md. Docusaurus requires .mdx for MDX features. Also add front matter so the doc id matches the filename per repo guideline. Remove the duplicate H1 since the title comes from front matter.
Apply this diff after renaming the file to addingnewgitlabrepo.mdx:
+--- +id: addingnewgitlabrepo +title: Creating a New GitLab Project with Pipelines +--- import CustomizableValue from '/src/components/CustomizableValue'; -# Creating a New GitLab Project with PipelinesThen run a quick link check in the sidebar/build locally to confirm the new id is picked up. I used the repo learning that doc ids should match filenames. Would you like me to open a follow-up PR to update any inbound links?
343-347: Repeat the pass-through fix here as well.- terragrunt run --all providers lock -platform=darwin_amd64 -platform=linux_amd64 + terragrunt run --all providers -- lock -platform=darwin_amd64 -platform=linux_amd64
376-380: Ensure the--flag separator is included in allterragrunt runcommandsThe
terragrunt run --all providers lock ...invocation is missing the required--beforelockin several spots. Please update each instance as follows:• File:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
– Line 319
– Line 346
– Line 379Replace this:
terragrunt run --all providers lock -platform=darwin_amd64 -platform=linux_amd64With this:
terragrunt run --all providers -- lock -platform=darwin_amd64 -platform=linux_amd64
316-321: Pass-through separator missing for providers lock command.Without
--the-platformflags may be consumed by Terragrunt instead of the underlying (Open)Tofu/Terraform subcommand.- terragrunt run --all providers lock -platform=darwin_amd64 -platform=linux_amd64 + terragrunt run --all providers -- lock -platform=darwin_amd64 -platform=linux_amd64
🧹 Nitpick comments (4)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (4)
31-37: Tiny grammar cleanups: “inaccessible” and “JWTs”.Polish for readability and correctness.
Apply this diff:
-This step only applies if you are using a self-hosted GitLab instance that is not accessible from the public internet. If you are using GitLab.com or a self-hosted instance that is publicly accessible, you can skip this step. +This step only applies if you are using a self-hosted GitLab instance that is inaccessible from the public internet. If you are using GitLab.com or a self-hosted instance that is publicly accessible, you can skip this step. @@ -1. [Follow GitLab's instructions](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance) for hosting your OIDC configuration and JWKS in a public location (e.g. S3 Bucket). This is necessary for both Gruntwork and the AWS OIDC provider to access the GitLab OIDC configuration and JWKS when authenticating JWT's generated by your custom instance. +1. [Follow GitLab's instructions](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance) for hosting your OIDC configuration and JWKS in a public location (e.g., an S3 bucket). This is necessary for both Gruntwork and the AWS OIDC provider to access the GitLab OIDC configuration and JWKS when authenticating JWTs generated by your custom instance.
50-58: Avoid bare email; use a mailto link.Minor formatting improvement and avoids MD034.
-To use Gruntwork Pipelines with GitLab, your group needs authorization from Gruntwork. Email your Gruntwork account manager or support@gruntwork.io with: +To use Gruntwork Pipelines with GitLab, your group needs authorization from Gruntwork. Email your Gruntwork account manager or [support@gruntwork.io](mailto:support@gruntwork.io) with:
86-95: Pin awscli instead of “latest” for reproducible installs.“latest” can break setups unexpectedly. Pin a known-good version and bump intentionally.
- awscli = "latest" + awscli = "2.17.0" # Pin for reproducible builds; update intentionally as neededIf you prefer, we can add a short admonition explaining how to update and why it’s pinned.
228-234: Use current AWS naming: IAM Identity Center (formerly AWS SSO).Small clarity upgrade; avoids confusion with older naming.
-You can utilize the AWS SSO Portal to obtain temporary AWS credentials necessary for subsequent steps: +You can use the AWS IAM Identity Center (formerly AWS SSO) portal to obtain temporary AWS credentials for the subsequent steps: @@ -1. Sign in to the Portal page and select your preferred account to unveil the roles accessible to your SSO user. +1. Sign in to the IAM Identity Center user portal and select your account to view the roles available to your user. @@ -1. Navigate to the "Access keys" tab adjacent to the "AWSAdministratorAccess" role. +1. Navigate to the "Access keys" tab next to the "AWSAdministratorAccess" role.
📜 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)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md(1 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-07-17T18:43:27.029Z
Learnt from: ZachGoldberg
PR: gruntwork-io/docs#2663
File: docs/2.0/docs/pipelines/architecture/change-types.md:1-6
Timestamp: 2025-07-17T18:43:27.029Z
Learning: In the gruntwork-io/docs repository, document IDs should match the filename (without extension) rather than being namespaced. For example, a file named "change-types.md" should have `id: change-types` in the front matter.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
📚 Learning: 2025-07-23T21:18:35.163Z
Learnt from: CR
PR: gruntwork-io/docs#0
File: .cursor/rules/gitlab-background.mdc:0-0
Timestamp: 2025-07-23T21:18:35.163Z
Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
📚 Learning: 2025-07-17T18:44:16.153Z
Learnt from: ZachGoldberg
PR: gruntwork-io/docs#2663
File: docs/2.0/docs/pipelines/architecture/change-types.md:59-61
Timestamp: 2025-07-17T18:44:16.153Z
Learning: In current Terragrunt versions (2024-2025), the preferred command syntax is `terragrunt run --all` rather than the deprecated `terragrunt run-all` subcommand. The `run-all` command is still functional for backwards compatibility but is being phased out in favor of the `run --all` syntax.
Applied to files:
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
🪛 LanguageTool
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
[grammar] ~15-~15: There might be a mistake here.
Context: ...Lab, and infrastructure as code concepts - Completed the [AWS Landing Zone setup](/...
(QB_NEW_EN)
[grammar] ~18-~18: There might be a mistake here.
Context: ...machine user with appropriate PAT tokens - Local access to Gruntwork's GitHub repos...
(QB_NEW_EN)
[style] ~33-~33: Consider using “inaccessible” to avoid wordiness.
Context: ...g a self-hosted GitLab instance that is not accessible from the public internet. If you are us...
(NOT_ABLE_PREMIUM)
[grammar] ~35-~35: There might be a mistake here.
Context: ...JWT's generated by your custom instance. 2. Note the <CustomizableValue id="ISSUER_U...
(QB_NEW_EN)
[grammar] ~64-~64: There might be a mistake here.
Context: ...e project. e.g. infrastructure-live-root 1. Click Create Project. 1. Clone the p...
(QB_NEW_EN)
[grammar] ~65-~65: There might be a mistake here.
Context: ...e-live-root 1. Click Create Project. 1. Clone the project to your local machine....
(QB_NEW_EN)
[grammar] ~228-~228: There might be a mistake here.
Context: ...s content into your main branch. :::tip You can utilize the AWS SSO Portal to ob...
(QB_NEW_EN)
[grammar] ~231-~231: There might be a mistake here.
Context: ...l the roles accessible to your SSO user. 1. Navigate to the "Access keys" tab adjace...
(QB_NEW_EN)
[grammar] ~457-~457: There might be a mistake here.
Context: ...s: - GitLab Pipelines workflow file - Gruntwork Pipelines configuration files ...
(QB_NEW_EN)
[grammar] ~458-~458: There might be a mistake here.
Context: ... Gruntwork Pipelines configuration files - Module defaults files for GitLab OIDC ro...
(QB_NEW_EN)
[grammar] ~470-~470: There might be a mistake here.
Context: ...w because there is no infrastructure to apply; repository simply contains the GitLab O...
(QB_NEW_EN)
[grammar] ~546-~546: There might be a mistake here.
Context: ...and the example Service Catalog modules. 1. Merge the open merge request.
(QB_NEW_EN)
🪛 markdownlint-cli2 (0.17.2)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
50-50: Bare URL used
(MD034, no-bare-urls)
75-75: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
88-88: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
107-107: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
200-200: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
209-209: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
243-243: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
249-249: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
255-255: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
261-261: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
271-271: Headings must start at the beginning of the line
(MD023, heading-start-left)
300-300: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
306-306: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
312-312: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
318-318: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
327-327: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
333-333: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
339-339: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
345-345: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
354-354: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
360-360: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
366-366: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
372-372: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
378-378: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
384-384: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
416-416: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
451-451: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
464-464: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
499-499: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
532-532: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
540-540: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
⏰ 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). (3)
- GitHub Check: validate_build
- GitHub Check: Pull Request has non-contributor approval
- GitHub Check: Validate generated content
🔇 Additional comments (2)
docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (2)
394-548: Overall: Strong, step-by-step guide—clear structure and consistent use of Terragrunt’s modernrun --all.The flow is coherent, prerequisites are actionable, and the checklists are practical. Once the MDX/front-matter and minor command fixes land, this will be ready to ship.
532-534: Update Template Version to a Released TagBefore merging, replace the placeholder
?ref=mainwith an actual released tag from theterraform-aws-architecture-catalogrepo to prevent drift. For example, if the latest release isv0.15.2, update as follows:- <!-- TODO: Update template version before merging --> - ```bash - boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-modules/?ref=main" --output-folder . --var-file vars.yaml --non-interactive - ``` + ```bash + boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-modules/?ref=v0.15.2" --output-folder . --var-file vars.yaml --non-interactive + ```Make sure to:
- Choose the most recent stable tag (e.g.,
v0.15.2).- Update this same version across the other two catalog‐template references in your docs to keep them in sync.
| <!-- TODO: Update template version before merging --> | ||
| ```bash | ||
| boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-root/?ref=main" --output-folder . --var-file vars.yaml --non-interactive | ||
| ``` | ||
|
|
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Replace template ref=main with a released version before merge.
This is called out in the PR TODO. Use a tagged release for stability.
- <!-- TODO: Update template version before merging -->
- ```bash
- boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-root/?ref=main" --output-folder . --var-file vars.yaml --non-interactive
- ```
+ ```bash
+ boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-root/?ref=vX.Y.Z" --output-folder . --var-file vars.yaml --non-interactive
+ ```To verify across the repo, run:
If you want, I can look up the latest released tag you plan to target and update all three locations in this doc.
🏁 Script executed:
#!/bin/bash
# Find any lingering refs to ?ref=main in boilerplate template URLs
rg -nP '\?ref=main' -C2Length of output: 79866
Update all boilerplate template URLs to use a tagged release instead of ?ref=main
I ran the Ripgrep search and found multiple occurrences of ?ref=main in boilerplate commands that should be switched to a released tag (e.g. ?ref=vX.Y.Z) for stability:
• docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md
– lines 199–203: devops-foundations-infrastructure-live-root
– lines 450–453: devops-foundations-infrastructure-live-access-control
– lines 531–533: devops-foundations-infrastructure-modules
• docs/2.0/docs/pipelines/tutorials/deploying-to-aws-gov-cloud.md
– line 90: github-actions-single-account-setup
– line 95: gitlab-pipelines-single-account-setup
Please replace each ?ref=main with the appropriate tagged release (e.g. ?ref=v1.2.3) before merging. Let me know if you’d like me to look up the latest tag or help update these snippets across the docs!
🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
200-200: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
🤖 Prompt for AI Agents
In docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md around lines
199–203 (and also update the other occurrences called out: lines 450–453 and
531–533 in the same file, plus
docs/2.0/docs/pipelines/tutorials/deploying-to-aws-gov-cloud.md lines 90 and
95), replace the boilerplate template URLs that end with ?ref=main with a
specific released tag (for example ?ref=vX.Y.Z) to ensure reproducible installs;
update the commented TODO about template version if present, and confirm each
snippet uses the same vetted tag (or the correct tag per template) before
merging.
| ```bash | ||
| boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-access-control/?ref=main" --output-folder . --var-file vars.yaml --non-interactive | ||
| ``` |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
Replace ref=main with a released version (access-control template).
Same change as earlier; use a tag for stability.
- <!-- TODO: Update template version before merging -->
- ```bash
- boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-access-control/?ref=main" --output-folder . --var-file vars.yaml --non-interactive
- ```
+ ```bash
+ boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-access-control/?ref=vX.Y.Z" --output-folder . --var-file vars.yaml --non-interactive
+ ```Ensure stable template version
Replace the placeholder reference to the main branch with a specific released tag (for example, vX.Y.Z) to avoid drifting documentation and unpredictable changes. Remove the TODO comment once updated.
• In docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md (around lines 451–453):
- <!-- TODO: Update template version before merging -->
- ```bash
- boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-access-control/?ref=main" --output-folder . --var-file vars.yaml --non-interactive
- ```
+ ```bash
+ boilerplate --template-url "git@github.com:gruntwork-io/terraform-aws-architecture-catalog.git//templates/devops-foundations-infrastructure-live-access-control/?ref=vX.Y.Z" --output-folder . --var-file vars.yaml --non-interactive
+ ```🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
451-451: Code block style
Expected: indented; Actual: fenced
(MD046, code-block-style)
🤖 Prompt for AI Agents
In docs/2.0/docs/pipelines/installation/addingnewgitlabrepo.md around lines 451
to 453, the example boilerplate command pins the template to the unstable "main"
branch and includes a TODO; update the --template-url to reference a specific
released tag (e.g., replace ?ref=main with ?ref=vX.Y.Z using the actual released
version) and remove the TODO comment so the docs point to a stable template
version.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
docs/2.0/docs/accountfactory/guides/vend-aws-account.md (4)
10-12: Tighten audience gating phrasing for the two generation methods.Minor copy polish to improve readability and consistency with product capitalization.
Apply this diff:
-1. Using the [Gruntwork Developer Portal](/2.0/docs/accountfactory/guides/vend-aws-account?account-creation-method=ui#using-the-gruntwork-developer-portal) (**GitLab and GitHub non-enterprise customers**) +1. Using the [Gruntwork Developer Portal](/2.0/docs/accountfactory/guides/vend-aws-account?account-creation-method=ui#using-the-gruntwork-developer-portal) (**GitLab and GitHub, non‑enterprise**) 2. Using the [Account Factory workflow in your repository](/2.0/docs/accountfactory/guides/vend-aws-account?account-creation-method=workflow#using-the-account-factory-workflow-in-your-repository) (**GitHub only**)
19-29: Clarify required permissions and standardize capitalization (“Account Factory”).
- “Authenticated” might imply any logged-in user; most orgs restrict this to maintainers/admins. Explicitly naming the role reduces support churn.
- Use “Account Factory” as a proper noun consistently.
Apply this diff:
-1. Navigate to the [Account Request](https://app.gruntwork.io/account-factory/request-generator) page in the Gruntwork Developer Portal, as an authenticated user, to access the request generator UI. +1. Navigate to the [Account Request](https://app.gruntwork.io/account-factory/request-generator) page in the Gruntwork Developer Portal, as an authenticated and authorized user (e.g., Admin or Maintainer), to access the request generator UI. @@ -1. If the form is disabled for filling out, request that an Admin in your Gruntwork Developer Account configures the Account factory settings. +1. If the form is disabled for filling out, request that an Admin in your Gruntwork Developer Account configures the Account Factory settings.
39-42: Tighten wording around the GitHub inputs limit.Small copy edit to read more naturally.
Apply this diff:
-The JSON payload approach provides greater flexibility for account vending, overcoming the GitHub workflow restriction of a 10-input maximum. +The JSON payload approach provides greater flexibility for account vending and avoids GitHub’s limit of at most 10 workflow inputs.
75-80: Add cross-links for “Account Baseline” and “Terragrunt units” for faster wayfinding.Linking these terms to their respective docs will help readers continue the flow without searching.
If you share the canonical URLs for “Account Baseline” and “Terragrunt units” in this docs set, I can propose a precise patch.
📜 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 ignored due to path filters (1)
static/img/accountfactory/dev-portal-request-generator.pngis excluded by!**/*.png
📒 Files selected for processing (1)
docs/2.0/docs/accountfactory/guides/vend-aws-account.md(2 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/2.0/docs/accountfactory/guides/vend-aws-account.md
[grammar] ~1-~1: There might be a mistake here.
Context: import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; #...
(QB_NEW_EN)
[grammar] ~10-~10: There might be a mistake here.
Context: ...b and GitHub non-enterprise customers**) 2. Using the [Account Factory workflow in y...
(QB_NEW_EN)
[grammar] ~23-~23: There might be a mistake here.
Context: ...configures the Account factory settings. 1. Fill out the form with the required info...
(QB_NEW_EN)
⏰ 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). (3)
- GitHub Check: validate_build
- GitHub Check: Pull Request has non-contributor approval
- GitHub Check: Validate generated content
🔇 Additional comments (4)
docs/2.0/docs/accountfactory/guides/vend-aws-account.md (4)
1-2: LGTM on MDX imports at top-of-file.These Docusaurus MDX imports look correct and are positioned appropriately at the top of the document.
63-69: Confirm the stated creation durations and add a small caveat.Timelines here (“10 to 15 minutes,” “may extend to 45 minutes”) are helpful, but they’re environment- and queue-dependent. Recommend verifying with recent runs and optionally adding “depending on AWS account vending throughput and queue length.”
If accurate, consider:
-Once the account request PR merges into the main branch, Pipelines will initiate the account creation in AWS. This process typically takes 10 to 15 minutes but may extend to 45 minutes. +Once the account request PR merges into the main branch, Pipelines will initiate account creation in AWS. This typically takes 10–15 minutes but may extend to ~45 minutes depending on AWS and pipeline queue load.
63-76: AI summary inconsistency: SSO/root-login guidance is still present here.The AI-generated summary claims prior SSO/root-login guidance was removed, but Lines 69–71 still include these bullets. The current content looks useful—no change requested—just flagging the summary mismatch.
14-16: Ensure Tabs deep-links and safe defaultI didn’t find any custom implementation of a
queryStringprop for<Tabs>in our repo—<Tabs>is the core Docusaurus theme component imported from@theme/Tabs, which out of the box only supportsgroupId,values, anddefaultValue. Without custom logic (e.g. a theme override or wrapper parsingURLSearchParams), thequeryString="account-creation-method"prop will be ignored and deep-links won’t auto-select the intended tab.To address this:
- Add a
defaultValue="ui"fallback so the “Using Portal UI” tab always shows if the URL parameter isn’t parsed.- Implement or verify a wrapper or plugin that reads the
account-creation-methodURL parameter and syncs it with the Tabs component—or remove the unsupportedqueryStringprop if no such logic exists.Suggested MDX diff:
-<Tabs groupId="account-creation-method" queryString="account-creation-method"> +<Tabs groupId="account-creation-method" defaultValue="ui" queryString="account-creation-method">If there isn’t already a theme override, you can create a simple wrapper in
src/components/CustomTabs.tsx:import Tabs from '@theme/Tabs'; import {useLocation} from '@docusaurus/router'; export default function CustomTabs(props) { const {search} = useLocation(); const params = new URLSearchParams(search); const defaultValue = params.get('account-creation-method') ?? props.defaultValue; return <Tabs {...props} defaultValue={defaultValue} />; }Then update your MDX imports:
- import Tabs from '@theme/Tabs'; + import CustomTabs from 'src/components/CustomTabs';This ensures:
?account-creation-method=workflowselects the “workflow” tab.- A safe
uifallback if the URL param is missing or invalid.⛔ Skipped due to learnings
Learnt from: CR PR: gruntwork-io/docs#0 File: .cursor/rules/gitlab-background.mdc:0-0 Timestamp: 2025-07-23T21:18:35.163Z Learning: Applies to docs/**/*.mdx : Whenever presenting information that diverges between GitHub and GitLab, use the <Tabs> and <TabItem> components to distinguish the two sets of information UNLESS the distinction is just changing one word. For example, GitHub has pull requests and GitLab has merge requests, so we can just say '... pull/merge requests...' and not need full <Tabs>.
| Access the Actions tab in your `infrastructure-live-root` repository on GitHub and select `Account factory` from the left-hand pane. | ||
|
|
||
| Click "Run workflow" on the right, paste the generated JSON payload into the dropdown, and click the green "Run workflow" button to initiate the workflow. | ||
| After the workflow is complete, a new Pull Request will be created in the `infrastructure-live-root` repository. This PR will add an account request to the `_new-account-requests` directory. | ||
|
|
There was a problem hiding this comment.
“Dropdown” is inaccurate for workflow_dispatch input; fix wording and verify workflow name casing. Also, specify the repo where the PR appears.
- GitHub’s “Run workflow” UI uses an input field/textarea, not a dropdown, unless a “choice” type was defined.
- Use the exact workflow name casing users will see.
- Clarify where the PR is opened to reduce confusion.
Apply this diff:
-Access the Actions tab in your `infrastructure-live-root` repository on GitHub and select `Account factory` from the left-hand pane.
+Access the Actions tab in your `infrastructure-live-root` repository on GitHub and select `Account Factory` from the left-hand pane. <!-- Adjust casing to match the actual workflow name -->
@@
-Click "Run workflow" on the right, paste the generated JSON payload into the dropdown, and click the green "Run workflow" button to initiate the workflow.
+Click "Run workflow" on the right, paste the generated JSON payload into the input field, and click the green "Run workflow" button to initiate the workflow.
-After the workflow is complete, a new Pull Request will be created in the `infrastructure-live-root` repository. This PR will add an account request to the `_new-account-requests` directory.
+After the workflow completes, a new Pull Request will be created in the `infrastructure-live-root` repository. This PR adds the account request under `_new-account-requests`.Follow-up: Please confirm the exact workflow display name so we can match the casing precisely in the doc.
📝 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.
| Access the Actions tab in your `infrastructure-live-root` repository on GitHub and select `Account factory` from the left-hand pane. | |
| Click "Run workflow" on the right, paste the generated JSON payload into the dropdown, and click the green "Run workflow" button to initiate the workflow. | |
| After the workflow is complete, a new Pull Request will be created in the `infrastructure-live-root` repository. This PR will add an account request to the `_new-account-requests` directory. | |
| Access the Actions tab in your `infrastructure-live-root` repository on GitHub and select `Account Factory` from the left-hand pane. <!-- Adjust casing to match the actual workflow name --> | |
| Click "Run workflow" on the right, paste the generated JSON payload into the input field, and click the green "Run workflow" button to initiate the workflow. | |
| After the workflow completes, a new Pull Request will be created in the `infrastructure-live-root` repository. This PR adds the account request under `_new-account-requests`. |
🤖 Prompt for AI Agents
In docs/2.0/docs/accountfactory/guides/vend-aws-account.md around lines 55 to
59, update the wording that currently says “paste the generated JSON payload
into the dropdown” to reflect GitHub’s workflow_dispatch UI (use “input field”
or “textarea” as appropriate) and replace the workflow name with the exact
display name/casing shown in GitHub; also clarify that the new Pull Request is
opened in the infrastructure-live-root repository (adding the
_new-account-requests path for clarity). Verify the exact workflow display name
in GitHub and use that exact casing in the docs before committing the change.
TODO
mainto released versionSummary by CodeRabbit
New Features
Documentation
Chores
Style