2021-06-27 16:28:07 +09:00
package e2e
import (
"context"
"fmt"
2022-05-26 10:59:50 +09:00
"os"
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
} ,
{
2022-05-22 10:25:50 +09:00
Dockerfile : "../../runner/actions-runner.dockerfile" ,
2022-04-03 11:12:44 +09:00
Args : [ ] testing . BuildArg {
{
Name : "RUNNER_VERSION" ,
2022-05-22 10:25:50 +09:00
Value : "2.291.1" ,
2022-04-03 11:12:44 +09:00
} ,
} ,
Image : runnerImage ,
2021-06-27 16:28:07 +09:00
} ,
2022-02-20 04:37:15 +00:00
{
2022-05-22 10:25:50 +09:00
Dockerfile : "../../runner/actions-runner-dind.dockerfile" ,
2022-04-03 11:12:44 +09:00
Args : [ ] testing . BuildArg {
{
Name : "RUNNER_VERSION" ,
2022-05-22 10:25:50 +09:00
Value : "2.291.1" ,
2022-04-03 11:12:44 +09:00
} ,
} ,
Image : runnerDindImage ,
2022-02-20 04:37:15 +00:00
} ,
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 {
2022-04-03 11:12:44 +09:00
"SYNC_PERIOD=" + "30m" ,
2021-06-29 17:52:43 +09:00
"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 )
} )
2022-05-26 10:59:50 +09:00
if os . Getenv ( "ARC_E2E_NO_CLEANUP" ) != "" {
t . FailNow ( )
}
2021-06-29 17:52:43 +09:00
}
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 )
2022-03-13 13:11:26 +00:00
env . useApp = 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 )
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
} )
2022-03-12 12:10:04 +00:00
2022-05-26 10:59:50 +09:00
if os . Getenv ( "ARC_E2E_NO_CLEANUP" ) != "" {
t . FailNow ( )
}
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
2022-03-12 12:10:04 +00:00
// Uses GITHUB_APP_ID, GITHUB_APP_INSTALLATION_ID, and GITHUB_APP_PRIVATE_KEY
// to let ARC authenticate as a GitHub App
useApp bool
2021-06-29 17:52:43 +09:00
testID string
2022-02-19 09:24:12 +00:00
testName string
2022-02-17 09:16:28 +09:00
repoToCommit string
2022-03-12 12:10:04 +00:00
appID , appInstallationID , appPrivateKeyFile 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
2022-03-13 07:22:04 +00:00
testEphemeral string
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-03-12 12:10:04 +00:00
e . appID = testing . Getenv ( t , "GITHUB_APP_ID" )
e . appInstallationID = testing . Getenv ( t , "GITHUB_APP_INSTALLATION_ID" )
e . appPrivateKeyFile = testing . Getenv ( t , "GITHUB_APP_PRIVATE_KEY_FILE" )
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" , "" )
2022-03-13 13:11:26 +00:00
e . testEnterprise = testing . Getenv ( t , "TEST_ENTERPRISE" , "" )
2022-03-13 07:22:04 +00:00
e . testEphemeral = testing . Getenv ( t , "TEST_EPHEMERAL" , "" )
2022-05-16 09:26:48 +09:00
e . testJobs = createTestJobs ( id , testResultCMNamePrefix , 6 )
2022-03-12 14:08:23 +00:00
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" ,
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 ,
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-03-13 07:22:04 +00:00
"TEST_EPHEMERAL=" + e . testEphemeral ,
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-03-12 12:10:04 +00:00
if e . useApp {
varEnv = append ( varEnv ,
"ACCEPTANCE_TEST_SECRET_TYPE=app" ,
"APP_ID=" + e . appID ,
"APP_INSTALLATION_ID=" + e . appInstallationID ,
"APP_PRIVATE_KEY_FILE=" + e . appPrivateKeyFile ,
)
} else {
varEnv = append ( varEnv ,
"ACCEPTANCE_TEST_SECRET_TYPE=token" ,
"GITHUB_TOKEN=" + e . githubToken ,
)
}
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 ,
} ,
2022-05-16 09:26:48 +09:00
{
// This might be the easiest way to handle permissions without use of securityContext
// https://stackoverflow.com/questions/50156124/kubernetes-nfs-persistent-volumes-permission-denied#comment107483717_53186320
Run : "sudo chmod 777 -R \"${RUNNER_TOOL_CACHE}\" \"${HOME}/.cache\" \"/var/lib/docker\"" ,
} ,
{
// This might be the easiest way to handle permissions without use of securityContext
// https://stackoverflow.com/questions/50156124/kubernetes-nfs-persistent-volumes-permission-denied#comment107483717_53186320
Run : "ls -lah \"${RUNNER_TOOL_CACHE}\" \"${HOME}/.cache\" \"/var/lib/docker\"" ,
} ,
{
Uses : "actions/setup-go@v3" ,
With : & testing . With {
2022-05-19 18:33:31 +09:00
GoVersion : "1.18.2" ,
2022-05-16 09:26:48 +09:00
} ,
} ,
{
Run : "go version" ,
} ,
{
Run : "go build ." ,
} ,
{
// https://github.com/docker/buildx/issues/413#issuecomment-710660155
// To prevent setup-buildx-action from failing with:
// error: could not create a builder instance with TLS data loaded from environment. Please use `docker context create <context-name>` to create a context for current environment and then create a builder instance with `docker buildx create <context-name>`
Run : "docker context create mycontext" ,
} ,
{
Run : "docker context use mycontext" ,
} ,
{
Name : "Set up Docker Buildx" ,
Uses : "docker/setup-buildx-action@v1" ,
With : & testing . With {
BuildkitdFlags : "--debug" ,
Endpoint : "mycontext" ,
// As the consequence of setting `install: false`, it doesn't install buildx as an alias to `docker build`
// so we need to use `docker buildx build` in the next step
Install : false ,
} ,
} ,
{
Run : "docker buildx build --platform=linux/amd64 " +
"--cache-from=type=local,src=/home/runner/.cache/buildx " +
"--cache-to=type=local,dest=/home/runner/.cache/buildx-new,mode=max " +
"." ,
} ,
{
// https://github.com/docker/build-push-action/blob/master/docs/advanced/cache.md#local-cache
// See https://github.com/moby/buildkit/issues/1896 for why this is needed
Run : "rm -rf /home/runner/.cache/buildx && mv /home/runner/.cache/buildx-new /home/runner/.cache/buildx" ,
} ,
{
Run : "ls -lah /home/runner/.cache/*" ,
} ,
2021-06-29 17:52:43 +09:00
{
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
}