Allow running integration and E2E tests in tests workflow for external contributors

[czeslavo]

Is there an existing issue for this?

• I have searched the existing issues

Problem Statement

KTF's integration and E2E tests require secrets to run (for the Kong license, and for access to GKE). That makes them fail for PRs from external contributors. We'd like to run them against every PR, therefore we need to come up with a solution to that.

Proposed Solution

Trigger tests.yaml workflow on pull_request_target and ensure that in case a pull request author is an external contributor, the PR has to have a predefined label assigned (e.g. verified-for-running-ci) that would be assigned by a reviewer after ensuring that no potential secrets leak can happen due to the changes from PR.

Implement the workflow described by Michael Heap in his blogpost.

Additional information

No response

Acceptance Criteria

• Integration and E2E tests can be run against PRs submitted by external contributors

[shaneutt]

What's left after #597 to consider this resolved?

[pmalek]

Actually run the integration (and if possible e2e) tests on PRs from forks. Now they are just skipped to not cause trouble.

Since tests here are not grouped or tagged in any way to indicate they require a license we'd need to add that perhaps and only run those that don't require it (if we want to run something but not expose secrets)

[shaneutt]

Looks like @astoycos's PR #591 is working, so I think we're set!

[randmonkey]

Seems integration tests could run after merging #632. For e2e tests which is running on GKE, I think we may need a new issue to track how to enable GKE tests on forks.

[shaneutt]

Seems integration tests could run after merging #632. For e2e tests which is running on GKE, I think we may need a new issue to track how to enable GKE tests on forks.

Sounds good. As I remember it the GKE tests wont run unless the GKE_CREDS are present? If that's still the case that's probably fine as its minimally disruptive if not we could consider making it that way. These kinds of variances do however scream for a need for documentation, particularly better contributor guidance. We should get ahold of whatever miscreant started this repo and ask them "where is the documentation". 😅