kubesphere / kubesphere/ks-devops
E2E testing check list
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 164
- Forks
- 140
- PR merge metrics
- No merged PRs in 30d
Description
What is it / Why we need it?
E2E testing is when we validate our entire ks-devops application from start to finish, along with any of its dependencies.
In E2E testing, we create an environment identical to the one that will be used by real users. Then we test all actions that our users might perform on ks-devops.
Check list
Priority from top to bottom.
- #342
- #349
- #347
- #350
- Run E2E testing after nightly build.
- Provide
/ok-to-e2e-testcommand to run E2E testing. - Create an issue if E2E testing failed
- Migrate E2E testing from GitHub action to KubeSphere DevOps.
/kind feature
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by reviewing the existing E2E testing setup and the unchecked checklist items, then determine how nightly builds, the /ok-to-e2e-test command, failure issue creation, and migration to KubeSphere DevOps should be coordinated. Done means the remaining checklist items are implemented and verified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- ci-cd, devops, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100