Revert "fixes: #1888 Documentation — eSignet standalone multi-namespace deployment (esignet standalone + MOSIP platform profiles)"#263
Open
ckm007 wants to merge 1 commit into
Open
Conversation
…ce deployment (esignet standalone + MOSIP platform profiles)"
Contributor
WalkthroughDocumentation-only PR that removes profile-based Terraform/Helmsman concepts, the eSignet standalone deployment guide, and the ChangesMOSIP Docs Simplification and DSF Expansion
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/ENVIRONMENT_DESTRUCTION_GUIDE.md (1)
44-49: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winDocument the optional
INFRA_PROFILEinput
The destroy workflow still exposesINFRA_PROFILE(mosip/esignet) forinfradestroys and uses it to select the tfvars file. Add it here, or note that it’s only relevant for theinfracomponent.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/ENVIRONMENT_DESTRUCTION_GUIDE.md` around lines 44 - 49, The destroy guide is missing the optional INFRA_PROFILE input used by infra destroys. Update the documentation near the Parameters section to mention INFRA_PROFILE (mosip/esignet) and clarify that it only applies when the Component is infra, since it selects the tfvars file in the destroy workflow. Use the existing Parameters list in ENVIRONMENT_DESTRUCTION_GUIDE and keep the note aligned with how the workflow handles infra-specific inputs.docs/SECRET_GENERATION_GUIDE.md (1)
588-595: 🩺 Stability & Availability | 🟡 Minor | ⚡ Quick winKeep
GH_INFRA_PATandINFRA_PROFILEin the guide..github/workflows/terraform.ymland.github/workflows/terraform-destroy.ymlstill referencesecrets.GH_INFRA_PATand theINFRA_PROFILEinput, so the secret/setup instructions are incomplete without them.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/SECRET_GENERATION_GUIDE.md` around lines 588 - 595, The secret setup list is missing `GH_INFRA_PAT` and `INFRA_PROFILE`, but both are still referenced by the Terraform workflows. Update the repository secret instructions in the secret generation guide so the setup steps explicitly include `GH_INFRA_PAT` and the `INFRA_PROFILE` input alongside the existing items, keeping the guidance aligned with the workflow symbols `terraform.yml` and `terraform-destroy.yml`.
🧹 Nitpick comments (12)
docs/profile-based-deployment.drawio (1)
101-116: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winStale profile references remain in this diagram.
While this layer updates profile labels and state filenames, the diagram still contains references being removed elsewhere in this PR:
- Line 101:
INFRA_PROFILE input—INFRA_PROFILEis removed from workflow guides in this PR (see cohort 1).- Lines 104, 107:
profiles/mosip/aws.tfvarsandprofiles/esignet/aws.tfvars— theprofiles/structure and profile-based tfvars are being deprecated.- Line 116: State isolation examples
aws-infra-mosip-main-terraform.tfstateandaws-infra-esignet-main-terraform.tfstateinclude a profile/component segment (mosip,esignet) that is inconsistent with the simplified{cloud}-{component}-{branch}-terraform.tfstatepattern now documented inARCHITECTURE_DIAGRAMS.mdandterraform/README.md.Consider updating these remaining elements to align with the non-profile deployment model, or remove the
INFRA_PROFILEnode and update tfvars paths to the new location if they have moved.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/profile-based-deployment.drawio` around lines 101 - 116, The deployment diagram still shows deprecated profile-based terms, so update the diagram elements in the drawio content to match the non-profile model used elsewhere in this PR. In the nodes for INFRA_PROFILE, profiles/mosip/aws.tfvars, profiles/esignet/aws.tfvars, and the state isolation examples, replace the old profile-specific labels with the simplified deployment and state naming now documented in the Terraform docs. Use the existing mxCell entries for these labels to locate and revise them so the diagram stays consistent with the renamed workflow inputs and tfvars/state layout.docs/esignet_README.md (1)
121-122: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider restoring branch-to-environment mapping note.
The removed explanation that branch selection determines which GitHub Environment secrets and variables are active (since environment name matches the branch name) is important operational context. Without it, users may select a branch without understanding which secrets will be used.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/esignet_README.md` around lines 121 - 122, Restore the branch-to-environment mapping note in the README section describing GitHub branch selection, since the missing explanation leaves users unaware that the selected branch name determines which GitHub Environment secrets and variables are active. Update the relevant documentation text in the README to explicitly mention the environment-name-matches-branch behavior so readers can understand which secrets will be used when choosing a branch.docs/WORKFLOW_GUIDE.md (8)
360-360: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueAdd language specifier to fenced code block.
- ``` + ```text → eSignet services → OIDC client configuration → Keycloak integration → Mock identity system<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 360, The fenced code block in WORKFLOW_GUIDE
should include an explicit language specifier to match the surrounding markdown
style. Update the code fence around the bullet list to use a text-language fence
so the block is correctly rendered and labeled, keeping the content and
structure otherwise unchanged.</details> <!-- cr-comment:v1:5d4227223174b288c510268d --> _Source: Linters/SAST tools_ --- `315-315`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text Branch: release-0.1.0 Mode: apply<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 315, Add a language specifier to the fenced
block in the workflow guide so the snippet is explicitly marked as text; update
the Markdown fence around the Branch/Mode example to use a descriptive language
tag in that section of WORKFLOW_GUIDE, keeping the existing content unchanged.</details> <!-- cr-comment:v1:2ac8e5951a1387efac051acd --> _Source: Linters/SAST tools_ --- `394-394`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text Click: "Run workflow" Branch: release-0.1.0 Mode: apply<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 394, The fenced code block in the workflow
guide is missing a language specifier, so update the markdown fence to use the
appropriate text language tag on the example block. Locate the example near the
“Run workflow” snippet and make sure the opening fence includes the specifier
while keeping the existing content unchanged.</details> <!-- cr-comment:v1:ba43edf9698f9254286f6ce9 --> _Source: Linters/SAST tools_ --- `514-514`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text DSF File: [prereq-dsf.yaml | external-dsf.yaml | mosip-dsf.yaml | testrigs-dsf.yaml]<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 514, Add a language specifier to the fenced
code block in the workflow guide so the snippet is properly formatted and
rendered consistently. Update the Markdown fence that contains the DSF File
examples to use the appropriate language label in the existing code block,
keeping the content unchanged and matching the surrounding documentation style.</details> <!-- cr-comment:v1:0fd246ecd929060bc298006b --> _Source: Linters/SAST tools_ --- `401-401`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text → API Test Rig → DSL Test Rig → UI Test Rig<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 401, The fenced code block in the workflow
guide is missing a language specifier, so update the markdown fence at the
referenced block to use a plain text specifier. Locate the affected fenced
section showing the test rig list and change the opening fence to a
language-tagged fence while keeping the content unchanged.</details> <!-- cr-comment:v1:96c0fb28ef03059f69fd59be --> _Source: Linters/SAST tools_ --- `300-300`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text ✅ On success → Automatically triggers MOSIP Services deployment<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 300, The fenced code block in the workflow
guide is missing a language specifier; update the Markdown block around the
success message to use the appropriate fenced syntax, using the existing code
block in WORKFLOW_GUIDE as the target. This is a simple docs-only fix: change
the opening fence to include the text specifier so the block is rendered and
highlighted consistently.</details> <!-- cr-comment:v1:c07b5e5c42a0314e4d970443 --> _Source: Linters/SAST tools_ --- `666-666`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text DEPLOYMENT FLOW: ... └── ✅ Deployment Complete!<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 666, Add a language specifier to the fenced
code block in WORKFLOW_GUIDE so the DEPLOYMENT FLOW snippet uses a proper
markdown fence like a text block instead of an unlabeled fence. Update the
surrounding markdown near the deployment flow example and keep the content
unchanged while adjusting the code fence syntax.</details> <!-- cr-comment:v1:e20529be6cd7e0766518d846 --> _Source: Linters/SAST tools_ --- `346-346`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text Click: "Run workflow" Branch: release-0.1.0 Mode: apply<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/WORKFLOW_GUIDE.mdat line 346, The fenced code block in WORKFLOW_GUIDE
should include an explicit language tag to match the requested formatting.
Update the Markdown snippet around the “Click: "Run workflow"” example by
changing the opening fence to use the appropriate specifier, and keep the rest
of the example content unchanged.</details> <!-- cr-comment:v1:902ef8842b39683770c91828 --> _Source: Linters/SAST tools_ </blockquote></details> <details> <summary>docs/DSF_CONFIGURATION_GUIDE.md (1)</summary><blockquote> `39-39`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add language specifier to fenced code block.** ```diff - ``` + ```text Helmsman/dsf/ ├── prereq-dsf.yaml ├── external-dsf.yaml ├── mosip-dsf.yaml └── testrigs-dsf.yaml<details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@docs/DSF_CONFIGURATION_GUIDE.mdat line 39, The fenced example block in the
configuration guide is missing a language specifier, so update the markdown
fence in the DSF_CONFIGURATION_GUIDE section to use the appropriate text
language tag. Keep the content unchanged and ensure the fenced block around the
Helmsman/dsf directory tree remains valid and consistently highlighted.</details> <!-- cr-comment:v1:3c336e7700a2bf9321e39119 --> _Source: Linters/SAST tools_ </blockquote></details> <details> <summary>README.md (1)</summary><blockquote> `749-752`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _⚡ Quick win_ **Clarify the source-of-truth direction for cluster/domain values.** The note states: "Ensure `cluster_name` and `cluster_env_domain` match values used in Helmsman DSF files." Since Terraform runs before DSF configuration in the deployment flow (Step 3d before Step 4a), readers will set these Terraform values first. The DSF guide (docs/DSF_CONFIGURATION_GUIDE.md) states that DSF placeholders should match Terraform values — not the reverse. Consider rephrasing to: "Ensure these values match what you'll use in Helmsman DSF files" or "Set these to values you'll consistently use in DSF files later." <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@README.mdaround lines 749 - 752, The README note forcluster_nameand
cluster_env_domainhas the source-of-truth direction reversed. Update the
wording in the deployment guidance near the Helmsman/DSF references so it tells
readers to choose Terraform values that will be used consistently in DSF files
later, rather than implying Terraform should match preexisting DSF values. Use
the existing cluster/domain bullet text in this section to keep the phrasing
aligned with the deployment flow.</details> <!-- cr-comment:v1:9fd773c5048ab3d95c968adb --> </blockquote></details> </blockquote></details> <details> <summary>🤖 Prompt for all review comments with AI agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.Inline comments:
In@docs/DSF_CONFIGURATION_GUIDE.md:
- Around line 117-138: Replace the hardcoded sample cluster IDs in the DSF
configuration guide example with a placeholder such as $CLUSTER_ID or
; update the “Before/After” snippet under the “Where to Add
clusterid in prereq-dsf.yaml” section so it matches the repo’s prereq-dsf.yaml
conventions. Keep the example generic by changing the clusterId values in the
rancher-monitoring set block and avoid using real-looking IDs like c-m-pbrcfglw
or c-m-5x9k7w3d.In
@docs/ENVIRONMENT_DESTRUCTION_GUIDE.md:
- Around line 172-175: The Terraform state backup step only captures
terraform.tfstate* and misses the profile-scoped state written under
profiles/${profile}/ by configure-backend.sh. Update the backup command in
ENVIRONMENT_DESTRUCTION_GUIDE.md to include the profile state files as well,
using the same terraform-state-backup flow and explicitly covering
profiles//terraform.tfstate so profile-based destroys can restore the correct
state.In
@docs/esignet_README.md:
- Around line 242-244: The workflow run steps in the README omit the required
profileinput, which leaves users with an undocumented selection when starting
the Helmsman deployment. Update the instructions near the Deploy eSignet using
Helmsman workflow to include theprofilechoice explicitly, or clearly note
that any additional inputs use their default values; reference the existing
Actions workflow/run instructions so the added step fits the current
dry-run/applyflow.- Around line 104-137: The README’s Deployment Modes and Workflow Inputs
sections are missing theprofileworkflow input and its impact on MOSIP DSF
checks. Update the documentation to mention thatprofile: esignetalso
bypasses the DSF dependency check in thehelmsman_esignetworkflow, alongside
skip_mosip_dsf_checkandESIGNET_STANDALONE_MODE. Also addprofileto the
Workflow Inputs list with its default value so users know it is required for
manual runs and understand how it changes the DSF condition.- Around line 165-186: The README snippet uses the wrong DSF path, which should
include the profile subdirectory. Update the path reference in the documentation
to match the workflow pattern used by the esignet DSF configuration, and ensure
the example points to Helmsman/dsf//esignet-dsf.yaml rather than the
non-profile-specific path.In
@docs/ONBOARDING_GUIDE.md:
- Line 168: The onboarding guide is pointing to the wrong DSF manifest path,
which is misleading for profile-based setups. Update the referenced location in
the guide to use the profile subdirectory path that matches the workflow
behavior, and ensure the documented path aligns with the
Helmsman/dsf/**/mosip-dsf.yamlpattern and the${PROFILE}-based path used by
the deployment flow.In
@docs/SECRET_GENERATION_GUIDE.md:
- Line 13: The TOC entry for the “How to Add Secrets to GitHub” section has a
broken anchor because the fragment does not match the generated GitHub heading
slug. Update the existing markdown link in the table of contents to use the
correct#7-how-to-add-secrets-to-githubfragment so it points to the## 7. How to Add Secrets to GitHubheading.In
@docs/WORKFLOW_GUIDE.md:
- Line 262: The Workflow 1 “What it does” description in the guide is missing
Keycloak from the deployed components. Update the text in the relevant Workflow
guide section so it matches the external dependencies list used elsewhere, and
make sure the description alongside the deployment steps still includes Keycloak
together with monitoring, Istio, databases, message queues, and storage.In
@README.md:
- Around line 920-1195: The DSF setup guidance uses placeholder names that do
not match the actual tokens in the DSF files, which will confuse users. Update
the README section around the DSF configuration steps to reference the real
variables used in the YAML, especially ${domain_name} and $CLUSTER_ID, instead
of or sandbox.xyz.net. Make sure the instructions for prereq-dsf.yaml,
external-dsf.yaml, mosip-dsf.yaml, esignet-dsf.yaml, and testrigs-dsf.yaml
consistently point to the actual keys and placeholders present in those files.
Outside diff comments:
In@docs/ENVIRONMENT_DESTRUCTION_GUIDE.md:
- Around line 44-49: The destroy guide is missing the optional INFRA_PROFILE
input used by infra destroys. Update the documentation near the Parameters
section to mention INFRA_PROFILE (mosip/esignet) and clarify that it only
applies when the Component is infra, since it selects the tfvars file in the
destroy workflow. Use the existing Parameters list in
ENVIRONMENT_DESTRUCTION_GUIDE and keep the note aligned with how the workflow
handles infra-specific inputs.In
@docs/SECRET_GENERATION_GUIDE.md:
- Around line 588-595: The secret setup list is missing
GH_INFRA_PATand
INFRA_PROFILE, but both are still referenced by the Terraform workflows.
Update the repository secret instructions in the secret generation guide so the
setup steps explicitly includeGH_INFRA_PATand theINFRA_PROFILEinput
alongside the existing items, keeping the guidance aligned with the workflow
symbolsterraform.ymlandterraform-destroy.yml.
Nitpick comments:
In@docs/DSF_CONFIGURATION_GUIDE.md:
- Line 39: The fenced example block in the configuration guide is missing a
language specifier, so update the markdown fence in the DSF_CONFIGURATION_GUIDE
section to use the appropriate text language tag. Keep the content unchanged and
ensure the fenced block around the Helmsman/dsf directory tree remains valid and
consistently highlighted.In
@docs/esignet_README.md:
- Around line 121-122: Restore the branch-to-environment mapping note in the
README section describing GitHub branch selection, since the missing explanation
leaves users unaware that the selected branch name determines which GitHub
Environment secrets and variables are active. Update the relevant documentation
text in the README to explicitly mention the environment-name-matches-branch
behavior so readers can understand which secrets will be used when choosing a
branch.In
@docs/profile-based-deployment.drawio:
- Around line 101-116: The deployment diagram still shows deprecated
profile-based terms, so update the diagram elements in the drawio content to
match the non-profile model used elsewhere in this PR. In the nodes for
INFRA_PROFILE, profiles/mosip/aws.tfvars, profiles/esignet/aws.tfvars, and the
state isolation examples, replace the old profile-specific labels with the
simplified deployment and state naming now documented in the Terraform docs. Use
the existing mxCell entries for these labels to locate and revise them so the
diagram stays consistent with the renamed workflow inputs and tfvars/state
layout.In
@docs/WORKFLOW_GUIDE.md:
- Line 360: The fenced code block in WORKFLOW_GUIDE should include an explicit
language specifier to match the surrounding markdown style. Update the code
fence around the bullet list to use a text-language fence so the block is
correctly rendered and labeled, keeping the content and structure otherwise
unchanged.- Line 315: Add a language specifier to the fenced block in the workflow guide
so the snippet is explicitly marked as text; update the Markdown fence around
the Branch/Mode example to use a descriptive language tag in that section of
WORKFLOW_GUIDE, keeping the existing content unchanged.- Line 394: The fenced code block in the workflow guide is missing a language
specifier, so update the markdown fence to use the appropriate text language tag
on the example block. Locate the example near the “Run workflow” snippet and
make sure the opening fence includes the specifier while keeping the existing
content unchanged.- Line 514: Add a language specifier to the fenced code block in the workflow
guide so the snippet is properly formatted and rendered consistently. Update the
Markdown fence that contains the DSF File examples to use the appropriate
language label in the existing code block, keeping the content unchanged and
matching the surrounding documentation style.- Line 401: The fenced code block in the workflow guide is missing a language
specifier, so update the markdown fence at the referenced block to use a plain
text specifier. Locate the affected fenced section showing the test rig list and
change the opening fence to a language-tagged fence while keeping the content
unchanged.- Line 300: The fenced code block in the workflow guide is missing a language
specifier; update the Markdown block around the success message to use the
appropriate fenced syntax, using the existing code block in WORKFLOW_GUIDE as
the target. This is a simple docs-only fix: change the opening fence to include
the text specifier so the block is rendered and highlighted consistently.- Line 666: Add a language specifier to the fenced code block in WORKFLOW_GUIDE
so the DEPLOYMENT FLOW snippet uses a proper markdown fence like a text block
instead of an unlabeled fence. Update the surrounding markdown near the
deployment flow example and keep the content unchanged while adjusting the code
fence syntax.- Line 346: The fenced code block in WORKFLOW_GUIDE should include an explicit
language tag to match the requested formatting. Update the Markdown snippet
around the “Click: "Run workflow"” example by changing the opening fence to use
the appropriate specifier, and keep the rest of the example content unchanged.In
@README.md:
- Around line 749-752: The README note for
cluster_nameand
cluster_env_domainhas the source-of-truth direction reversed. Update the
wording in the deployment guidance near the Helmsman/DSF references so it tells
readers to choose Terraform values that will be used consistently in DSF files
later, rather than implying Terraform should match preexisting DSF values. Use
the existing cluster/domain bullet text in this section to keep the phrasing
aligned with the deployment flow.</details> <details> <summary>🪄 Autofix (Beta)</summary> Fix all unresolved CodeRabbit comments on this PR: - [ ] <!-- {"checkboxId": "4b0d0e0a-96d7-4f10-b296-3a18ea78f0b9"} --> Push a commit to this branch (recommended) - [ ] <!-- {"checkboxId": "ff5b1114-7d8c-49e6-8ac1-43f82af23a33"} --> Create a new PR with the fixes </details> --- <details> <summary>ℹ️ Review info</summary> <details> <summary>⚙️ Run configuration</summary> **Configuration used**: Repository UI **Review profile**: CHILL **Plan**: Pro **Run ID**: `e93a1ec5-d7e7-4967-adc8-833c1b755332` </details> <details> <summary>📥 Commits</summary> Reviewing files that changed from the base of the PR and between c6dea578408f3354e906689e26627f293eff23f8 and 4b710f4af5ff9049383faf50b1529cc1000a8767. </details> <details> <summary>⛔ Files ignored due to path filters (6)</summary> * `docs/_images/esignet.png` is excluded by `!**/*.png` * `docs/_images/helmsman-external-services.png` is excluded by `!**/*.png` * `docs/_images/helmsman-mosip.png` is excluded by `!**/*.png` * `docs/_images/helmsman-testrigs.png` is excluded by `!**/*.png` * `docs/_images/infra-terraform-apply.png` is excluded by `!**/*.png` * `docs/_images/infra-terraform-destroy.png` is excluded by `!**/*.png` </details> <details> <summary>📒 Files selected for processing (15)</summary> * `README.md` * `docs/DSF_CONFIGURATION_GUIDE.md` * `docs/ENVIRONMENT_DESTRUCTION_GUIDE.md` * `docs/ESIGNET_STANDALONE_DEPLOYMENT_GUIDE.md` * `docs/HELMSMAN_DESTROY_GUIDE.md` * `docs/HELMSMAN_EXTERNAL_GUIDE.md` * `docs/HELMSMAN_MOSIP_GUIDE.md` * `docs/HELMSMAN_TESTRIGS_GUIDE.md` * `docs/ONBOARDING_GUIDE.md` * `docs/SECRET_GENERATION_GUIDE.md` * `docs/TERRAFORM_WORKFLOW_GUIDE.md` * `docs/WORKFLOW_GUIDE.md` * `docs/_images/ARCHITECTURE_DIAGRAMS.md` * `docs/esignet_README.md` * `docs/profile-based-deployment.drawio` </details> <details> <summary>💤 Files with no reviewable changes (5)</summary> * docs/HELMSMAN_EXTERNAL_GUIDE.md * docs/HELMSMAN_TESTRIGS_GUIDE.md * docs/ESIGNET_STANDALONE_DEPLOYMENT_GUIDE.md * docs/TERRAFORM_WORKFLOW_GUIDE.md * docs/HELMSMAN_MOSIP_GUIDE.md </details> </details> <!-- This is an auto-generated comment by CodeRabbit for review status -->
Comment on lines
+117
to
+138
| #### Where to Add clusterid in prereq-dsf.yaml | ||
|
|
||
| **Set it as a GitHub Environment Variable:** | ||
| **Location**: Around line 40-45 in `prereq-dsf.yaml` | ||
|
|
||
| 1. Go to **Repository → Settings → Environments → `<branch-name>` → Variables** | ||
| 2. Add variable: `CLUSTER_ID` = your clusterid (e.g. `c-m-abc12xyz`) | ||
|
|
||
| The DSF file reads it automatically via `${clusterid}` substitution at deploy time. For manual `workflow_dispatch` runs, you can also pass it directly as the `clusterid` workflow input. | ||
|
|
||
| **How the DSF uses it (no changes needed):** | ||
| **Before (Default/Placeholder)**: | ||
| ```yaml | ||
| apps: | ||
| rancher-monitoring: | ||
| namespace: cattle-monitoring-system | ||
| enabled: true | ||
| version: 103.1.0+up45.31.1 | ||
| chart: mosip/rancher-monitoring | ||
| set: | ||
| grafana.global.cattle.clusterId: "c-m-pbrcfglw" # ← CHANGE THIS | ||
| global.cattle.clusterId: "c-m-pbrcfglw" # ← CHANGE THIS | ||
| wait: true | ||
| valuesFile: "$WORKDIR/utils/monitoring_values.yaml" | ||
| priority: -5 | ||
| timeout: 600 | ||
| ``` | ||
|
|
||
| **After (Your Actual clusterid)**: |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify actual clusterId placeholder syntax in prereq-dsf.yaml files
find Helmsman/dsf/ -name "prereq-dsf.yaml" -exec grep -n "clusterId" {} + 2>/dev/null
echo "=== Checking for literal example values ==="
rg -n 'c-m-' Helmsman/dsf/prereq-dsf.yaml || echo "Not found"
echo "=== Checking for \$CLUSTER_ID ==="
rg -n '\$CLUSTER_ID' Helmsman/dsf/prereq-dsf.yaml || echo "Not found"Repository: mosip/infra
Length of output: 976
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "=== DSF guide excerpt ==="
sed -n '100,150p' docs/DSF_CONFIGURATION_GUIDE.md | cat -n
echo "=== clusterId references in docs ==="
rg -n 'clusterId|CLUSTER_ID|cluster-id|prereq-dsf\.yaml' docs/DSF_CONFIGURATION_GUIDE.md
echo "=== prereq-dsf files ==="
find Helmsman/dsf -name 'prereq-dsf.yaml' -print | sort
echo "=== clusterId lines in each prereq-dsf.yaml ==="
while IFS= read -r f; do
echo "--- $f ---"
rg -n 'clusterId|CLUSTER_ID|<cluster-id>|c-m-' "$f" || true
done < <(find Helmsman/dsf -name 'prereq-dsf.yaml' -print | sort)Repository: mosip/infra
Length of output: 3243
Use a placeholder here instead of a sample cluster ID. The prereq-dsf.yaml variants in this repo expect $CLUSTER_ID or <cluster-id>, so reusing c-m-pbrcfglw/c-m-5x9k7w3d here makes the replacement step unclear.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/DSF_CONFIGURATION_GUIDE.md` around lines 117 - 138, Replace the
hardcoded sample cluster IDs in the DSF configuration guide example with a
placeholder such as $CLUSTER_ID or <cluster-id>; update the “Before/After”
snippet under the “Where to Add clusterid in prereq-dsf.yaml” section so it
matches the repo’s prereq-dsf.yaml conventions. Keep the example generic by
changing the clusterId values in the rancher-monitoring set block and avoid
using real-looking IDs like c-m-pbrcfglw or c-m-5x9k7w3d.
Comment on lines
172
to
175
| # Export Terraform state (if using local backend) | ||
| cd terraform/implementations/aws/infra/ | ||
| # For profile-isolated deployments, check the profiles/ directory: | ||
| tar -czf terraform-state-backup-$(date +%Y%m%d).tar.gz profiles/<profile>/terraform.tfstate* | ||
| tar -czf terraform-state-backup-$(date +%Y%m%d).tar.gz terraform.tfstate* | ||
|
|
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check backend configuration script for profile-based state paths
cat .github/scripts/configure-backend.sh | head -100
# Check for any profile-related state path references
rg -n 'profiles' .github/scripts/Repository: mosip/infra
Length of output: 3697
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the backend configuration around the state path logic
sed -n '130,190p' .github/scripts/configure-backend.sh
# Inspect the destroy workflow inputs and backend setup
sed -n '1,220p' .github/workflows/terraform-destroy.yml
# Inspect the backup guidance around the cited lines
sed -n '160,190p' docs/ENVIRONMENT_DESTRUCTION_GUIDE.md
# Find other references to terraform-state backup/state file locations
rg -n 'terraform-state-backup|terraform\.tfstate|profiles/' docs .github/workflows .github/scriptsRepository: mosip/infra
Length of output: 18149
Include profile-scoped Terraform state in the backup
The local backend still writes infra state to profiles/${profile}/... in configure-backend.sh, so terraform.tfstate* alone will miss the files used by profile-based destroys. Add the profile path here too, e.g. profiles/*/terraform.tfstate*.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/ENVIRONMENT_DESTRUCTION_GUIDE.md` around lines 172 - 175, The Terraform
state backup step only captures terraform.tfstate* and misses the profile-scoped
state written under profiles/${profile}/ by configure-backend.sh. Update the
backup command in ENVIRONMENT_DESTRUCTION_GUIDE.md to include the profile state
files as well, using the same terraform-state-backup flow and explicitly
covering profiles/*/terraform.tfstate* so profile-based destroys can restore the
correct state.
Comment on lines
+104
to
+137
| --- | ||
|
|
||
| ## Repository Variables (Optional) | ||
|
|
||
| Configure in **Repository → Settings → Secrets and variables → Actions → Variables**: | ||
|
|
||
| | Variable | Description | Values | | ||
| |----------|-------------|--------| | ||
| | `ESIGNET_STANDALONE_MODE` | Skip MOSIP DSF check for push-triggered runs | `true` / `false` | | ||
|
|
||
| --- | ||
|
|
||
| ## Deployment Modes | ||
|
|
||
| ### Default: MOSIP Platform | ||
| ### 1. Dependent Mode (Default) | ||
|
|
||
| This guide covers eSignet deployed as part of a full MOSIP platform. eSignet is deployed **after** MOSIP core services are running: | ||
| Requires MOSIP DSF to be completed first. The workflow checks for `mosip-dsf=completed` label. | ||
|
|
||
| ``` | ||
| helmsman_external.yml (profile=mosip-platform-1.2.0.x) | ||
| ↓ | ||
| helmsman_mosip.yml (auto-triggered) | ||
| ↓ | ||
| helmsman_esignet.yml (profile=mosip-platform-1.2.0.x) | ||
| ┌─────────────┐ ┌─────────────┐ | ||
| │ MOSIP DSF │ ──► │ eSignet DSF │ | ||
| └─────────────┘ └─────────────┘ | ||
| ``` | ||
|
|
||
| Use `skip_mosip_dsf_check=false` (default) — the workflow checks for the `mosip-dsf=completed` label before deploying. | ||
| ### 2. Standalone Mode | ||
|
|
||
| Set `skip_mosip_dsf_check=true` only if you need to re-run eSignet independently after it has already been deployed once. | ||
| Deploy eSignet independently without MOSIP DSF dependency. | ||
|
|
||
| > **For eSignet standalone** (no full MOSIP, 4 parallel instances): see [ESIGNET_STANDALONE_DEPLOYMENT_GUIDE.md](ESIGNET_STANDALONE_DEPLOYMENT_GUIDE.md). | ||
| **Enable via:** | ||
|
|
||
| | Trigger | Method | | ||
| |---------|--------| | ||
| | Manual run | Set `skip_mosip_dsf_check = true` | | ||
| | Push triggered | Set `ESIGNET_STANDALONE_MODE = true` variable | |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Document the profile workflow input and its effect on DSF dependency checking.
The "Deployment Modes" section documents two ways to skip the MOSIP DSF check, but the workflow actually has a third: selecting profile: esignet also bypasses the check (.github/workflows/helmsman_esignet.yml, DSF check condition includes github.event.inputs.profile != 'esignet'). More critically, the "Workflow Inputs" section later in this document (lines 259-262) omits the profile input entirely, yet it remains a required workflow input with a default value of mosip-platform-java11. Users following this guide will encounter an unexpected required field when running the workflow manually.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 122-122: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/esignet_README.md` around lines 104 - 137, The README’s Deployment Modes
and Workflow Inputs sections are missing the `profile` workflow input and its
impact on MOSIP DSF checks. Update the documentation to mention that `profile:
esignet` also bypasses the DSF dependency check in the `helmsman_esignet`
workflow, alongside `skip_mosip_dsf_check` and `ESIGNET_STANDALONE_MODE`. Also
add `profile` to the Workflow Inputs list with its default value so users know
it is required for manual runs and understand how it changes the DSF condition.
Comment on lines
165
to
+186
| ``` | ||
| Helmsman/dsf/mosip-platform-1.2.0.x/esignet-dsf.yaml (Java 11) | ||
| Helmsman/dsf/mosip-platform-1.2.1.x/esignet-dsf.yaml (Java 21) | ||
| Helmsman/dsf/esignet-dsf.yaml | ||
| ``` | ||
|
|
||
| The workflow selects the correct subdirectory based on the `profile` input. | ||
|
|
||
| ### Domain and Environment Configuration | ||
| ### Key Configurations to Update | ||
|
|
||
| **No manual domain edits needed in the DSF file.** All hostnames and service URLs are resolved via `${domain_name}` substitution at deploy time. | ||
| Update these values for your environment: | ||
|
|
||
| Set your domain as a GitHub Environment Variable: | ||
| - **Repository → Settings → Environments → `<branch-name>` → Variables → `DOMAIN_NAME`** | ||
|
|
||
| The workflow also reads `vars.ESIGNET_DB_PORT` for the PostgreSQL port (typically `5433` for MOSIP platform external postgres). | ||
| ```yaml | ||
| # Domain configurations (replace sandbox.xyz.net) | ||
| keycloakExternalHost: "iam.YOUR_DOMAIN.net" | ||
| istio.hosts[0]: "esignet.YOUR_DOMAIN.net" | ||
| mock_relying_party_ui.mock_relying_party_ui_service_host: "healthservices.YOUR_DOMAIN.net" | ||
|
|
||
| # PostgreSQL host | ||
| databases.mosip_esignet.host: "postgres.YOUR_DOMAIN.net" | ||
| databases.mosip_esignet.port: 5433 | ||
|
|
||
| # eSignet URLs | ||
| mock_relying_party_ui.ESIGNET_UI_BASE_URL: "https://esignet.YOUR_DOMAIN.net" | ||
| mock_relying_party_service.ESIGNET_AUD_URL: "https://esignet.YOUR_DOMAIN.net/v1/esignet/oauth/v2/token" | ||
| ``` |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify: Check if eSignet DSF exists in a profile subdirectory or flat path
# and whether the workflow references match.
echo "=== Checking for esignet-dsf.yaml locations ==="
find . -path '*/Helmsman/dsf/*esignet-dsf.yaml' -type f 2>/dev/null
echo "=== Checking workflow for path patterns ==="
rg -n 'Helmsman/dsf.*esignet-dsf' .github/workflows/helmsman_esignet.ymlRepository: mosip/infra
Length of output: 433
Use the profile subdirectory path here. The DSF file is under Helmsman/dsf/<profile>/esignet-dsf.yaml, not Helmsman/dsf/esignet-dsf.yaml; update this snippet so it matches the workflow’s expected path pattern.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 165-165: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/esignet_README.md` around lines 165 - 186, The README snippet uses the
wrong DSF path, which should include the profile subdirectory. Update the path
reference in the documentation to match the workflow pattern used by the esignet
DSF configuration, and ensure the example points to
Helmsman/dsf/<profile>/esignet-dsf.yaml rather than the non-profile-specific
path.
Comment on lines
+242
to
+244
| 1. Go to **Actions** → **Deploy eSignet using Helmsman** | ||
| 2. Select mode: `dry-run` (preview) or `apply` (deploy) | ||
| 3. Click **Run workflow** |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Incomplete workflow run instructions omit required inputs.
The simplified 3-step sequence omits the profile selection step, which remains a required workflow input with a default value. Users following these minimal instructions will need to interact with undocumented inputs. Consider adding a step for profile selection or noting that additional fields use defaults.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/esignet_README.md` around lines 242 - 244, The workflow run steps in the
README omit the required `profile` input, which leaves users with an
undocumented selection when starting the Helmsman deployment. Update the
instructions near the Deploy eSignet using Helmsman workflow to include the
`profile` choice explicitly, or clearly note that any additional inputs use
their default values; reference the existing Actions workflow/run instructions
so the added step fits the current `dry-run`/`apply` flow.
| 1. **Navigate to the mosip-dsf.yaml file:** | ||
| - Location: `Helmsman/dsf/mosip-platform-1.2.0.x/mosip-dsf.yaml` (Java 11) | ||
| - Location: `Helmsman/dsf/mosip-platform-1.2.1.x/mosip-dsf.yaml` (Java 21) | ||
| - Location: `Helmsman/dsf/mosip-dsf.yaml` |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify: Check for mosip-dsf.yaml locations and workflow push triggers
find . -path '*/Helmsman/dsf/*mosip-dsf.yaml' -type f 2>/dev/null
rg -n 'mosip-dsf.yaml' .github/workflows/ 2>/dev/null | head -20Repository: mosip/infra
Length of output: 453
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== docs/ONBOARDING_GUIDE.md around line 168 ==\n'
sed -n '158,176p' docs/ONBOARDING_GUIDE.md | cat -n
printf '\n== .github/workflows/helmsman_mosip.yml around relevant lines ==\n'
sed -n '20,40p' .github/workflows/helmsman_mosip.yml | cat -n
printf '\n---\n'
sed -n '235,252p' .github/workflows/helmsman_mosip.yml | cat -nRepository: mosip/infra
Length of output: 2463
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path('docs/ONBOARDING_GUIDE.md')
text = p.read_text()
for i, line in enumerate(text.splitlines(), 1):
if 'Helmsman/dsf/mosip-dsf.yaml' in line:
print(i, line)
PYRepository: mosip/infra
Length of output: 198
Use the profile subdirectory path here. The guide should point to Helmsman/dsf/<profile>/mosip-dsf.yaml; the workflow only triggers on Helmsman/dsf/**/mosip-dsf.yaml and runs Helmsman/dsf/${PROFILE}/mosip-dsf.yaml, so the flat path is misleading.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/ONBOARDING_GUIDE.md` at line 168, The onboarding guide is pointing to
the wrong DSF manifest path, which is misleading for profile-based setups.
Update the referenced location in the guide to use the profile subdirectory path
that matches the workflow behavior, and ensure the documented path aligns with
the `Helmsman/dsf/**/mosip-dsf.yaml` pattern and the `${PROFILE}`-based path
used by the deployment flow.
| 4. [WireGuard VPN Configuration](#4-wireguard-vpn-configuration) | ||
| 5. [Kubernetes Config (KUBECONFIG)](#5-kubernetes-config-kubeconfig) | ||
| 6. [reCAPTCHA Keys](#6-recaptcha-keys) | ||
| 7. [How to Add Secrets to GitHub](#how-to-add-secrets-to-github) |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Fix broken TOC anchor link.
The link fragment #how-to-add-secrets-to-github is missing the 7- prefix. GitHub generates anchors from the full header text, so ## 7. How to Add Secrets to GitHub becomes #7-how-to-add-secrets-to-github. This TOC link will not navigate to the section.
Update to:
7. [How to Add Secrets to GitHub](`#7-how-to-add-secrets-to-github`)🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 13-13: Link fragments should be valid
(MD051, link-fragments)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/SECRET_GENERATION_GUIDE.md` at line 13, The TOC entry for the “How to
Add Secrets to GitHub” section has a broken anchor because the fragment does not
match the generated GitHub heading slug. Update the existing markdown link in
the table of contents to use the correct `#7-how-to-add-secrets-to-github`
fragment so it points to the `## 7. How to Add Secrets to GitHub` heading.
| ### Workflow 1: Prerequisites & External Dependencies | ||
|
|
||
| **What it does**: Deploys monitoring, Istio, databases, message queues, storage, Keycloak | ||
| **What it does**: Deploys monitoring, Istio, databases, message queues, storage |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Restore Keycloak in Workflow 1 description.
The "What it does" line removed Keycloak from the deployed components, but both the README (Step 4c, line 1297) and the DSF guide identify Keycloak as part of the external dependencies deployment. The description should read:
- **What it does**: Deploys monitoring, Istio, databases, message queues, storage
+ **What it does**: Deploys monitoring, Istio, databases, message queues, storage, identity management (Keycloak)📝 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.
Suggested change
| **What it does**: Deploys monitoring, Istio, databases, message queues, storage | |
| **What it does**: Deploys monitoring, Istio, databases, message queues, storage, identity management (Keycloak) |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/WORKFLOW_GUIDE.md` at line 262, The Workflow 1 “What it does”
description in the guide is missing Keycloak from the deployed components.
Update the text in the relevant Workflow guide section so it matches the
external dependencies list used elsewhere, and make sure the description
alongside the deployment steps still includes Keycloak together with monitoring,
Istio, databases, message queues, and storage.
Comment on lines
+920
to
+1195
| #### Step 4a: Update DSF Configuration Files | ||
|
|
||
| **No manual DSF file edits are required per environment.** All domain, cluster, port, and environment name values are resolved at deploy time via Helmsman's `${VAR}` substitution. | ||
| 1. **Clone the repository (if not already done):** | ||
|
|
||
| **How values are provided:** | ||
| ```bash | ||
| git clone https://github.com/mosip/infra.git | ||
| cd infra/Helmsman | ||
| ``` | ||
|
|
||
| When you trigger a Helmsman workflow manually (`workflow_dispatch`), you enter these values directly as **workflow inputs** — no pre-configuration needed. The GitHub Environment (`<branch-name>`) must already exist (created automatically when Terraform runs or manually via Repository → Settings → Environments). | ||
| 2. **Navigate to DSF configuration directory:** | ||
|
|
||
| For **push-triggered runs** (no workflow inputs), values fall back to GitHub Environment Variables. In that case, navigate to **Repository → Settings → Environments → `<branch-name>` → Variables** and add: | ||
| ```bash | ||
| cd dsf/ | ||
| ``` | ||
|
|
||
| | Variable | Example value | Used by | | ||
| |----------|--------------|---------| | ||
| | `DOMAIN_NAME` | `soil38.mosip.net` | All DSFs — hostnames, Istio VS, DB hosts | | ||
| | `ENV_NAME` | `soil38` | Landing page, testrig user | | ||
| | `CLUSTER_ID` | `c-m-abc12xyz` | `prereq-dsf.yaml` — rancher-monitoring | | ||
| | `SLACK_CHANNEL_NAME` | `#mosip-alerts` | `prereq-dsf.yaml` — alerting | | ||
| | `DB_PORT` | `5433` | MOSIP platform external postgres port | | ||
| | `ESIGNET_DB_PORT` | `5432` | eSignet container postgres port | | ||
| 3. **Update prereq-dsf.yaml:** | ||
|
|
||
| > **Domain consistency**: `DOMAIN_NAME` must match `cluster_env_domain` in `aws.tfvars`. `ENV_NAME` must match `cluster_name`. No in-file replacements needed. | ||
| > **IMPORTANT CONFIGURATION:** This file requires **clusterid** configuration **only if you're using Rancher UI** (when `rancher_import = true`)! See [DSF Configuration Guide - clusterid](docs/DSF_CONFIGURATION_GUIDE.md#critical-configuration-clusterid) | ||
|
|
||
| **Finding your clusterid (for `CLUSTER_ID`):** | ||
| - **Rancher UI**: Open your cluster → the URL contains `c-m-xxxxx` — that's your clusterid | ||
| - **kubectl**: `kubectl get setting cluster-id -n cattle-system -o jsonpath='{.value}'` | ||
| - Only needed if `rancher_import = true` in your Terraform config | ||
| **Critical Updates Required:** | ||
|
|
||
| **Alerting (Slack) setup:** | ||
| - **clusterid Configuration (OPTIONAL - only if using Rancher):** | ||
| - **When needed?** Only if `rancher_import = true` in your terraform configuration | ||
| - **Skip if:** Deploying without Rancher UI (`rancher_import = false`) - ignore this entire section | ||
| - **What is this?** Unique identifier for your Rancher-managed cluster | ||
| - **Why needed?** Monitoring dashboards won't work without it in Rancher deployments | ||
| - **How to find:** See [DSF Guide - Finding clusterid](docs/DSF_CONFIGURATION_GUIDE.md#how-to-find-your-clusterid) | ||
| - **Location in file:** Around line 40-45 | ||
| - **What to change:** | ||
|
|
||
| Create a Slack incoming webhook ([guide](https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks/)), then add: | ||
| - `SLACK_CHANNEL_NAME` variable (e.g. `#mosip-alerts`) | ||
| - `SLACK_WEBHOOK_URL` environment secret | ||
| ```yaml | ||
| set: | ||
| grafana.global.cattle.clusterId: "c-m-pbrcfglw" # ← REPLACE THIS | ||
| global.cattle.clusterId: "c-m-pbrcfglw" # ← REPLACE THIS | ||
| ``` | ||
|
|
||
| - **Alerting Configuration:** | ||
| Alerting is part of cluster monitoring, where alert notifications are sent to the configured email or Slack channel. | ||
| - `<slack-channel-name>` → Slack channel name configured for alert notifications. | ||
| - `<slack-api-url>` → Slack API URL configured for alert notifications. | ||
| - `<env-name>` → provide the cluster name. | ||
|
|
||
| > **Note:** | ||
| > - Create a Slack incoming webhook: [Slack incoming webhooks guide](https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks/) | ||
| > - Create a Slack app for your environment from the above URL. | ||
| > - After creating the app, select `Incoming webhooks` from the **Features** section. | ||
| > - Activate Incoming webhooks. | ||
| > - Select `Add New Webhook To Workspace` and choose a Slack channel where alerts should be notified. | ||
| > - The incoming webhook URL will be created. | ||
| > - Update `slack_api_url`, `channel`, and `env-name` in the `rancher-monitoring` section in `prereq-dsf.yaml`. | ||
|
|
||
|
|
||
| - **Domain Validation (Double-check):** | ||
| - `<env-name>` → your cluster name (e.g., `soil38`) | ||
| - `sandbox.xyz.net` → your domain name (e.g., `soil38.mosip.net`) | ||
| - **Why?** Every service needs to know its web address | ||
| - **Chart Versions:** Verify and update to latest stable versions | ||
| - Check [MOSIP Helm Repository](https://mosip.github.io/mosip-helm) for latest versions | ||
| - **Namespace Configuration:** Ensure proper namespace isolation | ||
| - **What is namespace?** Like separate folders for different applications | ||
|
|
||
| > **Note:** Maintain consistency with your Terraform configuration: | ||
| > | ||
| > - `<env-name>` should match `cluster_name` in `aws.tfvars` | ||
| > - `sandbox.xyz.net` should match `cluster_env_domain` in `aws.tfvars`. | ||
| > - These above variables MUST be identical or deployment will fail because the same domain is being mapped in the route-53 service in aws. | ||
| > - If the cluster is created manually instead of using terraform scripts then user can provide the `values` for above two variables as per his requirement, no need to match variables in `aws.tfvars`. | ||
|
|
||
| **reCAPTCHA keys (MOSIP platform profiles):** | ||
| ```yaml | ||
| # Configure monitoring, Istio, logging | ||
| helmRepos: | ||
| rancher-latest: "https://releases.rancher.com/server-charts/latest" | ||
|
|
||
| apps: | ||
| rancher-monitoring: | ||
| enabled: true | ||
| namespace: cattle-monitoring-system | ||
| # DON'T FORGET: Update clusterid here! See above | ||
| ``` | ||
|
|
||
| 📖 **[View detailed reCAPTCHA Setup Guide](docs/RECAPTCHA_SETUP_GUIDE.md)** | ||
| **Need detailed help?** [DSF Configuration Guide - Prerequisites](docs/DSF_CONFIGURATION_GUIDE.md#prerequisites-dsf-configuration) | ||
|
|
||
| Create reCAPTCHA v2 keys for each domain at [Google reCAPTCHA Admin](https://www.google.com/recaptcha/admin/create), then add as **Environment Secrets**: | ||
| 4. **Update external-dsf.yaml:** | ||
|
|
||
| | Secret | Domain | | ||
| |--------|--------| | ||
| | `PREREG_CAPTCHA_SITE_KEY` / `PREREG_CAPTCHA_SECRET_KEY` | `prereg.your-domain.net` | | ||
| | `ADMIN_CAPTCHA_SITE_KEY` / `ADMIN_CAPTCHA_SECRET_KEY` | `admin.your-domain.net` | | ||
| | `RESIDENT_CAPTCHA_SITE_KEY` / `RESIDENT_CAPTCHA_SECRET_KEY` | `resident.your-domain.net` | | ||
| **Critical Updates Required:** | ||
|
|
||
| The `external-dsf.yaml` reads these via `${PREREG_CAPTCHA_SITE_KEY}` etc. — no DSF edits needed. | ||
| - **Domain Validation (Double-check):** | ||
| - `<sandbox>` → your cluster name (e.g., `soil`) | ||
| - `sandbox.xyz.net` → your domain name (e.g., `soil.mosip.net`) | ||
| - **Chart Versions:** Update Helm chart versions to latest stable releases | ||
| - **Database Branch:** Verify correct branch for DB scripts and schema | ||
| - **PostgreSQL Configuration:** Match with Terraform `enable_postgresql_setup` setting | ||
|
|
||
| **PostgreSQL configuration:** | ||
| > **Note:** Maintain consistency with your Terraform configuration: | ||
| > - `<sandbox>` should match `cluster_name` in `aws.tfvars` | ||
| > - `sandbox.xyz.net` should match `cluster_env_domain` in `aws.tfvars`. | ||
| > - These above variables MUST be identical or deployment will fail because the same domain is being mapped in the route-53 service in aws. | ||
| > - If the cluster is created manually instead of using terraform scripts then user can provide the `values` for above two variables as per his requirement, no need to match variables in `aws.tfvars`. | ||
|
|
||
| The only DSF setting that still requires a manual decision is `postgres.enabled` in `external-dsf.yaml`: | ||
| - **Configure reCAPTCHA keys:** | ||
|
|
||
| 1. **Create reCAPTCHA keys for each domain:** | ||
|
|
||
| 📖 **[View detailed reCAPTCHA Setup Guide with screenshots](docs/RECAPTCHA_SETUP_GUIDE.md)** | ||
|
|
||
| - Go to [Google reCAPTCHA Admin](https://www.google.com/recaptcha/admin/create) | ||
| - Create reCAPTCHA v2 ("I'm not a robot" Checkbox) for each domain: | ||
| - **PreReg domain**: `prereg.your-domain.net` (e.g., `prereg.soil.mosip.net`) | ||
| - **Admin domain**: `admin.your-domain.net` (e.g., `admin.soil.mosip.net`) | ||
| - **Resident domain**: `resident.your-domain.net` (e.g., `resident.soil.mosip.net`) | ||
|
|
||
| 2. **Update captcha-setup.sh arguments in external-dsf.yaml (around line 315):** | ||
|
|
||
| ```yaml | ||
| apps: | ||
| postgres: | ||
| enabled: false # false = use external Terraform-provisioned PostgreSQL | ||
| # true = deploy container PostgreSQL (for dev/test) | ||
| hooks: | ||
| postInstall: "$WORKDIR/hooks/captcha-setup.sh PREREG_SITE_KEY PREREG_SECRET_KEY ADMIN_SITE_KEY ADMIN_SECRET_KEY RESIDENT_SITE_KEY RESIDENT_SECRET_KEY" | ||
| ``` | ||
|
|
||
| Set this to match your Terraform `enable_postgresql_setup` value. Everything else (host, port, credentials) is resolved automatically from environment variables and hooks. | ||
| **Arguments order:** | ||
|
|
||
| **Database branch (MOSIP platform):** | ||
| - **Argument 1**: PreReg site key | ||
| - **Argument 2**: PreReg secret key | ||
| - **Argument 3**: Admin site key | ||
| - **Argument 4**: Admin secret key | ||
| - **Argument 5**: Resident site key | ||
| - **Argument 6**: Resident secret key | ||
|
|
||
| 3. **Example configuration:** | ||
|
|
||
| ```yaml | ||
| # In mosip-dsf.yaml — update to match your MOSIP version | ||
| gitRepo: | ||
| dbBranch: "v1.2.0.2" # must match your deployed MOSIP chart versions | ||
| hooks: | ||
| postInstall: "$WORKDIR/hooks/captcha-setup.sh 6LfkAMwrAAAAAATB1WhkIhzuAVMtOs9VWabODoZ_ 6LfkAMwrAAAAAHQAT93nTGcLKa-h3XYhGoNSG-NL 6LdNAcwrAAAAAETGWvz-3I12vZ5V8vPJLu2ct9CO 6LdNAcwrAAAAAE4iWGJ-g6Dc2HreeJdIwAl5h1iL 6LdRAcwrAAAAAFUEHHKK5D_bSrwAPqdqAJqo4mCk 6LdRAcwrAAAAAOeVl6yHGBCBA8ye9GsUOy4pi9s9" | ||
| ``` | ||
|
|
||
| **What you should NOT edit manually in DSF files:** | ||
| - Domain names or cluster names (use `vars.DOMAIN_NAME` / `vars.ENV_NAME`) | ||
| - Keycloak hostnames (derived from `${domain_name}`) | ||
| - eSignet service URLs (derived from `${domain_name}`) | ||
| - Test rig endpoints (derived from `${domain_name}`) | ||
| - Captcha keys (passed as GitHub Secrets via `${VAR}` substitution) | ||
| ```yaml | ||
| # Configure external dependencies | ||
| apps: | ||
| postgresql: | ||
| # Set based on your Terraform configuration: | ||
| enabled: false # false if enable_postgresql_setup = true (external PostgreSQL via Terraform) | ||
| # true if enable_postgresql_setup = false (container PostgreSQL) | ||
| minio: | ||
| enabled: true | ||
| kafka: | ||
| enabled: true | ||
| ``` | ||
|
|
||
| **Need detailed help?** [DSF Configuration Guide](docs/DSF_CONFIGURATION_GUIDE.md) | ||
| 5. **Update mosip-dsf.yaml:** | ||
|
|
||
| **Critical Updates Required:** | ||
|
|
||
| - **Domain Validation (Double-check):** | ||
| > - `<sandbox>` should match `cluster_name` in `aws.tfvars` | ||
| > - `sandbox.xyz.net` should match `cluster_env_domain` in `aws.tfvars`. | ||
| > - These above variables MUST be identical or deployment will fail because the same domain is being mapped in the route-53 service in aws. | ||
| > - If the cluster is created manually instead of using terraform scripts then user can provide the `values` for above two variables as per his requirement, no need to match variables in `aws.tfvars`. | ||
| - **Chart Versions:** Update MOSIP service chart versions to compatible releases | ||
| - **Database Branch:** Ensure correct MOSIP DB scripts branch matches deployment version | ||
| - **Service Dependencies:** Verify all required external services are properly configured | ||
| - **Resource Limits:** Adjust CPU/memory limits based on environment requirements | ||
|
|
||
| > **Note:** Maintain consistency with your Terraform configuration: | ||
| > | ||
| > - `<sandbox>` should match `cluster_name` in `aws.tfvars` | ||
| > - `sandbox.xyz.net` should match `cluster_env_domain` in `aws.tfvars`. | ||
| > - These above variables MUST be identical or deployment will fail because the same domain is being mapped in the route-53 service in aws. | ||
| > - If the cluster is created manually instead of using terraform scripts then user can provide the `values` for above two variables as per his requirement, no need to match variables in `aws.tfvars`. | ||
|
|
||
| ```yaml | ||
| # Configure MOSIP services | ||
| apps: | ||
| config-server: | ||
| enabled: true | ||
| artifactory: | ||
| enabled: true | ||
| kernel: | ||
| enabled: true | ||
| ``` | ||
|
|
||
| 6. **Update esignet-dsf.yaml:** | ||
|
|
||
| **Critical Updates Required:** | ||
|
|
||
| - **Domain Validation (Double-check):** | ||
| - `<sandbox>` → your cluster name (e.g., `soil`) | ||
| - `sandbox.xyz.net` → your domain name (e.g., `soil.mosip.net`) | ||
| - **eSignet Domain**: `esignet.sandbox.xyz.net` → `esignet.soil.mosip.net` | ||
| - **Chart Versions:** Update eSignet chart versions to latest stable releases | ||
| - **Database Branch:** Verify correct eSignet DB scripts branch | ||
| - **OIDC Configuration:** Configure OIDC client settings and redirect URLs | ||
| - **Mock Services:** Enable/disable mock identity system and relying party based on requirements | ||
| - **Keycloak Integration:** Ensure Keycloak endpoints and realm settings are correct | ||
|
|
||
| > **Note:** Maintain consistency with your Terraform configuration: | ||
| > | ||
| > - `<sandbox>` should match `cluster_name` in `aws.tfvars` | ||
| > - `sandbox.xyz.net` should match `cluster_env_domain` in `aws.tfvars` | ||
| > - eSignet requires MOSIP core services to be deployed first (unless using standalone mode) | ||
|
|
||
| ```yaml | ||
| # Configure eSignet services | ||
| apps: | ||
| esignet: | ||
| enabled: true | ||
| mock-identity-system: | ||
| enabled: true # Set to false for production with real identity system | ||
| oidc-ui: | ||
| enabled: true | ||
| mock-relying-party: | ||
| enabled: true # Set to false for production | ||
| ``` | ||
|
|
||
| **eSignet-Specific Configuration:** | ||
|
|
||
| - **Mock Identity System:** | ||
| - Enable (`true`) for development/testing without MOSIP integration | ||
| - Disable (`false`) for production with real MOSIP identity system | ||
| - **OIDC Client Configuration:** | ||
| - Update redirect URIs for your domain | ||
| - Configure client IDs and secrets | ||
| - Set up allowed scopes and claims | ||
| - **Keycloak Settings:** | ||
| - Verify Keycloak realm: typically `esignet` | ||
| - Update Keycloak host: `https://iam.sandbox.xyz.net` → `https://iam.soil.mosip.net` | ||
| - Ensure Keycloak client credentials are configured | ||
|
|
||
| **Need detailed help?** [DSF Configuration Guide - eSignet](docs/esignet_README.md#dsf-configuration) | ||
|
|
||
| 7. **Update testrigs-dsf.yaml (if deploying test environment):** | ||
|
|
||
| **Critical Updates Required:** | ||
|
|
||
| - **Domain Validation (Double-check):** | ||
| > - `<sandbox>` should match `cluster_name` in `aws.tfvars` | ||
| > - `sandbox.xyz.net` should match `cluster_env_domain` in `aws.tfvars`. | ||
| > - These above variables MUST be identical or deployment will fail because the same domain is being mapped in the route-53 service in aws. | ||
| > - If the cluster is created manually instead of using terraform scripts then user can provide the `values` for above two variables as per his requirement, no need to match variables in `aws.tfvars`. | ||
| - **Test Chart Versions:** Update test rig chart versions to match MOSIP service versions | ||
| - **Database Branch:** Ensure test DB scripts use correct branch | ||
| - **Test Configuration:** Update test endpoints, API versions, and test data paths | ||
| - **Resource Allocation:** Configure appropriate test environment resource limits | ||
|
|
||
| > **Critical Validation Checklist for All DSF Files:** | ||
| > | ||
| > **Domain Configuration (Validate Twice):** | ||
| > - `<sandbox>` should match `cluster_name` in `aws.tfvars` | ||
| > - `sandbox.xyz.net` should match `cluster_env_domain` in `aws.tfvars`. | ||
| > - These above variables MUST be identical or deployment will fail because the same domain is being mapped in the route-53 service in aws. | ||
| > - If the cluster is created manually instead of using terraform scripts then user can provide the `values` for above two variables as per his requirement, no need to match variables in `aws.tfvars`. | ||
| > - Verify domain DNS resolution is working | ||
| > - Ensure SSL certificate coverage for all subdomains | ||
| > | ||
| > **Version Management:** | ||
| > | ||
| > - **Chart Versions**: Update all Helm chart versions to latest compatible releases | ||
| > - **Database Branch**: Verify DB scripts branch matches your MOSIP deployment version | ||
| > - **Service Versions**: Ensure MOSIP service versions are compatible across all DSF files | ||
| > | ||
| > **Configuration Consistency:** | ||
| > | ||
| > - `<sandbox>` must match `cluster_name` in `terraform/implementations/aws/infra/aws.tfvars` | ||
| > - `sandbox.xyz.net` must match `cluster_env_domain` in `terraform/implementations/aws/infra/aws.tfvars` | ||
| > - These above variables MUST be identical or deployment will fail because the same domain is being mapped in the route-53 service in aws. | ||
| > - If the cluster is created manually instead of using terraform scripts then user can provide the `values` for above two variables as per his requirement, no need to match variables in `aws.tfvars`. | ||
| > - PostgreSQL settings must align with `enable_postgresql_setup` in Terraform configuration | ||
| > | ||
| > **Environment-Specific Updates:** | ||
| > | ||
| > - Resource limits and requests based on environment capacity | ||
| > - Storage class configurations for persistent volumes | ||
| > - Ingress controller and load balancer settings | ||
| > - Security context and RBAC configurations | ||
|
|
||
| #### Step 4b: Configure Repository Secrets for Helmsman | ||
|
|
||
| Configure the required secrets for Helmsman deployments in **Repository → Settings → Environments → `<branch-name>` → Secrets**: | ||
| **After updating all DSF files**, configure the required repository secrets for Helmsman deployments: |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check actual placeholder syntax in DSF files
grep -r '<sandbox>\|sandbox\.xyz\.net' Helmsman/dsf/ 2>/dev/null | head -20
grep -r '\${domain_name}\|\${env_name}\|\$CLUSTER_ID' Helmsman/dsf/ 2>/dev/null | head -20
# Check which placeholder style is actually used
echo "=== Checking for <sandbox> style ==="
rg -n '<sandbox>' Helmsman/dsf/ || echo "Not found"
echo "=== Checking for \${domain_name} style ==="
rg -n '\${domain_name}' Helmsman/dsf/ || echo "Not found"
echo "=== Checking for \$CLUSTER_ID ==="
rg -n '\$CLUSTER_ID' Helmsman/dsf/ || echo "Not found"Repository: mosip/infra
Length of output: 3103
Match the replacement instructions to the actual DSF tokens. The DSF files use ${domain_name} and $CLUSTER_ID, not <sandbox>/sandbox.xyz.net, so this guidance will send users to edit strings that do not exist.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` around lines 920 - 1195, The DSF setup guidance uses placeholder
names that do not match the actual tokens in the DSF files, which will confuse
users. Update the README section around the DSF configuration steps to reference
the real variables used in the YAML, especially ${domain_name} and $CLUSTER_ID,
instead of <sandbox> or sandbox.xyz.net. Make sure the instructions for
prereq-dsf.yaml, external-dsf.yaml, mosip-dsf.yaml, esignet-dsf.yaml, and
testrigs-dsf.yaml consistently point to the actual keys and placeholders present
in those files.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reverts #250
Summary by CodeRabbit