Cutom Docker Image Build and deplument via Helm

[sainikhilsamineni]

@dosu can we skip frontend react tests when building superset for a docker image as i have made a few changes ?

[dosubot[bot]]

You don't need to do anything special to skip frontend React tests when building a Superset Docker image. The default Docker build process only installs dependencies and builds frontend assets—it does not run tests by default. The npm scripts for testing (like npm run test or npm run cover) are separate and not triggered during the standard image build, so your custom changes won't force test execution unless you explicitly add those steps yourself. For reference, see the Dockerfile and package.json scripts.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[sainikhilsamineni]

@dosu then why am i getting these errors WARNING in ./src/components/Tooltip/index.tsx 22:0-42
115.1 export 'TooltipProps' (reexported as 'TooltipProps') was not found in 'antd-v5/lib/tooltip' (possible exports: __esModule, default)
115.1
115.1 WARNING in ./src/components/Tooltip/index.tsx 22:0-42
115.1 export 'TooltipPlacement' (reexported as 'TooltipPlacement') was not found in 'antd-v5/lib/tooltip' (possible exports: __esModule, default)
115.1
115.1 ERROR in ./plugins/plugin-chart-echarts/src/Timeseries/transformProps.ts:106:3
115.1 TS6133: 'getXAxisFormatter' is declared but its value is never read.
115.1 104 | getPercentFormatter,
115.1 105 | getTooltipTimeFormatter,
115.1 > 106 | getXAxisFormatter,
115.1 | ^^^^^^^^^^^^^^^^^
115.1 107 | getYAxisFormatter,
115.1 108 | } from '../utils/formatters';
115.1 109 |
115.1
115.1 ERROR in ./plugins/plugin-chart-echarts/src/Timeseries/transformProps.ts:193:5
115.1 TS6133: 'xAxisTimeFormat' is declared but its value is never read.
115.1 191 | xAxisSortSeries,
115.1 192 | xAxisSortSeriesAscending,
115.1 > 193 | xAxisTimeFormat,
115.1 | ^^^^^^^^^^^^^^^
115.1 194 | xAxisTitle,
115.1 195 | xAxisTitleMargin,
115.1 196 | yAxisBounds,
115.1
115.1 ERROR in ./src/dashboard/reducers/dashboardState.test.ts:37:38
115.1 TS2345: Argument of type '{ activeTabs: never[]; }' is not assignable to parameter of type '{ timezone: string; }'.
115.1 Object literal may only specify known properties, and 'activeTabs' does not exist in type '{ timezone: string; }'.
115.1 35 | const thunkAction = request(store.dispatch, store.getState);
115.1 36 |
115.1 > 37 | expect(dashboardStateReducer({ activeTabs: [] }, thunkAction)).toEqual({
115.1 | ^^^^^^^^^^
115.1 38 | activeTabs: ['tab1'],
115.1 39 | inactiveTabs: [],
115.1 40 | });
115.1
115.1 ERROR in ./src/dashboard/reducers/dashboardState.test.ts:45:33
115.1 TS2345: Argument of type '{ activeTabs: string[]; }' is not assignable to parameter of type '{ timezone: string; }'.
115.1 Object literal may only specify known properties, and 'activeTabs' does not exist in type '{ timezone: string; }'.
115.1 43 | const thunkAction2 = request2(store.dispatch, store.getState);
115.1 44 | expect(
115.1 > 45 | dashboardStateReducer({ activeTabs: ['tab1'] }, thunkAction2),
115.1 | ^^^^^^^^^^
115.1 46 | ).toEqual({ activeTabs: ['tab2'], inactiveTabs: [] });
115.1 47 | });
115.1 48 |
115.1
115.1 ERROR in ./src/dashboard/reducers/dashboardState.test.ts:67:11
115.1 TS2345: Argument of type '{ activeTabs: string[]; }' is not assignable to parameter of type '{ timezone: string; }'.
115.1 Object literal may only specify known properties, and 'activeTabs' does not exist in type '{ timezone: string; }'.
115.1 65 | let thunkAction = request(store.dispatch, store.getState);
115.1 66 | let result = dashboardStateReducer(
115.1 > 67 | { activeTabs: ['TAB-1', 'TAB-A', 'TAB-__a'] },
115.1 | ^^^^^^^^^^
115.1 68 | thunkAction,
115.1 69 | );
115.1 70 | expect(result).toEqual({
115.1
115.1 ERROR in ./src/dashboard/reducers/dashboardState.test.ts:128:31
115.1 TS2345: Argument of type '{ activeTabs: never[]; }' is not assignable to parameter of type '{ timezone: string; }'.
115.1 Object literal may only specify known properties, and 'activeTabs' does not exist in type '{ timezone: string; }'.
115.1 126 | it('SET_ACTIVE_TABS', () => {
115.1 127 | expect(
115.1 > 128 | dashboardStateReducer({ activeTabs: [] }, setActiveTabs(['tab1'])),
115.1 | ^^^^^^^^^^
115.1 129 | ).toEqual({ activeTabs: ['tab1'] });
115.1 130 | expect(
115.1 131 | dashboardStateReducer(
115.1
115.1 ERROR in ./src/dashboard/reducers/dashboardState.test.ts:132:11
115.1 TS2345: Argument of type '{ activeTabs: string[]; }' is not assignable to parameter of type '{ timezone: string; }'.
115.1 Object literal may only specify known properties, and 'activeTabs' does not exist in type '{ timezone: string; }'.
115.1 130 | expect(
115.1 131 | dashboardStateReducer(
115.1 > 132 | { activeTabs: ['tab1', 'tab2'] },
115.1 | ^^^^^^^^^^
115.1 133 | setActiveTabs(['tab3', 'tab4']),
115.1 134 | ),
115.1 135 | ).toEqual({ activeTabs: ['tab3', 'tab4'] });
115.1
115.1 ERROR in ./src/explore/components/controls/DateFilterControl/DateFilterLabel.tsx:141:37
115.1 TS7006: Parameter 'timeRange' implicitly has an 'any' type.
115.1 139 | ; 115.1 140 | 115.1 > 141 | function convertTimeRangeToTimezone(timeRange, timezone) { 115.1 | ^^^^^^^^^ 115.1 142 | // Example: "2025-07-23T05:59:49 ≤ col < 2025-07-23T06:05:49" 115.1 143 | // You may need to adjust this regex for your actual format 115.1 144 | if (!timeRange || !timezone) return timeRange; 115.1 115.1 ERROR in ./src/explore/components/controls/DateFilterControl/DateFilterLabel.tsx:141:48 115.1 TS7006: Parameter 'timezone' implicitly has an 'any' type. 115.1 139 | ;
115.1 140 |
115.1 > 141 | function convertTimeRangeToTimezone(timeRange, timezone) {
115.1 | ^^^^^^^^
115.1 142 | // Example: "2025-07-23T05:59:49 ≤ col < 2025-07-23T06:05:49"
115.1 143 | // You may need to adjust this regex for your actual format
115.1 144 | if (!timeRange || !timezone) return timeRange;
115.1
115.1 ERROR in ./src/explore/components/controls/DateFilterControl/DateFilterLabel.tsx:147:5
115.1 TS7006: Parameter 'match' implicitly has an 'any' type.
115.1 145 | return timeRange.replace(
115.1 146 | /\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}/g,
115.1 > 147 | match => dayjs.utc(match).tz(timezone).format('YYYY-MM-DD HH:mm:ss')
115.1 | ^^^^^
115.1 148 | );
115.1 149 | }
115.1 150 |
115.1
115.1 webpack 5.97.1 compiled with 10 errors and 2 warnings in 105635 ms

Dockerfile:82

81 | # Build the frontend if not in dev mode
82 | >>> RUN --mount=type=cache,target=/root/.npm
83 | >>> if [ "$DEV_MODE" = "false" ]; then
84 | >>> echo "Running 'npm run ${BUILD_CMD}'";
85 | >>> npm run ${BUILD_CMD};
86 | >>> else
87 | >>> echo "Skipping 'npm run ${BUILD_CMD}' in dev mode";
88 | >>> fi;
89 |

ERROR: failed to solve: process "/bin/sh -c if [ "$DEV_MODE" = "false" ]; then echo "Running 'npm run ${BUILD_CMD}'"; npm run ${BUILD_CMD}; else echo "Skipping 'npm run ${BUILD_CMD}' in dev mode"; fi;" did not complete successfully: exit code: 1 which i havent gotten when i use docker compse dev mode adding few new features onto frontend ?

[dosubot[bot]]

You're seeing these errors because the production Docker build runs stricter type checks and uses the actual module export structure, which can surface issues that dev mode hides.

For the antd-v5 warnings: the code is trying to import named exports like TooltipProps and TooltipPlacement from 'antd-v5/lib/tooltip', but antd-v5 only provides a default export there. This is a common breaking change after major UI library upgrades. You'll need to update your import statements to match the new antd-v5 structure—check the official antd-v5 docs or look for type exports in a different location or from the default export.

The TypeScript errors (TS6133, TS2345, TS7006) are caught during the production build because the build process enforces strict type checking. Dev mode (like with docker-compose) often skips or relaxes these checks, so you don't see the errors until you do a full production build. To fix these, remove unused variables, ensure your types match the expected signatures, and add explicit type annotations where needed.

The Dockerfile only runs the full build (with all checks) when DEV_MODE is false, which is why these errors only appear in production Docker builds and not in dev mode. The build process does not run frontend React tests by default—these are type and module errors, not test failures.

If you want the build to succeed, you'll need to update your imports and fix the TypeScript errors so the production build passes all checks. For more on why these differences happen, see this explanation and npm build script details.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[sainikhilsamineni]

@dosu cant we skip these ?

[sainikhilsamineni]

@dosu please explain kubernetes deployment of superset and official helm chart of superset

[dosubot[bot]]

You can deploy Superset on Kubernetes using the official Helm chart, which is located in the helm/superset directory of the Superset GitHub repo. The public Helm chart registry is no longer available, so you should use the chart directly from the repo or host it internally in your organization. The chart is community-maintained and not officially supported by the core project, so thorough testing is recommended for production use source.

To deploy Superset 5.0.0, use Helm chart version 0.14.2 and override the image tag in your values.yaml to specify the 5.0.0 image. There isn't a chart version specifically for 5.0.0, so this approach requires extra validation source.

The Helm chart provides static templates for Superset services, database, ingress, and persistent storage. You can disable the internal PostgreSQL database by setting postgresql.enabled: false in values.yaml and configure an external database via supersetNode.connections. Store sensitive credentials like database passwords securely using Kubernetes secrets source.

For custom images or extra connectors (like Trino), build your own Docker image with the required packages installed, push it to your registry, and update the Helm chart values to use your image source.

If you need to deploy Superset under a URL prefix, set APPLICATION_ROOT, STATIC_ASSETS_PREFIX, and ENABLE_PROXY_FIX in Superset config, and configure your ingress or nginx proxy accordingly source.

The Helm chart deployment applies manifests once and does not provide continuous reconciliation or advanced lifecycle management features like a Kubernetes operator source.

Let me know if you need example configs or have specific questions about customizing your deployment!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[sainikhilsamineni]

@dosu ingress(ALB) issue when configuring via helm values. getting 504

[dosubot[bot]]

A 504 from ALB usually means the load balancer can't reach your Superset backend in time. For Superset on Kubernetes via Helm, double-check these areas:

• Your Helm values.yaml should have ingress enabled, with the correct ingressClassName for ALB, and ALB-specific annotations under ingress.annotations. The service type should be ClusterIP (default), and the service port should match what ALB expects (usually 8088) chart config reference.
• Make sure your Superset pods are healthy and responding to /health (the chart sets up readiness/liveness probes on this endpoint, which ALB uses for health checks) probe config reference.
• Set ALB-specific ingress annotations for timeouts, SSL, and routing in values.yaml. The chart exposes an annotations map for this, but you need to add the AWS-specific keys yourself ingress template reference.
• Check that your ALB target group health checks are passing. If not, look at pod logs (kubectl logs <pod>) and describe the ingress/service for errors.
• If you're using HTTPS, set WEBSERVER_BASE_URL, ENABLE_PROXY_FIX, SESSION_COOKIE_SECURE, and PREFERRED_URL_SCHEME in Superset config to match your ALB setup discussion.

If you share your ingress section from values.yaml and clarify which ingress controller you're using, I can help spot any misconfigurations.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[sainikhilsamineni]

@dosu service:
type: ClusterIP
port: 8088
annotations: {}
# cloud.google.com/load-balancer-type: "Internal"
loadBalancerIP: ~
nodePort:
# -- (int)
http: nil

ingress:
enabled: true
ingressClassName: ~
annotations:
# kubernetes.io/tls-acme: "true"
## Extend timeout to allow long running queries.
# nginx.ingress.kubernetes.io/proxy-connect-timeout: "300"
# nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
# nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
path: /
pathType: ImplementationSpecific
hosts:
- ""
tls: []
extraHostsRaw: []

- secretName: chart-example-tls

hosts:

- chart-example.local

[dosubot[bot]]

Your Helm values.yaml has a couple of key issues that can cause ALB 504 errors. The hosts field must be set to a valid DNS hostname (not an empty string)—for example, use your Superset domain or a placeholder like chart-example.local. The ingressClassName should be set to the ALB ingress controller's class name, usually "alb". Without these, ALB can't route traffic to your service.

Your ALB annotations look correct, but make sure your Superset pods are healthy and responding to /health, since ALB uses this for health checks. If you still get 504s after fixing hosts and ingressClassName, check your pod logs and ALB target group health status.

See the Helm chart values.yaml and ingress template for reference.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[sainikhilsamineni]

@dosu service:
type: ClusterIP
port: 8088
annotations: {}
# cloud.google.com/load-balancer-type: "Internal"
loadBalancerIP: ~
nodePort:
# -- (int)
http: nil

ingress:
enabled: true
ingressClassName: alb
annotations:
# kubernetes.io/tls-acme: "true"
## Extend timeout to allow long running queries.
# nginx.ingress.kubernetes.io/proxy-connect-timeout: "300"
# nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
# nginx.ingress.kubernetes.io/proxy-send-timeout: "300"
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}]'
alb.ingress.kubernetes.io/healthcheck-path: /health
alb.ingress.kubernetes.io/healthcheck-port: traffic-port
alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
alb.ingress.kubernetes.io/subnets: subnet-0f09e8e29a29f7ff8,subnet-063cf074c8442b1c0,subnet-012cbea3f769396f0
path: /
pathType: ImplementationSpecific
hosts:
- chart-example.local
tls: []
extraHostsRaw: []

- secretName: chart-example-tls

hosts:

- chart-example.local

[dosubot[bot]]

Your Helm values.yaml looks correct for ALB integration: service type is ClusterIP on port 8088, ingress is enabled with ingressClassName set to "alb", and ALB-specific annotations are present. The chart maps these settings directly to the Kubernetes Ingress resource, so ALB should route traffic to your Superset pods if everything is healthy values.yaml.

Superset's readiness, liveness, and startup probes all target the /health endpoint on port 8088, which matches your ALB health check path and port. This setup is important for ALB to detect healthy pods and avoid 504 errors deployment.yaml.

If you're still seeing 504 errors, check these next:

• Are your Superset pods passing readiness and liveness probes? Run kubectl get pods and kubectl describe pod <pod> to confirm.
• Is the ALB target group showing healthy targets? In AWS console, check the target group health status.
• Does the /health endpoint return HTTP 200 from inside the cluster? You can test with kubectl exec <pod> -- curl localhost:8088/health.
• Are there any errors in pod logs or events? Use kubectl logs <pod> and kubectl describe ingress <ingress-name>.

Most 504s are caused by unhealthy pods, misconfigured health checks, or network/security group issues between ALB and your cluster. If all probes and health checks are passing, traffic should flow correctly. If not, focus on pod health and ALB target group diagnostics.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[sainikhilsamineni]

@dosu now the alb is not at all reachable

[dosubot[bot]]

If the ALB is not reachable at all, start by checking these areas:

• Is the ALB actually provisioned in AWS and visible in the console? If not, check for errors in the Kubernetes ingress controller logs—sometimes missing or invalid subnets, security groups, or IAM permissions prevent ALB creation.
• Does the ALB DNS name resolve to an IP address? If not, the ALB may not be provisioned or may have been deleted.
• Are the subnets in your Helm values.yaml valid, in the correct VPC, and have enough available IPs?
• Do the ALB security groups allow inbound traffic on port 80 (and 443 if using TLS), and outbound traffic to your cluster nodes?
• Is your Kubernetes Ingress resource healthy (kubectl get ingress, kubectl describe ingress <name>)? Look for events about failed provisioning or annotation errors.
• Check the ingress controller logs for errors about ALB creation, subnet, or security group issues.

If everything looks correct but the ALB is still unreachable, consider switching to NGINX Ingress Controller with cert-manager for SSL termination, as some users have found ALB problematic for Superset deployments example config and discussion.

If you find any errors or events in the AWS console or Kubernetes, share them here and I can help interpret them.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}