chore: specifies deploymentEnv in helm files

[stalniy]

Why

Because DEPLOYMENT_ENV is a deployment concern and we deploy using helm

Summary by CodeRabbit

• Chores
  • Updated Helm configuration files to include deployment environment designations (production/staging) across console APIs, web services, indexer, and provider proxy deployments.
  • Expanded and standardized hostname configurations for console API services.
  • Removed deprecated hostname entries for provider proxy services.

[coderabbitai]

Walkthrough

Helm configuration values files across multiple services (console-api, console-web, indexer, provider-proxy) are updated to include a new top-level deploymentEnv key set to either production or staging depending on the environment. Additionally, hostNames entries are removed from two provider-proxy production files for backward compatibility.

Changes

Cohort / File(s)	Summary
console-api .helm/console-api-prod-mainnet-values.yaml, .helm/console-api-prod-sandbox-values.yaml, .helm/console-api-staging-mainnet-values.yaml, .helm/console-api-staging-sandbox-values.yaml, .helm/console-api-staging-testnet-values.yaml	Added deploymentEnv key with value production or staging based on environment; prod-mainnet also expanded hostNames to include three domain entries.
console-web .helm/console-web-prod-values.yaml, .helm/console-web-staging-values.yaml, .helm/console-web-testnet-staging-values.yaml	Added deploymentEnv key with value production or staging based on environment.
indexer .helm/indexer-prod-mainnet-values.yaml, .helm/indexer-prod-sandbox-values.yaml, .helm/indexer-prod-testnet-values.yaml, .helm/indexer-staging-testnet-values.yaml	Added deploymentEnv key with value production or staging based on environment.
provider-proxy .helm/provider-proxy-prod-mainnet-values.yaml, .helm/provider-proxy-prod-sandbox-values.yaml, .helm/provider-proxy-staging-mainnet-values.yaml, .helm/provider-proxy-staging-sandbox-values.yaml, .helm/provider-proxy-staging-testnet-values.yaml	Added deploymentEnv key with value production or staging based on environment; removed hostNames blocks from prod-mainnet and staging-mainnet for backward compatibility.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• This change applies a consistent, repetitive pattern across 17 Helm configuration files with minimal variation in logic or structure
• Verify that deploymentEnv values match the expected environment (production/staging) for each file
• Confirm that hostNames removals from provider-proxy files (mainnet variants) do not break existing deployments or reverse required functionality

Possibly related PRs

• chore(release): adds proper configurations for testnet #2079: Modifies indexer-prod-testnet-values.yaml with environment-specific chain and nodePort configurations alongside deploymentEnv additions
• chore: add nodePort to deploy-k8s #1426: Updates indexer production files (mainnet/sandbox) with nodePort and chain entries in similar configuration patterns
• fix: separate deployments for each provider proxy env/network #2211: Modifies provider-proxy Helm values with hostNames removal and environment-specific changes across prod and staging files

Poem

🐰 Helm charts now bloom with purpose clear,
Each deploymentEnv marked by tier,
Production, staging, each its name,
Configuration made tame!
Seventeen files, one noble quest,
Organizing clusters at their best. 🌿

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title 'chore: specifies deploymentEnv in helm files' accurately and concisely describes the main change: adding deploymentEnv configuration to multiple Helm values files across different environments.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore/helm-deployment-env

---

📜 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 e58863a and c2d2a4b.

📒 Files selected for processing (17)

• .helm/console-api-prod-mainnet-values.yaml (1 hunks)
• .helm/console-api-prod-sandbox-values.yaml (1 hunks)
• .helm/console-api-staging-mainnet-values.yaml (1 hunks)
• .helm/console-api-staging-sandbox-values.yaml (1 hunks)
• .helm/console-api-staging-testnet-values.yaml (1 hunks)
• .helm/console-web-prod-values.yaml (1 hunks)
• .helm/console-web-staging-values.yaml (1 hunks)
• .helm/console-web-testnet-staging-values.yaml (1 hunks)
• .helm/indexer-prod-mainnet-values.yaml (1 hunks)
• .helm/indexer-prod-sandbox-values.yaml (1 hunks)
• .helm/indexer-prod-testnet-values.yaml (1 hunks)
• .helm/indexer-staging-testnet-values.yaml (1 hunks)
• .helm/provider-proxy-prod-mainnet-values.yaml (1 hunks)
• .helm/provider-proxy-prod-sandbox-values.yaml (1 hunks)
• .helm/provider-proxy-staging-mainnet-values.yaml (1 hunks)
• .helm/provider-proxy-staging-sandbox-values.yaml (1 hunks)
• .helm/provider-proxy-staging-testnet-values.yaml (1 hunks)

🧰 Additional context used

🧠 Learnings (4)

📓 Common learnings

Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, akashnetwork/env-loader is used at the top of next.config.js files to automatically load environment variables from env/.env files into process.env. SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env and are loaded this way, while only SENTRY_AUTH_TOKEN is handled as a GitHub secret in workflows.

📚 Learning: 2025-08-12T13:52:38.708Z

Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, akashnetwork/env-loader is used at the top of next.config.js files to automatically load environment variables from env/.env files into process.env. SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env and are loaded this way, while only SENTRY_AUTH_TOKEN is handled as a GitHub secret in workflows.

