Plugins: Testing / Validation and CI/CD
- Dominant language
- Python
- Stars
- 37
- Forks
- 9
- PR merge metrics
- No merged PRs in 30d
Description
Idea: Each plugin will require a validate script (called validate or startup) in the plugin folder. When BitOps starts, we iterate through each folder and run each script. It could be nothing more than a simple `echo Plugin xyz found` but this allows for more complex scripts if required.
These scripts can validate that the plugin is installed. It also allows for more complex checks when starting.
For Example, AWS might start by running something like `printenv | grep ^AWS` which gets the environmental variables for AWS. If there are variables, then we can do things like validate the user, or even calculate other values.
Other plugins might do something like `terraform --version`
## Updated: Testing Checklist
- [x] Env validation on plugin runtime
- [x] terraform
- [x] helm
- [x] ansible
- [ ] aws
- [ ] DECIDE: cmd in `install.sh` vs `test.sh` vs testing framework
- [ ] enforce the standard across all the plugins
- [ ] Check the artifacts' existence
- [ ] CI/CD for each plugin
- [ ] PR run
- [ ] cron/weekly run
- [ ] based on latest `plugins-base` image
- [ ] idempotence
Contributor guide
Research direction
Start by reviewing each plugin folder and the existing install.sh/test.sh choices, then inspect the plugins-base image context mentioned in the checklist. Compare the current terraform, helm, and ansible validation coverage with the unchecked AWS, artifact, CI/CD, cron, PR, and idempotence items. Done means the command convention and testing approach are decided and the remaining validation and CI/CD checks are covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ansible, aws, helm, terraform
- Domain
- ci-cd, cloud, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100