Skip to content

Noam/core 5674 cli incloud deploy uses ingestion key custom key name#319

Merged
noamApps merged 5 commits intomainfrom
noam/core-5674-cli-incloud-deploy-uses-ingestion-key-custom-key-name
Jul 24, 2025
Merged

Noam/core 5674 cli incloud deploy uses ingestion key custom key name#319
noamApps merged 5 commits intomainfrom
noam/core-5674-cli-incloud-deploy-uses-ingestion-key-custom-key-name

Conversation

@noamApps
Copy link
Collaborator

@noamApps noamApps commented Jul 14, 2025

Summary by CodeRabbit

  • New Features

    • Enhanced deployment to automatically fetch or create a sensor ingestion key when needed.
    • Added a unified command to create or retrieve ingestion keys with optional custom naming.
    • Improved backend selection with explicit handling of "InCloud" status and multiple backends.
  • Refactor

    • Consolidated ingestion key management into a single API client method.
    • Updated backend selection to use tenant UUID and return detailed backend info.
    • Simplified deployment flow by refining component configuration and API key retrieval logic.
  • Documentation

    • Updated command examples to include optional ingestion key name argument.

noamApps added 2 commits July 14, 2025 19:45
- Introduced a new configuration file `incloud.yaml` for global settings.
- Enhanced the `runDeployCmd` function to support fetching an ingestion key if no API key is provided, with a fallback to the regular API key.
- Updated `selectBackendName` to accept a tenant UUID instead of a tenant object.
- Refactored the ingestion key command to utilize the new API client for key management, allowing for custom names for ingestion keys.
@coderabbitai
Copy link

coderabbitai bot commented Jul 14, 2025

Walkthrough

The deployment and ingestion key logic was refactored to unify API key retrieval via a new helper that tries multiple sources, including a new sensor ingestion key fetched through an API client method. Backend name selection was updated to use tenant UUID and return InCloud status. The ingestion key command now uses the API client’s new method.

Changes

File(s) Change Summary
cmd/deploy.go Refactored API key retrieval to try multiple sources including ingestion key; added helpers for backend config and ingestion key fetching.
cmd/ingestion_key.go Replaced manual SDK ingestion key logic with API client’s GetOrCreateIngestionKey call; updated backend name selection.
cmd/get_datasources_api_key.go Updated call to selectBackendName to use tenant UUID and handle new return signature.
cmd/login.go Modified selectBackendName to accept tenant UUID and deployFlow flag; returns backend name, InCloud bool, and error.
pkg/api/client.go Added GetOrCreateIngestionKey method to retrieve or create ingestion keys using SDK client internally.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant CLI
    participant APIClient
    participant SDKClient

    User->>CLI: Run deploy command
    CLI->>APIClient: selectBackendName(tenantUUID, deployFlow)
    APIClient-->>CLI: backendName, isInCloud
    CLI->>APIClient: GetOrCreateIngestionKey(tenantUUID, backendName, ingestionKeyType, customName)
    APIClient->>SDKClient: ListIngestionKeys(filter by name)
    alt Key exists
        SDKClient-->>APIClient: Existing key
        APIClient-->>CLI: Ingestion key
    else No key
        APIClient->>SDKClient: CreateIngestionKey(name, type)
        SDKClient-->>APIClient: New key
        APIClient-->>CLI: Ingestion key
    end
    CLI->>CLI: Continue deployment with resolved API key
Loading
sequenceDiagram
    participant User
    participant CLI
    participant APIClient

    User->>CLI: Run get-ingestion-key command
    CLI->>APIClient: GetOrCreateIngestionKey(tenantUUID, backendName, ingestionKeyType, customName)
    APIClient-->>CLI: Ingestion key (existing or new)
    CLI-->>User: Output key
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~45 minutes

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b401598 and 1e4da6b.

📒 Files selected for processing (3)
  • cmd/deploy.go (4 hunks)
  • cmd/login.go (2 hunks)
  • pkg/api/client.go (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
  • pkg/api/client.go
  • cmd/login.go
  • cmd/deploy.go
⏰ 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). (1)
  • GitHub Check: Analyze (go)
✨ Finishing Touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch noam/core-5674-cli-incloud-deploy-uses-ingestion-key-custom-key-name

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Explain this complex logic.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai explain this code block.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and explain its main purpose.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai generate unit tests to generate unit tests for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (4)
cmd/deploy.go (2)

163-180: Smart fallback logic but improve error messaging

The ingestion-key-first approach with fallback is well-designed. However, the error message on line 169 should be more consistent with CLI conventions.

-			ui.GlobalWriter.PrintlnWithPrefixln("ingestion key not found, falling back to regular API key")
+			ui.GlobalWriter.PrintlnWithPrefixln("Ingestion key not found, falling back to regular API key")

693-710: Consider Auth0 token reuse optimization

The function loads Auth0 token again, but the caller likely already has one. Consider passing the token as parameter to avoid redundant operations.

