This guide shows you how to dynamically fetch your Kubernetes Ingress host, expose it as a job output in aDocumentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
dev-deploy job, and consume that output in an integration-testing job to verify your /live endpoint. By the end, you’ll have a seamless flow where the Ingress URL travels between jobs in the same workflow.
Overview
- Capture the Ingress host URL after deployment
- Export it as a job output
- Use the output in a downstream integration test
1. Deploying to Dev and Capturing the Ingress URL
In thedev-deploy job, we apply Kubernetes manifests and query the Ingress host name. We then write it to $GITHUB_OUTPUT so it becomes available to other jobs.
Ensure your Kubernetes context and namespace (
${{ vars.NAMESPACE }}) are correctly configured before running kubectl.2. Defining the Integration Testing Job
Afterdev-deploy completes, integration-testing retrieves the APP_INGRESS_URL output and calls the /live endpoint using curl and jq.
The Ubuntu runner includes both
curl and jq by default. If you use a custom runner, install these tools before running the test.3. Passing Values Between Jobs
GitHub Actions lets you map step outputs to job outputs and then reference them in downstream jobs via theneeds context.
| Level | Syntax | Example |
|---|---|---|
| Step output | steps.<step_id>.outputs.<output_name> | steps.set-ingress-host-address.outputs.APP_INGRESS_URL |
| Job output | needs.<job_id>.outputs.<output_name> | needs.dev-deploy.outputs.APP_INGRESS_URL |

4. Complete Workflow Example
Here’s how the full.github/workflows/solar-system.yml might look with both jobs defined:

References
- GitHub Actions Contexts: needs
- GitHub Actions: workflow syntax for GitHub Actions
- Kubernetes Ingress