feat: migrate ingress from NGINX to Envoy Gateway

[laurigates]

Migrate OLMap backend and frontend from ingress-nginx to Envoy Gateway (Gateway API).

• Add gateway.enabled: true to both deploy/backend-values.yaml and deploy/frontend-values.yaml
• Disable explicit ingress resources (chart suppresses them when gateway is enabled)
• Remove NGINX-specific configuration-snippet annotation from frontend

Important

Before merging, verify the frontend nginx container image handles SPA routing (try_files $uri $uri/ /index.html) internally in its nginx.conf.

Closes #62

Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request transitions the OLMap backend and frontend services from using ingress-nginx to leveraging Envoy Gateway via the Kubernetes Gateway API. This change modernizes the ingress management, consolidating routing logic and preparing for a more standardized and flexible traffic management solution. The update involves enabling the new gateway configuration and disabling the legacy ingress resources, streamlining the deployment process for external access.

Highlights

• Ingress Migration: The backend and frontend ingress configurations have been migrated from ingress-nginx to Envoy Gateway using the Gateway API.
• Configuration Updates: The gateway.enabled: true flag was added to both deploy/backend-values.yaml and deploy/frontend-values.yaml to activate the new Gateway API setup.
• Ingress Disablement: Explicit ingress resources have been disabled in both backend-values.yaml and frontend-values.yaml, as they are now superseded by the Gateway API.
• Frontend Routing: The NGINX-specific configuration-snippet annotation, previously used for SPA routing, was removed from the frontend configuration, with a note that SPA routing must now be handled internally by the NGINX container.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request migrates the application's ingress from NGINX Ingress to Envoy Gateway by updating the Helm values for the backend and frontend deployments. The changes correctly enable the Gateway API configuration and disable the legacy Ingress resources. However, I've identified a critical issue where related application configuration, such as DJANGO_ALLOWED_HOSTS and CORS settings, has not been updated to reflect the new hostname-based routing scheme introduced by this migration. This will likely break the application. A specific comment has been left on the relevant file with details on the required fixes.

[gemini-code-assist]

This comment indicates the backend will be served from olmap-backend.dataportal.fi. This is a change from the previous single-host setup (olmap.dataportal.fi).

This change requires corresponding updates to other configuration values in this file, which appear to have been missed:

• DJANGO_ALLOWED_HOSTS (line 80) should include olmap-backend.dataportal.fi.
• DJANGO_CORS_ALLOWED_ORIGINS (line 82) should be updated to the new frontend URL, which seems to be https://olmap-frontend.dataportal.fi based on the changes in deploy/frontend-values.yaml.
• FRONTEND_ROOT (line 98) should also be updated to https://olmap-frontend.dataportal.fi.

Without these changes, the application will likely fail with CORS errors, incorrect redirects, and other issues.

[laurigates]

Let's address the recommendations in the comments. Evaluate which pieces of criticism and recommendations are substantive and valid. Act accordingly and refute invalid points.

Create follow-up issue for the currently failing tests
@claude

[claude]

Claude finished @laurigates's task in 2m 43s —— View job

---

Addressing Review Comments

• Read changed files and evaluated Gemini's feedback
• Fixed DJANGO_ALLOWED_HOSTS, DJANGO_CORS_ALLOWED_ORIGINS, and FRONTEND_ROOT — committed and pushed
• Created follow-up issue for failing pre-commit CI (see below)

---

Gemini feedback evaluation

Valid — addressed: Gemini's concern about hostname mismatches is correct. The migration changes routing from a single shared domain olmap.dataportal.fi (path-based) to two separate subdomains (hostname-based):

• Backend: olmap-backend.dataportal.fi
• Frontend: olmap-frontend.dataportal.fi

The following env vars in deploy/backend-values.yaml were stale and have been updated:

Variable	Before	After
DJANGO_ALLOWED_HOSTS	olmap.dataportal.fi,localhost	olmap-backend.dataportal.fi,localhost
DJANGO_CORS_ALLOWED_ORIGINS	https://olmap.dataportal.fi	https://olmap-frontend.dataportal.fi
FRONTEND_ROOT	https://olmap.dataportal.fi	https://olmap-frontend.dataportal.fi

Without these changes, Django would reject requests arriving at the new backend hostname and CORS would block the frontend.

---

CI failure analysis

The Tests workflow failure is from pre-existing issues unrelated to this PR:

1. check-yaml / yamllint in deploy/backend-values.yaml: duplicate migrations top-level key (lines 8 and 205) and multiple indentation errors. Same in deploy/frontend-values.yaml.
2. detect-secrets false positives in .github/workflows/renovate.yml:33 and SECURITY_ANALYSIS.md:31,224 — these need # pragma: allowlist secret annotations and a baseline regeneration.

I attempted to create a follow-up issue but the gh issue create command requires user approval in the current permission settings. Please create a follow-up issue (or approve the command) covering:

• Duplicate migrations key in deploy/backend-values.yaml
• yamllint indentation errors in both deploy YAML files
• detect-secrets false positives in renovate.yml and SECURITY_ANALYSIS.md

---

| Branch