docs: add logs, docs, functions delete, and schedules commands #16#22
docs: add logs, docs, functions delete, and schedules commands #16#22evergreenx wants to merge 1 commit intoInsForge:mainfrom
Conversation
WalkthroughThe PR adds documentation for four new CLI commands to the README: logs (fetch backend container logs), docs (browse SDK documentation), functions delete (delete edge functions), and schedules (manage cron jobs). These are standalone additions with usage examples; no existing functionality is altered. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip Migrating from UI to YAML configuration.Use the |
|
Closes #16 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Around line 148-154: Update the README section for the insforge docs command
to document its optional positional arguments and examples: state that the
command accepts optional [feature] and [language] arguments, list supported
features (db, storage, functions, auth, ai, realtime) and supported languages
(typescript, swift, kotlin, rest-api), and add several usage examples
demonstrating both listing all docs (insforge docs) and filtered invocations
(e.g., insforge docs db typescript, insforge docs auth swift, insforge docs
storage rest-api) so users understand the command's flexibility.
- Around line 140-146: Update the README entry for the insforge logs command to
document the allowed <source> values and the --limit option and add usage
examples: state that <source> must be one of insforge.logs, postgREST.logs,
postgres.logs, or function.logs, document that --limit controls how many entries
are returned (default 20), and include at least two concrete examples such as
"insforge logs insforge.logs" and "insforge logs postgres.logs --limit 50" so
users can run the command without invoking --help.
- Around line 436-442: The README's schedules section only documents `insforge
schedules list`; add full documentation entries for the remaining subcommands:
`insforge schedules get`, `insforge schedules create`, `insforge schedules
update`, `insforge schedules delete`, and `insforge schedules logs`. For each
subcommand follow the same format as other command groups: a short description,
required flags/arguments (e.g., schedule ID or name), and a usage example (bash
block) showing typical options (for create/update include spec/cron/target
flags, for logs include --follow/--tail or --since as applicable). Ensure the
headings match the existing style (e.g., "Schedules — `insforge schedules`"
subsections) and mirror phrasing and examples used in `db`, `functions`,
`storage` sections for consistency.
| #### `insforge logs` | ||
|
|
||
| Fetch backend container logs. | ||
|
|
||
| ```bash | ||
| insforge logs <source> | ||
| ``` |
There was a problem hiding this comment.
Incomplete documentation for insforge logs command.
The documentation is missing critical information that users need to use this command:
- Valid source values: According to the implementation,
<source>must be one of:insforge.logs,postgREST.logs,postgres.logs, orfunction.logs - The
--limitoption: Users can specify the number of log entries to return (default: 20) - Usage examples: No examples showing actual source values
Without this information, users cannot use the command without running insforge logs --help first.
📝 Suggested improvement
#### `insforge logs`
-Fetch backend container logs.
+Fetch backend container logs for a specific source.
```bash
-insforge logs <source>
+# Valid sources: insforge.logs | postgREST.logs | postgres.logs | function.logs
+insforge logs insforge.logs
+insforge logs postgres.logs --limit 50</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **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.
```suggestion
#### `insforge logs`
Fetch backend container logs for a specific source.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 140 - 146, Update the README entry for the insforge
logs command to document the allowed <source> values and the --limit option and
add usage examples: state that <source> must be one of insforge.logs,
postgREST.logs, postgres.logs, or function.logs, document that --limit controls
how many entries are returned (default 20), and include at least two concrete
examples such as "insforge logs insforge.logs" and "insforge logs postgres.logs
--limit 50" so users can run the command without invoking --help.
| #### `insforge docs` | ||
|
|
||
| Browse InsForge SDK documentation. | ||
|
|
||
| ```bash | ||
| insforge docs | ||
| ``` |
There was a problem hiding this comment.
Incomplete documentation for insforge docs command.
The documentation is missing important information about the command's capabilities:
- Optional arguments: The command accepts
[feature]and[language]arguments to filter documentation - Available options: Features include
db,storage,functions,auth,ai,realtime; languages includetypescript,swift,kotlin,rest-api - Usage examples: The implementation includes rich examples (e.g.,
insforge docs db typescript,insforge docs auth swift) that would help users understand the command's flexibility
📝 Suggested improvement
#### `insforge docs`
Browse InsForge SDK documentation.
```bash
+# List all available docs
insforge docs
+
+# View feature-specific docs
+insforge docs db typescript
+insforge docs auth swift
+insforge docs storage rest-api</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **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.
```suggestion
#### `insforge docs`
Browse InsForge SDK documentation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 148 - 154, Update the README section for the insforge
docs command to document its optional positional arguments and examples: state
that the command accepts optional [feature] and [language] arguments, list
supported features (db, storage, functions, auth, ai, realtime) and supported
languages (typescript, swift, kotlin, rest-api), and add several usage examples
demonstrating both listing all docs (insforge docs) and filtered invocations
(e.g., insforge docs db typescript, insforge docs auth swift, insforge docs
storage rest-api) so users understand the command's flexibility.
| ### Schedules — `insforge schedules` | ||
|
|
||
| Manage scheduled tasks (cron jobs). | ||
|
|
||
| ```bash | ||
| insforge schedules list | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: List all schedules subcommands registered in the CLI
ast-grep --pattern 'registerSchedules$_Command(schedulesCmd)'Repository: InsForge/CLI
Length of output: 38
🏁 Script executed:
# Find files related to schedules commands
fd -t f "schedule" --case-sensitiveRepository: InsForge/CLI
Length of output: 38
🏁 Script executed:
# Read the README section in question (lines 430-450 to get context)
sed -n '430,450p' README.mdRepository: InsForge/CLI
Length of output: 396
🏁 Script executed:
# Search for schedules command registration or implementation
rg -i "schedules" --max-count=20Repository: InsForge/CLI
Length of output: 3798
🏁 Script executed:
# Check the db command section in README
sed -n '/^## Database Queries/,/^##/p' README.md | head -50Repository: InsForge/CLI
Length of output: 38
🏁 Script executed:
# Check the functions command section in README
sed -n '/^### Functions/,/^###/p' README.md | head -80Repository: InsForge/CLI
Length of output: 124
🏁 Script executed:
# Look at storage section
sed -n '/^### Storage/,/^###/p' README.md | head -50Repository: InsForge/CLI
Length of output: 121
🏁 Script executed:
# Get a more comprehensive view of the functions section
rg -A 150 "^### Functions" README.md | head -200Repository: InsForge/CLI
Length of output: 3186
🏁 Script executed:
# Get all command group headers to understand structure
rg "^### " README.mdRepository: InsForge/CLI
Length of output: 343
🏁 Script executed:
# Check what subcommands are documented for functions, db, storage, deployments
rg "^#### \`insforge" README.mdRepository: InsForge/CLI
Length of output: 1272
Incomplete documentation for insforge schedules command group.
The schedules command group has 6 subcommands (list, get, create, update, delete, logs), but the README only documents the list subcommand.
This is inconsistent with how other command groups are documented. The db, functions, storage, deployments, and secrets sections all document each of their subcommands with descriptions and examples.
Add documentation for the missing get, create, update, delete, and logs subcommands.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` around lines 436 - 442, The README's schedules section only
documents `insforge schedules list`; add full documentation entries for the
remaining subcommands: `insforge schedules get`, `insforge schedules create`,
`insforge schedules update`, `insforge schedules delete`, and `insforge
schedules logs`. For each subcommand follow the same format as other command
groups: a short description, required flags/arguments (e.g., schedule ID or
name), and a usage example (bash block) showing typical options (for
create/update include spec/cron/target flags, for logs include --follow/--tail
or --since as applicable). Ensure the headings match the existing style (e.g.,
"Schedules — `insforge schedules`" subsections) and mirror phrasing and examples
used in `db`, `functions`, `storage` sections for consistency.
jwfing
left a comment
jwfing
left a comment
There was a problem hiding this comment.
I think the comments of coderabbit are reasonable.
2 participants
Summary by CodeRabbit