feat: end to end testing with coredns provider

[Raffo]

What does it do ?

This pull request implements end to end testing by using the coredns provider. This is a much simpler approach than what I originally proposed with a custom provider.

Motivation

We have custom end-to-end testing infrastructure since almost the beginning of this project that I've been maintaining myself. That infrastructure has relied on an AWS account, and a private zone. Unfortunately, due to security requirements, I cannot make that infrastructure available to the bigger project, and that meant that I was always the bottleneck to run end to end tests. The motivation behind this work is to stop using that infrastructure and relying only on kind and local tests.

#5601

• Yes, this PR title follows Conventional Commits
• Yes, I added unit tests
• Yes, I updated end user documentation accordingly

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[coveralls]

Pull Request Test Coverage Report for Build 19495451846

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 116 unchanged lines in 6 files lost coverage.
• Overall coverage decreased (-0.008%) to 78.658%

---

Files with Coverage Reduction	New Missed Lines	%
openshift_route.go	1	79.49%
apis/externaldns/types.go	1	99.71%
source.go	3	83.33%
istio_gateway.go	8	90.1%
gloo_proxy.go	47	74.18%
execute.go	56	64.72%

Totals
Change from base Build 18968339179:	-0.008%
Covered Lines:	15951
Relevant Lines:	20279

---

💛 - Coveralls

[mloiseleur]

For the feature, it would really help and improve quality to have CI like this 👍 .

For the implementation choice, I'm still unsure 🤔.

✔️ On one hand, having a small custom DNS implementation allows behavior flexibility and speed
❌ on the other hand, it will require us to implement every new feature we want to add in e2e testing and we may miss some specific details that will be in standard implementation.

💡 It remembers me that I've opened a PR about documenting usage of coredns for local dev testing (#5887).

@Raffo Did you consider using coredns as an option for the implementation ?

[Raffo]

@mloiseleur Yes, I considered it. Unfortunately coreDNS doesn't really work. It re needs a whole etcd server up and running. And that sounded more complicated than what we wanted to do. Remind that we're not testing a provider, any provider, not the coredns provider, not this fake provider, but we're testing the core of the project like the image can start and the plan works and and so on. Happy to change, but currently a bit unsure of the benefits as well 🤔

[Raffo]

I'm working to refactor this towards using etcd.

[Raffo]

@mloiseleur ok update this test to not have a custom provider and rely entirely on the coredns one. This a much simpler approach and I wish I did it from the beginning. Nonetheless, I'm quite happy with it. You can see the run of the tests here: https://github.com/Raffo/external-dns/actions/runs/19392854519/job/55488802798

[mloiseleur]

@Raffo Wdyt about requesting coredns directly ?
It can be done either by exposing coredns port like exposed in kind documentation, or even via port-forward ?

[Raffo]

But we are essentially asking coredns, just by using hostnetwork and the direct port. I think that is not a bad hack as it relies on dig directly which seems quite fine as a contract.

[szuecs]

/lgtm

[mloiseleur]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mloiseleur

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mloiseleur]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment