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
|
|
|
package testing
|
|
|
|
|
|
|
|
|
|
const (
|
2022-06-30 09:09:58 +09:00
|
|
|
ActionsCheckout = "actions/checkout@v3"
|
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
|
|
|
)
|
|
|
|
|
|
|
|
|
|
type Workflow struct {
|
|
|
|
|
Name string `json:"name"`
|
|
|
|
|
On On `json:"on"`
|
|
|
|
|
Jobs map[string]Job `json:"jobs"`
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type On struct {
|
|
|
|
|
Push *Push `json:"push,omitempty"`
|
|
|
|
|
WorkflowDispatch *WorkflowDispatch `json:"workflow_dispatch,omitempty"`
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type Push struct {
|
|
|
|
|
Branches []string `json:"branches,omitempty"`
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type WorkflowDispatch struct {
|
|
|
|
|
Inputs map[string]InputSpec `json:"inputs,omitempty"`
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type InputSpec struct {
|
|
|
|
|
Description string `json:"description,omitempty"`
|
|
|
|
|
Required bool `json:"required,omitempty"`
|
|
|
|
|
Default string `json:"default,omitempty"`
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type Job struct {
|
2022-06-30 09:09:58 +09:00
|
|
|
RunsOn string `json:"runs-on"`
|
|
|
|
|
Container string `json:"container,omitempty"`
|
|
|
|
|
Steps []Step `json:"steps"`
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type Step struct {
|
|
|
|
|
Name string `json:"name,omitempty"`
|
|
|
|
|
Uses string `json:"uses,omitempty"`
|
|
|
|
|
With *With `json:"with,omitempty"`
|
|
|
|
|
Run string `json:"run,omitempty"`
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
type With struct {
|
2022-05-16 09:26:48 +09:00
|
|
|
Version string `json:"version,omitempty"`
|
|
|
|
|
GoVersion string `json:"go-version,omitempty"`
|
|
|
|
|
|
|
|
|
|
// https://github.com/docker/setup-buildx-action#inputs
|
|
|
|
|
BuildkitdFlags string `json:"buildkitd-flags,omitempty"`
|
|
|
|
|
Install bool `json:"install,omitempty"`
|
|
|
|
|
// This can be either the address or the context name
|
|
|
|
|
// https://github.com/docker/buildx/blob/master/docs/reference/buildx_create.md#description
|
|
|
|
|
Endpoint string `json:"endpoint,omitempty"`
|
2022-08-24 10:42:45 +09:00
|
|
|
// Needs to be "docker" in rootless mode
|
|
|
|
|
// https://stackoverflow.com/questions/66142872/how-to-solve-error-with-rootless-docker-in-github-actions-self-hosted-runner-wr
|
|
|
|
|
Driver string `json:"driver,omitempty"`
|
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
|
|
|
}
|