2021-06-27 16:28:07 +09:00
|
|
|
package e2e
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"context"
|
|
|
|
|
"fmt"
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
"path/filepath"
|
2022-02-17 09:16:28 +09:00
|
|
|
"strconv"
|
2021-06-27 16:28:07 +09:00
|
|
|
"time"
|
|
|
|
|
|
|
|
|
|
"github.com/actions-runner-controller/actions-runner-controller/testing"
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
"github.com/onsi/gomega"
|
|
|
|
|
"sigs.k8s.io/yaml"
|
2021-06-27 16:28:07 +09:00
|
|
|
)
|
|
|
|
|
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
var (
|
|
|
|
|
controllerImageRepo = "actionsrunnercontrollere2e/actions-runner-controller"
|
|
|
|
|
controllerImageTag = "e2e"
|
2021-06-29 17:52:43 +09:00
|
|
|
controllerImage = testing.Img(controllerImageRepo, controllerImageTag)
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
runnerImageRepo = "actionsrunnercontrollere2e/actions-runner"
|
2022-02-20 04:37:15 +00:00
|
|
|
runnerDindImageRepo = "actionsrunnercontrollere2e/actions-runner-dind"
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
runnerImageTag = "e2e"
|
2021-06-29 17:52:43 +09:00
|
|
|
runnerImage = testing.Img(runnerImageRepo, runnerImageTag)
|
2022-02-20 04:37:15 +00:00
|
|
|
runnerDindImage = testing.Img(runnerDindImageRepo, runnerImageTag)
|
2021-06-27 16:28:07 +09:00
|
|
|
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
prebuildImages = []testing.ContainerImage{
|
2021-06-27 16:28:07 +09:00
|
|
|
controllerImage,
|
|
|
|
|
runnerImage,
|
2022-02-20 04:37:15 +00:00
|
|
|
runnerDindImage,
|
2021-06-27 16:28:07 +09:00
|
|
|
}
|
|
|
|
|
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
builds = []testing.DockerBuild{
|
2021-06-27 16:28:07 +09:00
|
|
|
{
|
2022-02-27 11:48:58 +00:00
|
|
|
Dockerfile: "../../Dockerfile",
|
|
|
|
|
Args: []testing.BuildArg{},
|
|
|
|
|
Image: controllerImage,
|
|
|
|
|
EnableBuildX: true,
|
2021-06-27 16:28:07 +09:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Dockerfile: "../../runner/Dockerfile",
|
|
|
|
|
Args: []testing.BuildArg{},
|
|
|
|
|
Image: runnerImage,
|
|
|
|
|
},
|
2022-02-20 04:37:15 +00:00
|
|
|
{
|
|
|
|
|
Dockerfile: "../../runner/Dockerfile.dindrunner",
|
|
|
|
|
Args: []testing.BuildArg{},
|
|
|
|
|
Image: runnerDindImage,
|
|
|
|
|
},
|
2021-06-27 16:28:07 +09:00
|
|
|
}
|
|
|
|
|
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
certManagerVersion = "v1.1.1"
|
2021-06-27 16:28:07 +09:00
|
|
|
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
images = []testing.ContainerImage{
|
2021-06-29 17:52:43 +09:00
|
|
|
testing.Img("docker", "dind"),
|
|
|
|
|
testing.Img("quay.io/brancz/kube-rbac-proxy", "v0.10.0"),
|
|
|
|
|
testing.Img("quay.io/jetstack/cert-manager-controller", certManagerVersion),
|
|
|
|
|
testing.Img("quay.io/jetstack/cert-manager-cainjector", certManagerVersion),
|
|
|
|
|
testing.Img("quay.io/jetstack/cert-manager-webhook", certManagerVersion),
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
commonScriptEnv = []string{
|
|
|
|
|
"SYNC_PERIOD=" + "10s",
|
|
|
|
|
"NAME=" + controllerImageRepo,
|
|
|
|
|
"VERSION=" + controllerImageTag,
|
|
|
|
|
"RUNNER_TAG=" + runnerImageTag,
|
2021-06-27 16:28:07 +09:00
|
|
|
}
|
2021-06-29 17:52:43 +09:00
|
|
|
|
|
|
|
|
testResultCMNamePrefix = "test-result-"
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
// If you're willing to run this test via VS Code "run test" or "debug test",
|
|
|
|
|
// almost certainly you'd want to make the default go test timeout from 30s to longer and enough value.
|
|
|
|
|
// Press Cmd + Shift + P, type "Workspace Settings" and open it, and type "go test timeout" and set e.g. 600s there.
|
|
|
|
|
// See https://github.com/golang/vscode-go/blob/master/docs/settings.md#gotesttimeout for more information.
|
|
|
|
|
//
|
|
|
|
|
// This tests ues testing.Logf extensively for debugging purpose.
|
|
|
|
|
// But messages logged via Logf shows up only when the test failed by default.
|
|
|
|
|
// To always enable logging, do not forget to pass `-test.v` to `go test`.
|
2021-11-09 09:04:19 +09:00
|
|
|
// If you're using VS Code, open `Workspace Settings` and search for `go test flags`, edit the `.vscode/settings.json` and put the below:
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
// "go.testFlags": ["-v"]
|
|
|
|
|
//
|
|
|
|
|
// This function requires a few environment variables to be set to provide some test data.
|
|
|
|
|
// If you're using VS Code and wanting to run this test locally,
|
|
|
|
|
// Browse "Workspace Settings" and search for "go test env file" and put e.g. "${workspaceFolder}/.test.env" there.
|
2021-06-29 17:52:43 +09:00
|
|
|
//
|
|
|
|
|
// Instead of relying on "stages" to make it possible to rerun individual tests like terratest,
|
|
|
|
|
// you use the "run subtest" feature provided by IDE like VS Code, IDEA, and GoLand.
|
|
|
|
|
// Our `testing` package automatically checks for the running test name and skips the cleanup tasks
|
|
|
|
|
// whenever the whole test failed, so that you can immediately start fixing issues and rerun inidividual tests.
|
|
|
|
|
// See the below link for how terratest handles this:
|
|
|
|
|
// https://terratest.gruntwork.io/docs/testing-best-practices/iterating-locally-using-test-stages/
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
func TestE2E(t *testing.T) {
|
|
|
|
|
if testing.Short() {
|
|
|
|
|
t.Skip("Skipped as -short is set")
|
|
|
|
|
}
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
env := initTestEnv(t)
|
|
|
|
|
env.useRunnerSet = true
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Run("build and load images", func(t *testing.T) {
|
|
|
|
|
env.buildAndLoadImages(t)
|
|
|
|
|
})
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Run("install cert-manager", func(t *testing.T) {
|
|
|
|
|
env.installCertManager(t)
|
2021-06-27 16:28:07 +09:00
|
|
|
})
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if t.Failed() {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
t.Run("install actions-runner-controller and runners", func(t *testing.T) {
|
|
|
|
|
env.installActionsRunnerController(t)
|
2021-06-27 16:28:07 +09:00
|
|
|
})
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if t.Failed() {
|
|
|
|
|
return
|
2021-06-27 16:28:07 +09:00
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Run("Install workflow", func(t *testing.T) {
|
|
|
|
|
env.installActionsWorkflow(t)
|
|
|
|
|
})
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if t.Failed() {
|
|
|
|
|
return
|
|
|
|
|
}
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Run("Verify workflow run result", func(t *testing.T) {
|
|
|
|
|
env.verifyActionsWorkflowRun(t)
|
|
|
|
|
})
|
|
|
|
|
}
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
func TestE2ERunnerDeploy(t *testing.T) {
|
|
|
|
|
if testing.Short() {
|
|
|
|
|
t.Skip("Skipped as -short is set")
|
|
|
|
|
}
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
env := initTestEnv(t)
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Run("build and load images", func(t *testing.T) {
|
|
|
|
|
env.buildAndLoadImages(t)
|
|
|
|
|
})
|
2021-06-27 16:28:07 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Run("install cert-manager", func(t *testing.T) {
|
|
|
|
|
env.installCertManager(t)
|
2021-06-27 16:28:07 +09:00
|
|
|
})
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if t.Failed() {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
t.Run("install actions-runner-controller and runners", func(t *testing.T) {
|
|
|
|
|
env.installActionsRunnerController(t)
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
})
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if t.Failed() {
|
|
|
|
|
return
|
2021-06-27 16:28:07 +09:00
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Run("Install workflow", func(t *testing.T) {
|
|
|
|
|
env.installActionsWorkflow(t)
|
|
|
|
|
})
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if t.Failed() {
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
t.Run("Verify workflow run result", func(t *testing.T) {
|
|
|
|
|
env.verifyActionsWorkflowRun(t)
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
})
|
2021-06-29 17:52:43 +09:00
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
type env struct {
|
|
|
|
|
*testing.Env
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
useRunnerSet bool
|
|
|
|
|
|
|
|
|
|
testID string
|
2022-02-19 09:24:12 +00:00
|
|
|
testName string
|
2022-02-17 09:16:28 +09:00
|
|
|
repoToCommit string
|
2021-06-29 17:52:43 +09:00
|
|
|
runnerLabel, githubToken, testRepo, testOrg, testOrgRepo string
|
2022-02-17 09:16:28 +09:00
|
|
|
githubTokenWebhook string
|
|
|
|
|
testEnterprise string
|
|
|
|
|
featureFlagEphemeral bool
|
2022-02-20 13:40:03 +00:00
|
|
|
scaleDownDelaySecondsAfterScaleOut int64
|
|
|
|
|
minReplicas int64
|
2022-02-20 04:37:15 +00:00
|
|
|
dockerdWithinRunnerContainer bool
|
2021-06-29 17:52:43 +09:00
|
|
|
testJobs []job
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func initTestEnv(t *testing.T) *env {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
testingEnv := testing.Start(t, testing.Preload(images...))
|
|
|
|
|
|
|
|
|
|
e := &env{Env: testingEnv}
|
|
|
|
|
|
|
|
|
|
id := e.ID()
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2022-02-19 09:24:12 +00:00
|
|
|
testName := t.Name() + " " + id
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2022-02-19 09:24:12 +00:00
|
|
|
t.Logf("Initializing test with name %s", testName)
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2022-02-19 09:24:12 +00:00
|
|
|
e.testID = id
|
|
|
|
|
e.testName = testName
|
2021-06-29 17:52:43 +09:00
|
|
|
e.runnerLabel = "test-" + id
|
|
|
|
|
e.githubToken = testing.Getenv(t, "GITHUB_TOKEN")
|
2022-02-17 09:16:28 +09:00
|
|
|
e.githubTokenWebhook = testing.Getenv(t, "WEBHOOK_GITHUB_TOKEN")
|
|
|
|
|
e.repoToCommit = testing.Getenv(t, "TEST_COMMIT_REPO")
|
|
|
|
|
e.testRepo = testing.Getenv(t, "TEST_REPO", "")
|
|
|
|
|
e.testOrg = testing.Getenv(t, "TEST_ORG", "")
|
|
|
|
|
e.testOrgRepo = testing.Getenv(t, "TEST_ORG_REPO", "")
|
|
|
|
|
e.testEnterprise = testing.Getenv(t, "TEST_ENTERPRISE")
|
2022-02-19 09:24:12 +00:00
|
|
|
e.testJobs = createTestJobs(id, testResultCMNamePrefix, 100)
|
2022-02-17 09:16:28 +09:00
|
|
|
ephemeral, _ := strconv.ParseBool(testing.Getenv(t, "TEST_FEATURE_FLAG_EPHEMERAL"))
|
|
|
|
|
e.featureFlagEphemeral = ephemeral
|
2022-02-20 13:40:03 +00:00
|
|
|
e.scaleDownDelaySecondsAfterScaleOut, _ = strconv.ParseInt(testing.Getenv(t, "TEST_RUNNER_SCALE_DOWN_DELAY_SECONDS_AFTER_SCALE_OUT", "10"), 10, 32)
|
|
|
|
|
e.minReplicas, _ = strconv.ParseInt(testing.Getenv(t, "TEST_RUNNER_MIN_REPLICAS", "1"), 10, 32)
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2022-02-20 04:37:15 +00:00
|
|
|
var err error
|
|
|
|
|
e.dockerdWithinRunnerContainer, err = strconv.ParseBool(testing.Getenv(t, "TEST_RUNNER_DOCKERD_WITHIN_RUNNER_CONTAINER", "false"))
|
|
|
|
|
if err != nil {
|
|
|
|
|
panic(fmt.Sprintf("unable to parse bool from TEST_RUNNER_DOCKERD_WITHIN_RUNNER_CONTAINER: %v", err))
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
return e
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *env) f() {
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *env) buildAndLoadImages(t *testing.T) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
e.DockerBuild(t, builds)
|
|
|
|
|
e.KindLoadImages(t, prebuildImages)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *env) installCertManager(t *testing.T) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
applyCfg := testing.KubectlConfig{NoValidate: true}
|
|
|
|
|
|
|
|
|
|
e.KubectlApply(t, fmt.Sprintf("https://github.com/jetstack/cert-manager/releases/download/%s/cert-manager.yaml", certManagerVersion), applyCfg)
|
|
|
|
|
|
|
|
|
|
waitCfg := testing.KubectlConfig{
|
|
|
|
|
Namespace: "cert-manager",
|
|
|
|
|
Timeout: 90 * time.Second,
|
2021-06-27 16:28:07 +09:00
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
e.KubectlWaitUntilDeployAvailable(t, "cert-manager-cainjector", waitCfg)
|
|
|
|
|
e.KubectlWaitUntilDeployAvailable(t, "cert-manager-webhook", waitCfg.WithTimeout(60*time.Second))
|
|
|
|
|
e.KubectlWaitUntilDeployAvailable(t, "cert-manager", waitCfg.WithTimeout(60*time.Second))
|
|
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
func (e *env) installActionsRunnerController(t *testing.T) {
|
|
|
|
|
t.Helper()
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
e.createControllerNamespaceAndServiceAccount(t)
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
scriptEnv := []string{
|
|
|
|
|
"KUBECONFIG=" + e.Kubeconfig(),
|
|
|
|
|
"ACCEPTANCE_TEST_DEPLOYMENT_TOOL=" + "helm",
|
|
|
|
|
"ACCEPTANCE_TEST_SECRET_TYPE=token",
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if e.useRunnerSet {
|
|
|
|
|
scriptEnv = append(scriptEnv, "USE_RUNNERSET=1")
|
2022-03-05 12:13:22 +00:00
|
|
|
} else {
|
|
|
|
|
scriptEnv = append(scriptEnv, "USE_RUNNERSET=false")
|
2021-06-29 17:52:43 +09:00
|
|
|
}
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
varEnv := []string{
|
2022-02-17 09:16:28 +09:00
|
|
|
"TEST_ENTERPRISE=" + e.testEnterprise,
|
2021-06-29 17:52:43 +09:00
|
|
|
"TEST_REPO=" + e.testRepo,
|
|
|
|
|
"TEST_ORG=" + e.testOrg,
|
|
|
|
|
"TEST_ORG_REPO=" + e.testOrgRepo,
|
|
|
|
|
"GITHUB_TOKEN=" + e.githubToken,
|
2022-02-17 09:16:28 +09:00
|
|
|
"WEBHOOK_GITHUB_TOKEN=" + e.githubTokenWebhook,
|
2021-06-29 17:52:43 +09:00
|
|
|
"RUNNER_LABEL=" + e.runnerLabel,
|
2022-02-19 09:24:12 +00:00
|
|
|
"TEST_ID=" + e.testID,
|
2022-02-17 09:16:28 +09:00
|
|
|
fmt.Sprintf("RUNNER_FEATURE_FLAG_EPHEMERAL=%v", e.featureFlagEphemeral),
|
2022-02-20 13:40:03 +00:00
|
|
|
fmt.Sprintf("RUNNER_SCALE_DOWN_DELAY_SECONDS_AFTER_SCALE_OUT=%d", e.scaleDownDelaySecondsAfterScaleOut),
|
2022-02-27 11:43:07 +00:00
|
|
|
fmt.Sprintf("REPO_RUNNER_MIN_REPLICAS=%d", e.minReplicas),
|
2022-02-20 13:40:03 +00:00
|
|
|
fmt.Sprintf("ORG_RUNNER_MIN_REPLICAS=%d", e.minReplicas),
|
2022-02-27 11:43:07 +00:00
|
|
|
fmt.Sprintf("ENTERPRISE_RUNNER_MIN_REPLICAS=%d", e.minReplicas),
|
2021-06-29 14:34:27 +09:00
|
|
|
}
|
|
|
|
|
|
2022-02-20 04:37:15 +00:00
|
|
|
if e.dockerdWithinRunnerContainer {
|
|
|
|
|
varEnv = append(varEnv,
|
|
|
|
|
"RUNNER_DOCKERD_WITHIN_RUNNER_CONTAINER=true",
|
|
|
|
|
"RUNNER_NAME="+runnerDindImageRepo,
|
|
|
|
|
)
|
|
|
|
|
} else {
|
|
|
|
|
varEnv = append(varEnv,
|
|
|
|
|
"RUNNER_DOCKERD_WITHIN_RUNNER_CONTAINER=false",
|
|
|
|
|
"RUNNER_NAME="+runnerImageRepo,
|
|
|
|
|
)
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
scriptEnv = append(scriptEnv, varEnv...)
|
|
|
|
|
scriptEnv = append(scriptEnv, commonScriptEnv...)
|
|
|
|
|
|
|
|
|
|
e.RunScript(t, "../../acceptance/deploy.sh", testing.ScriptConfig{Dir: "../..", Env: scriptEnv})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *env) createControllerNamespaceAndServiceAccount(t *testing.T) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
e.KubectlEnsureNS(t, "actions-runner-system", testing.KubectlConfig{})
|
|
|
|
|
e.KubectlEnsureClusterRoleBindingServiceAccount(t, "default-admin", "cluster-admin", "default:default", testing.KubectlConfig{})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *env) installActionsWorkflow(t *testing.T) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
2022-02-19 09:24:12 +00:00
|
|
|
installActionsWorkflow(t, e.testName, e.runnerLabel, testResultCMNamePrefix, e.repoToCommit, e.testJobs)
|
2021-06-29 17:52:43 +09:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (e *env) verifyActionsWorkflowRun(t *testing.T) {
|
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
verifyActionsWorkflowRun(t, e.Env, e.testJobs)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type job struct {
|
|
|
|
|
name, testArg, configMapName string
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func createTestJobs(id, testResultCMNamePrefix string, numJobs int) []job {
|
2021-06-29 14:34:27 +09:00
|
|
|
var testJobs []job
|
|
|
|
|
|
|
|
|
|
for i := 0; i < numJobs; i++ {
|
|
|
|
|
name := fmt.Sprintf("test%d", i)
|
|
|
|
|
testArg := fmt.Sprintf("%s%d", id, i)
|
|
|
|
|
configMapName := testResultCMNamePrefix + testArg
|
|
|
|
|
|
|
|
|
|
testJobs = append(testJobs, job{name: name, testArg: testArg, configMapName: configMapName})
|
|
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
return testJobs
|
|
|
|
|
}
|
|
|
|
|
|
2022-02-17 09:16:28 +09:00
|
|
|
const Branch = "main"
|
|
|
|
|
|
2022-02-19 09:24:12 +00:00
|
|
|
func installActionsWorkflow(t *testing.T, testName, runnerLabel, testResultCMNamePrefix, testRepo string, testJobs []job) {
|
2021-06-29 17:52:43 +09:00
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
|
|
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
|
|
|
|
|
defer cancel()
|
|
|
|
|
|
2022-02-19 09:24:12 +00:00
|
|
|
wfName := "E2E " + testName
|
2021-06-29 17:52:43 +09:00
|
|
|
wf := testing.Workflow{
|
|
|
|
|
Name: wfName,
|
|
|
|
|
On: testing.On{
|
|
|
|
|
Push: &testing.Push{
|
2022-02-17 09:16:28 +09:00
|
|
|
Branches: []string{Branch},
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
},
|
2021-06-29 17:52:43 +09:00
|
|
|
},
|
|
|
|
|
Jobs: map[string]testing.Job{},
|
|
|
|
|
}
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
for _, j := range testJobs {
|
|
|
|
|
wf.Jobs[j.name] = testing.Job{
|
|
|
|
|
RunsOn: runnerLabel,
|
|
|
|
|
Steps: []testing.Step{
|
|
|
|
|
{
|
|
|
|
|
Uses: testing.ActionsCheckoutV2,
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
Uses: "azure/setup-kubectl@v1",
|
|
|
|
|
With: &testing.With{
|
|
|
|
|
Version: "v1.20.2",
|
2021-06-29 14:34:27 +09:00
|
|
|
},
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
},
|
2021-06-29 17:52:43 +09:00
|
|
|
{
|
|
|
|
|
Run: fmt.Sprintf("./test.sh %s %s", t.Name(), j.testArg),
|
|
|
|
|
},
|
|
|
|
|
},
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
}
|
2021-06-29 17:52:43 +09:00
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
wfContent, err := yaml.Marshal(wf)
|
|
|
|
|
if err != nil {
|
|
|
|
|
t.Fatal(err)
|
|
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
script := []byte(fmt.Sprintf(`#!/usr/bin/env bash
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
set -vx
|
2021-06-29 14:34:27 +09:00
|
|
|
name=$1
|
|
|
|
|
id=$2
|
|
|
|
|
echo hello from $name
|
|
|
|
|
kubectl delete cm %s$id || true
|
|
|
|
|
kubectl create cm %s$id --from-literal=status=ok
|
|
|
|
|
`, testResultCMNamePrefix, testResultCMNamePrefix))
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
g := testing.GitRepo{
|
|
|
|
|
Dir: filepath.Join(t.TempDir(), "gitrepo"),
|
|
|
|
|
Name: testRepo,
|
|
|
|
|
CommitMessage: wfName,
|
|
|
|
|
Contents: map[string][]byte{
|
|
|
|
|
".github/workflows/workflow.yaml": wfContent,
|
|
|
|
|
"test.sh": script,
|
|
|
|
|
},
|
2022-02-17 09:16:28 +09:00
|
|
|
Branch: Branch,
|
2021-06-29 17:52:43 +09:00
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if err := g.Sync(ctx); err != nil {
|
|
|
|
|
t.Fatal(err)
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
}
|
2021-06-29 17:52:43 +09:00
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
func verifyActionsWorkflowRun(t *testing.T, env *testing.Env, testJobs []job) {
|
|
|
|
|
t.Helper()
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
var expected []string
|
|
|
|
|
|
|
|
|
|
for _ = range testJobs {
|
|
|
|
|
expected = append(expected, "ok")
|
|
|
|
|
}
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
gomega.NewGomegaWithT(t).Eventually(func() ([]string, error) {
|
|
|
|
|
var results []string
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
var errs []error
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
for i := range testJobs {
|
|
|
|
|
testResultCMName := testJobs[i].configMapName
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
kubectlEnv := []string{
|
|
|
|
|
"KUBECONFIG=" + env.Kubeconfig(),
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
}
|
|
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
cmCfg := testing.KubectlConfig{
|
|
|
|
|
Env: kubectlEnv,
|
|
|
|
|
}
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
|
|
|
|
|
defer cancel()
|
2021-06-29 14:34:27 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
m, err := env.Kubectl.GetCMLiterals(ctx, testResultCMName, cmCfg)
|
|
|
|
|
if err != nil {
|
|
|
|
|
errs = append(errs, err)
|
|
|
|
|
} else {
|
|
|
|
|
result := m["status"]
|
|
|
|
|
results = append(results, result)
|
2021-06-29 14:34:27 +09:00
|
|
|
}
|
2021-06-29 17:52:43 +09:00
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
var err error
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
if len(errs) > 0 {
|
|
|
|
|
var msg string
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
for i, e := range errs {
|
|
|
|
|
msg += fmt.Sprintf("error%d: %v\n", i, e)
|
|
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
err = fmt.Errorf("%d errors occurred: %s", len(errs), msg)
|
|
|
|
|
}
|
e2e: Install and run workflow and verify the result (#661)
This enhances the E2E test suite introduced in #658 to also include the following steps:
- Install GitHub Actions workflow
- Trigger a workflow run via a git commit
- Verify the workflow run result
In the workflow, we use `kubectl create cm --from-literal` to create a configmap that contains an unique test ID. In the last step we obtain the configmap from within the E2E test and check the test ID to match the expected one.
To install a GitHub Actions workflow, we clone a GitHub repository denoted by the TEST_REPO envvar, progmatically generate a few files with some Go code, run `git-add`, `git-commit`, and then `git-push` to actually push the files to the repository. A single commit containing an updated workflow definition and an updated file seems to run a workflow derived to the definition introduced in the commit, which was a bit surpirising and useful behaviour.
At this point, the E2E test fully covers all the steps for a GitHub token based installation. We need to add scenarios for more deployment options, like GitHub App, RunnerDeployment, HRA, and so on. But each of them would worth another pull request.
2021-06-28 08:30:32 +09:00
|
|
|
|
2021-06-29 17:52:43 +09:00
|
|
|
return results, err
|
2021-09-15 00:23:16 +00:00
|
|
|
}, 3*60*time.Second, 10*time.Second).Should(gomega.Equal(expected))
|
2021-06-27 16:28:07 +09:00
|
|
|
}
|