PR testing "common pattern" #397
Replies: 5 comments
-
What I did to accomplish some testing was; I created a Pro:
Con:
|
Beta Was this translation helpful? Give feedback.
-
Yes, you definitely want to build a new image if the plugin installation steps changed (ansible/terraform version, new tools, etc). The alternative would be to specify the plugin dir (or repo w branch) to share with the BitOps container. |
Beta Was this translation helpful? Give feedback.
-
Here is a comparison. If you have a WIP PR in the plugin repo (like bitops-plugins/terraform#23), and push to that branch while iterating. 1. Workflow with BitOps Image rebuildIn this scenario for every new changed line of code in the plugin you have to rebuild the Docker image, wait for tools re-installation, docker build-> deploy. If it's not a one-time change (the majority of the work is more than that), then there's a lot of waiting time. There's also a need to open a PR in the BitOps repo that'll run some workflow for deploying and WIP plugin branch which is likely not relevant to the prod. So we have 3 places for context-switch: Plugin repo, BitOps repo + Docker images, GHA repo 2. Workflow with Plugin path sharingIn this scenario, you add the logic to git clone the plugin repo with the WIP branch, share it with the BitOps container, and re-run the workflow in the GHA repo. The downside is that additional logic needs to be added to clone stuff and share dir and then cleanup GHA deploy.sh once everything looks good. You'll normally get faster results with the path-sharing approach rather than image rebuild. |
Beta Was this translation helpful? Give feedback.
-
3. Random idea with
|
Beta Was this translation helpful? Give feedback.
-
Just tested with the Example
It's much easier than rebuilding a BitOps image or sharing the docker volumes as it allows to shortcut several operations in between. |
Beta Was this translation helpful? Give feedback.
-
As per our internal Slack discussion
I'd like to come to consensus on how a developer can test a bitops plugin within an github action workflow.
The challenge is;
Currently BitOps branches do not create test images/tags, as a result, it is difficult to test changes to a plugin in a github workflow. For example, if a change is proposed for Terraform, and a PR is created, how could we test the PR?
There isn't a straight forward answer today and there is no documentation to guide others.
Beta Was this translation helpful? Give feedback.
All reactions