Applied to files:

• .helm/console-api-prod-sandbox-values.yaml
• .helm/console-api-staging-sandbox-values.yaml
• .helm/console-web-staging-values.yaml
• .helm/console-api-staging-testnet-values.yaml
• .helm/provider-proxy-staging-mainnet-values.yaml
• .helm/console-api-staging-mainnet-values.yaml
• .helm/provider-proxy-prod-mainnet-values.yaml
• .helm/console-web-testnet-staging-values.yaml
• .helm/console-web-prod-values.yaml
• .helm/console-api-prod-mainnet-values.yaml

📚 Learning: 2025-08-12T13:52:38.708Z

Learnt from: stalniy
Repo: akash-network/console PR: 1800
File: apps/deploy-web/next.config.js:163-165
Timestamp: 2025-08-12T13:52:38.708Z
Learning: In the Akash Console project, SENTRY_ORG and SENTRY_PROJECT are stored as public configuration values in apps/deploy-web/env/.env file and loaded by akashnetwork/env-loader, not as GitHub secrets. Only SENTRY_AUTH_TOKEN should be handled as a secret.

Applied to files:

• .helm/console-web-staging-values.yaml
• .helm/console-web-testnet-staging-values.yaml
• .helm/console-web-prod-values.yaml
• .helm/console-api-prod-mainnet-values.yaml

📚 Learning: 2025-06-10T14:19:14.122Z

Learnt from: ygrishajev
Repo: akash-network/console PR: 1461
File: apps/notifications/src/modules/alert/services/deployment-alert/deployment-alert.service.ts:194-197
Timestamp: 2025-06-10T14:19:14.122Z
Learning: The alert.CONSOLE_WEB_URL environment variable in the notifications app is controlled and configured by the Akash team, reducing XSS concerns for HTML link generation in alert messages.

Applied to files:

• .helm/console-web-prod-values.yaml

⏰ 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 (javascript-typescript)

🔇 Additional comments (10)

.helm/console-web-testnet-staging-values.yaml (1)

1-1: Helm values deploymentEnv is correctly configured and consistent with architecture.

The configuration is properly set up:

1. Application-side consumption verified: The DEPLOYMENT_ENV environment variable is actively consumed by env-loader (packages/env-loader/src/index.js), which dynamically loads environment-specific config files based on this value. It's also used in feature flags service and API key authentication.

2. Consistent across services: The deploymentEnv: staging value matches the pattern used in all other services (console-api, indexer, provider-proxy), correctly paired with chain: testnet.

3. Docker/build integration: The build system (Dockerfile.nextjs, docker-compose.build.yml) properly passes DEPLOYMENT_ENV through the build pipeline.

The .helm/ directory contains only values files (no templates), which is standard for monorepos using external or shared Helm charts. The mapping from Helm values to container environment variables is handled by the external chart deployment system, not present in this repository.

No issues found in the change.

.helm/indexer-prod-mainnet-values.yaml (1)

1-4: LGTM!

The deploymentEnv: production addition follows the consistent pattern across prod Helm values files and the YAML structure is correct.

.helm/console-web-staging-values.yaml (1)

1-3: LGTM!

The deploymentEnv: staging is correctly positioned and environment designation is appropriate for the staging web console.

.helm/provider-proxy-staging-sandbox-values.yaml (1)

1-3: LGTM!

The deploymentEnv: staging is correctly added for the staging sandbox provider proxy configuration.

.helm/indexer-prod-testnet-values.yaml (1)

1-4: LGTM!

The deploymentEnv: production is correctly assigned to the production testnet indexer configuration.

.helm/provider-proxy-staging-mainnet-values.yaml (1)

1-3: Verify hostNames removal impact.

While the deploymentEnv: staging addition is correct, the AI summary mentions hostNames removal for "backward compatibility." Removing configuration entries is typically a breaking change, not backward compatible. Please verify:

• What hostNames entries were removed?
• Why is this removal necessary?
• Will this cause any service discovery or DNS resolution issues?

.helm/indexer-prod-sandbox-values.yaml (1)

1-4: LGTM!

The deploymentEnv: production is correctly added for the production sandbox indexer configuration.

.helm/provider-proxy-staging-testnet-values.yaml (1)

1-3: LGTM!

The deploymentEnv: staging is correctly added for the staging testnet provider proxy configuration.

.helm/console-api-prod-mainnet-values.yaml (2)

1-7: LGTM with caution on hostNames consistency.

The deploymentEnv: production addition and hostNames expansion appear valid for the production mainnet console-api. However, note the inconsistency across the PR: while this file expands hostNames, other provider-proxy staging files remove them. Ensure the hostNames strategy is intentional and documented.

---

1-34: Confirm external Helm chart actually references deploymentEnv in templates.

The .helm/*-values.yaml files are correctly integrated—they're passed to the external Helm chart at akash/[app-name] during deployment. However, we cannot verify from this repository whether the external chart templates (in akash-network/helm-charts) actually use the deploymentEnv field.

To confirm the integration is complete, manually check the external Helm chart repository at https://akash-network.github.io/helm-charts (or its source at akash-network/helm-charts) to verify that chart templates reference .Values.deploymentEnv.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}