Docker setup in Setup Script #3187
Conversation
WalkthroughThe pull request introduces significant enhancements to the setup process for Talawa Admin, focusing on improving Docker configuration, port management, and environment variable handling. The changes involve creating modular functions for different setup tasks, such as Docker option selection, port configuration, and Talawa API URL setup. The implementation emphasizes error handling, user interaction, and flexibility in the installation process, making it more robust and user-friendly. Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Our Pull Request Approval ProcessThanks for contributing! Testing Your CodeRemember, your PRs won't be reviewed until these criteria are met:
Our policies make our code better. ReviewersDo not assign reviewers. Our Queue Monitors will review your PR and assign them.
Reviewing Your CodeYour reviewer(s) will have the following roles:
CONTRIBUTING.mdRead our CONTRIBUTING.md file. Most importantly:
Other
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (14)
setup.ts (2)
11-42: Consider clarifying the user prompt for reCAPTCHA.
Users might be unsure where to obtain a valid site key. Training them to visit official reCAPTCHA admin pages or project docs can help.
Line range hint
44-57: Use consistent environment variable naming.
"ALLOW_LOGS" might conflict with or confuse other environment variables. Consider a more descriptive naming convention, such as "TALAWA_ADMIN_LOG_ERRORS."- updateEnvFile('ALLOW_LOGS', 'YES'); + updateEnvFile('TALAWA_ADMIN_LOG_ERRORS', 'YES');src/setup/askForDocker/askForDocker.ts (2)
5-10: Replace mock implementation with real checks for production.
checkConnectionis marked as a mock. In a production setup, consider implementing an actual connectivity check (e.g., health-check endpoint).
32-99: Handle partial 'localhost' matches carefully.
Lines 83-94 replace'localhost'with'host.docker.internal'. If'localhost'appears elsewhere in the URL (e.g., path, querystrings), it might cause unexpected rewriting. Consider stricter URL parsing or user disclaimers.src/setup/updateEnvFile/updateEnvFile.ts (1)
3-19: Check for potential key collisions or partial matches.
Your regex pattern is mostly robust (^KEY=.*$), but collisions might occur if environment keys share name prefixes. This is unlikely but worth noting in larger codebases.src/setup/askAndUpdatePort/askAndUpdatePort.ts (1)
5-23: Consider verifying port availability.
This logic ensures the port is in the valid range but doesn’t verify whether it’s free. For improved UX, you may probe the port or warn the user if it’s already occupied.src/setup/askAndSetDockerOption/askAndSetDockerOption.ts (1)
5-33: Allow customization of Docker container names.
The container name is hard-coded to "talawa-admin." Letting users override it could improve flexibility in multi-container setups.- const DOCKER_NAME = 'talawa-admin'; + const { dockerContainerName } = await inquirer.prompt({ + type: 'input', + name: 'dockerContainerName', + message: 'Enter your preferred Docker container name:', + default: 'talawa-admin', + }); + const DOCKER_NAME = dockerContainerName;src/setup/askAndUpdatePort/askForUpdatePort.spec.ts (2)
16-28: Ensure custom port coverageYou're testing a valid port scenario here. It would be beneficial to include an additional assertion to confirm that the function returns or logs a success message indicating the port update was completed. This keeps validations consistent and improves test clarity regarding user-facing feedback.
it('should update the port when user confirms and provides a valid port', async () => { // ... await askAndUpdatePort(); + // Additional assertion for user feedback or returned result + // e.g., expect(console.log).toHaveBeenCalledWith('Port updated to 3000'); expect(updateEnvFile).toHaveBeenCalledWith('PORT', '3000'); });
43-54: Strengthen negative test coverageThe invalid port test is excellent, but you may want to test more boundary conditions (e.g., exactly 1024 and 65535 in this file) to ensure robust coverage. Although these edge cases exist in another file, duplicating them here ensures this function’s custom port validation is tested end-to-end without relying on
askForCustomPorttests alone.src/setup/askAndSetDockerOption/askAndSetDockerOption.spec.ts (2)
29-39: Validate environment file synergy in Docker scenarioAfter setting
USE_DOCKERandDOCKER_PORT, ensure you validate final.envcontents or the returned result. This helps confirm that the flow from user input -> environment variables is integrated properly.await askAndSetDockerOption(); expect(updateEnvFile).toHaveBeenCalledWith('USE_DOCKER', 'YES'); expect(updateEnvFile).toHaveBeenCalledWith('DOCKER_PORT', 8080); +// Potentially read the .env content or confirm user feedback: +// const envContent = fs.readFileSync('.env', 'utf8'); +// expect(envContent).toContain('DOCKER_PORT=8080');
51-60: Distinguish between user cancellation and errorsWhen
askForDockerfails, the test throws "Docker error" to confirm error-handling. Consider differentiating expected user-initiated exit vs genuine errors. If there's a scenario where a user aborts the Docker setup, capturing that distinctly clarifies the user journey in your tests.src/setup/askForDocker/askForDocker.spec.ts (2)
17-24: Add boundary-checking test for user-provided portWhile you test various port values, it's helpful to add a single combined test verifying both numeric input and range in one go. This could reduce duplication, making sure all numeric validations and range checks pass in a consolidated scenario.
26-37: Improve error message clarityThe test's thrown error message is explicit, but consider adding a recommended solution or instructions in the error string (e.g., “Please enter a valid port number...Did you type a letter accidentally?”). This guides users better if they mistakenly enter non-numeric or invalid inputs.
src/setup/updateEnvFile/updateEnvFile.spec.ts (1)
36-48: Optimize read vs append operationsWhen appending a new key, you first read the existing file content. If the file is large, re-checking content before each key append might be costly. If performance matters for large
.envfiles, consider buffering or caching in future enhancements. For small.envfiles, this is likely negligible.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
setup.ts(2 hunks)src/setup/askAndSetDockerOption/askAndSetDockerOption.spec.ts(1 hunks)src/setup/askAndSetDockerOption/askAndSetDockerOption.ts(1 hunks)src/setup/askAndUpdatePort/askAndUpdatePort.ts(1 hunks)src/setup/askAndUpdatePort/askForUpdatePort.spec.ts(1 hunks)src/setup/askForDocker/askForDocker.spec.ts(1 hunks)src/setup/askForDocker/askForDocker.ts(1 hunks)src/setup/updateEnvFile/updateEnvFile.spec.ts(1 hunks)src/setup/updateEnvFile/updateEnvFile.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Test Application
- GitHub Check: Analyse Code With CodeQL (javascript)
🔇 Additional comments (5)
setup.ts (2)
6-9: Great addition of modular helpers!
Importing these new functions and modules improves the maintainability and clarity of the setup script.
60-85: Confirm test coverage for Docker vs. non-Docker paths.
You have a clear, structured main function with separate branches for Docker and non-Docker usage. However, no tests were added for this logic. Ensure robust coverage is in place to avoid regressions when togglingUSE_DOCKER.src/setup/askForDocker/askForDocker.ts (2)
1-3: Imports look good.
These imports correctly separate concerns and keep the code organized.
11-30: Validate combined usage with Docker environment.
TheaskForDockerfunction ensures valid port input. Confirm that the chosen port doesn't conflict with other services.src/setup/updateEnvFile/updateEnvFile.spec.ts (1)
64-73: Verify file-creation logic furtherCurrently, the test ensures that
appendFileSyncis called if the file doesn’t exist. To reinforce reliability, test the scenario where.envis present but empty vs nonexistent. Confirm it correctly handles permissions or partial writes if the file is locked or read-only to ensure robust error handling.
rishav-jha-mech
added
the
ignore-sensitive-files-pr
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/setup/validateRecaptcha/validateRecaptcha.spec.ts (1)
Line range hint
10-21: Solid Coverage of Invalid Cases, Consider Testing Empty String or NullThe tests for special characters, incorrect length, and spaces collectively broaden coverage for potential invalid cases. However, it might be beneficial to also test scenarios involving empty string input or
null/undefinedto ensure the function gracefully handles those edge cases.Apply the following snippet to add an extra test case:
+ it('should return false for an empty string', () => { + const invalidRecaptcha = ''; + expect(validateRecaptcha(invalidRecaptcha)).toBe(false); + });
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/setup/validateRecaptcha/validateRecaptcha.spec.ts(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Test Application
🔇 Additional comments (2)
src/setup/validateRecaptcha/validateRecaptcha.spec.ts (2)
1-2: Imports and Testing Framework Setup Look GoodImporting from Vitest is correct, and referencing the local
validateRecaptchamodule aligns well with best practices for modular testing.
Line range hint
4-9: Comprehensive Positive Case TestingThe test for a valid Recaptcha string is straightforward and confirms that the function returns
trueas expected. This ensures the core functionality works for the happy path.
palisadoes
merged commit 2f68501
into
PalisadoesFoundation:develop-postgres
What kind of change does this PR introduce?
feature
Issue Number:
Fixes #2446
Previous PR:- #2615
Did you add tests for your changes?
No
Snapshots/Videos:
Screen.Recording.2025-01-06.001224.mp4
If relevant, did you update the documentation?
Summary
Does this PR introduce a breaking change?
Other information
Have you read the contributing guide?
Yes
Summary by CodeRabbit
Release Notes
New Features
Improvements
Bug Fixes