-func fetchIngestionKey(tenantUUID, backendName string) (string, error) {
+func fetchIngestionKey(tenantUUID, backendName string, auth0Token *auth.Auth0Token) (string, error) {
 	var err error
 
-	var auth0Token *auth.Auth0Token
-	if auth0Token, err = auth.LoadAuth0Token(); err != nil {
-		return "", err
-	}
-
 	apiClient := api.NewClient(auth0Token)
cmd/ingestion_key.go (1)

36-55: Excellent refactoring - much cleaner

The new API client approach eliminates manual SDK operations and improves readability. The argument parsing is functional but could be more robust.

Consider using more descriptive error messages:

-		return fmt.Errorf("ingestion key type is required")
+		return fmt.Errorf("ingestion key type is required: specify one of [sensor|rum|thirdParty]")
pkg/api/client.go (1)

210-260: Well-structured method but consider optimization

The method encapsulates ingestion key logic effectively. However, loading Auth0 token again is redundant since the client was created with a token.

Consider accessing the token from the client's transport:

-// GetOrCreateIngestionKey retrieves an existing CLI ingestion key or creates a new one
-func (client *Client) GetOrCreateIngestionKey(tenantUUID, backendName, ingestionKeyType, customName string) (string, error) {
-	// Create SDK client
-	auth0Token, err := auth.LoadAuth0Token()
-	if err != nil {
-		return "", err
-	}
+func (client *Client) GetOrCreateIngestionKey(tenantUUID, backendName, ingestionKeyType, customName string) (string, error) {
+	// Extract token from client transport
+	transport := client.httpClient.Transport.(*TransportWithAuth0Token)
+	auth0Token := transport.auth0Token
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 855fa49 and 22b25b4.

📒 Files selected for processing (5)
  • cmd/deploy.go (3 hunks)
  • cmd/get_datasources_api_key.go (1 hunks)
  • cmd/ingestion_key.go (2 hunks)
  • cmd/login.go (2 hunks)
  • pkg/api/client.go (2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
cmd/deploy.go (5)
cmd/root.go (1)
  • API_KEY_FLAG (29-29)
pkg/ui/writer.go (1)
  • GlobalWriter (37-37)
pkg/auth/api_key.go (1)
  • ApiKey (13-15)
pkg/auth/auth0.go (2)
  • Auth0Token (20-25)
  • LoadAuth0Token (39-59)
pkg/api/client.go (1)
  • NewClient (41-55)
cmd/ingestion_key.go (1)
pkg/api/client.go (1)
  • NewClient (41-55)
pkg/api/client.go (3)
pkg/auth/client.go (1)
  • Client (21-27)
pkg/auth/auth0.go (1)
  • LoadAuth0Token (39-59)
pkg/client/client.go (1)
  • NewDefaultClient (63-66)
⏰ 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: goreleaser
  • GitHub Check: Analyze (go)
🔇 Additional comments (8)
cmd/get_datasources_api_key.go (1)

22-22: LGTM - Consistent with refactoring pattern

Change aligns with updated selectBackendName signature across codebase.

cmd/login.go (2)

135-135: Good interface improvement

Function now takes only what it needs (UUID) instead of entire tenant object.


145-145: Consistent with signature change

Backend list call properly uses tenant UUID parameter.

cmd/deploy.go (1)

158-161: Good refactoring - backend name selection moved earlier

Moving backend selection before API key fetching enables reuse in ingestion key logic.

cmd/ingestion_key.go (2)

18-18: Updated example reflects new optional parameter

Good documentation update for the new custom name functionality.


32-32: Consistent with refactoring pattern

Properly uses tenant UUID with updated selectBackendName signature.

pkg/api/client.go (2)

4-5: New imports support ingestion key functionality

Required imports for context, string manipulation, and SDK client operations.

Also applies to: 9-9, 11-12, 14-14


17-17: Reasonable naming convention

The constant provides consistent naming for CLI-generated keys.

Copy link
Contributor

@AvitalTamir AvitalTamir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@noamApps this looks good to me - except the valid CodeRabbit comment there, I don't know if I fully understand the context - but it seems like the backendName variable is being repurposed and is expected to get 2 different values during this process?

If it is for a different purpose and is expected to get a completely new value - why not rename the first one to something else like backendNameFromTenant (don't know if this makes sense)?

If it is not expected to get a new value, why overwrite it?

If there's a chance it's empty - why no assign it to either selectBackendName(tenantUUID) or clusterName to begin with?

Other than that looks cool! clarify or fix and I'll approve 🙏

- Updated `selectBackendName` to return a boolean indicating if the backend is in the cloud and modified its signature to accept a deploy flow parameter.
- Refactored `runDeployCmd` to streamline API key retrieval, utilizing a new `getApiKey` function for improved clarity and maintainability.
- Introduced `getComponentsConfiguration` to encapsulate logic for determining agent and backend configurations based on chart values.
- Adjusted related commands to align with the updated backend selection logic.
Copy link
Contributor

@AvitalTamir AvitalTamir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved with comment, take it or leave it

@AvitalTamir
Copy link
Contributor

AvitalTamir commented Jul 23, 2025 via email

- Split `getComponentsConfiguration` into `getAgentComponentsConfiguration` and `getBackendComponentsConfiguration` for clearer separation of concerns.
- Updated `runDeployCmd` to utilize the new configuration functions, enhancing readability and maintainability.
- Simplified the logic for determining agent and backend configurations based on chart values.
@noamApps noamApps merged commit 671e861 into main Jul 24, 2025
5 checks passed
@noamApps noamApps deleted the noam/core-5674-cli-incloud-deploy-uses-ingestion-key-custom-key-name branch July 24, 2025 16:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants