It seems like, with GitHub Actions, we should be able to spin up a target container in CI, have it enable an SSH server, and then run the bd command using that host as a target. Given that we can SSH in, we should be able to validate the effects of having run bd deployments.
The question of having a repository to clone, getting access to it, etc., for the purposes of integration tests comes up. I think it might just be that cloning from bare git repos inside the container would suffice.
I seem to recall having a libgit-style test fixture thing back in ~2013 when I worked at GitHub, where one could programmatically express creating a "fixture" git repo. Anyway, if we create "fixture repos" here in, e.g., spec/fixture_repos, then we can scp that tree to the container, and set the --repo arg to point to the local path in question, and then run the bd deploy and verify the results.
I seem to recall that it was a pain having a .git in a fixture repo down inside a repo, so there's a case to be made for packaging up fixtures via (say) tar for storage, and generating them from a readable fixture language.
the work
[x] cleanup: move bd_command helpers to main spec_helper.rb file
[x] research: can I find the libgit-style git wrapper for readable repo creation?
It seems like, with GitHub Actions, we should be able to spin up a target container in CI, have it enable an SSH server, and then run the
bdcommand using that host as a target. Given that we can SSH in, we should be able to validate the effects of having runbddeployments.The question of having a repository to clone, getting access to it, etc., for the purposes of integration tests comes up. I think it might just be that cloning from bare git repos inside the container would suffice.
I seem to recall having a libgit-style test fixture thing back in ~2013 when I worked at GitHub, where one could programmatically express creating a "fixture" git repo. Anyway, if we create "fixture repos" here in, e.g.,
spec/fixture_repos, then we can scp that tree to the container, and set the--repoarg to point to the local path in question, and then run thebddeploy and verify the results.I seem to recall that it was a pain having a
.gitin a fixture repo down inside a repo, so there's a case to be made for packaging up fixtures via (say)tarfor storage, and generating them from a readable fixture language.the work
bd_commandhelpers to mainspec_helper.rbfiledocker-compose, go back and look at thatopen3require tospec_helper.rb, as this was missed earlier--localarg being passed (missed this)cc #4