Closed gabemontero closed 7 years ago
@gabemontero why isn't the existing test origin images command sufficient for this? This is what we already run when we do the jenkins PR testing and jenkins image build/push:
if the goal is to build a jenkins image from locally build plugins, it's not clear to me how this accomplishes that.
@bparees what I've provided here is for "pre PR" testing, when you want to work with your own AWS instance and say synchronize changes from your laptop to that instance and test there.
In the case of the 32 bit support for example, it allowed me to tinker with the Dockerfile.rhel7 file on my laptop and initiate tests on my AWS instance, vs. having to edit the files on my AWS instance and then bringing those changes back to my laptop prior before I say actually submit a PR. Certainly I could have done all my "unit testing" via PR, but found working with my own AWS instance a nicer experience.
Also, to clarify, there are no changes wrt plugins in this particular PR, but I did derive some ideas around potential future PRs to vagrant-openshift to facilitate PR test jobs for the plugins.
Ultimately, I'm thinking we might be able to have options on our PR tests for https://github.com/openshift/jenkins that say exercise our extended tests for the plugin(s), so when we say bump the version of one of the plugins in base-plugin.txt file, we can initiate our openshift based plugin tests at that point.
seems like we ought to be able to extend test_origin_image.rb to allow testing from a local dir, rather than adding specific logic for jenkins for this. (I'm also not sure how much value it adds over just ssh'ing into the machine and running make test on the local repo after syncing the code. I can see the value in adding the repo sync).
The sync is certainly the higher value of the options. I added build/test for at least more consistency with origin, source-to-image, etc. (as I mentioned initially I already omitted download*, so it is not fully consistent).
I'm amenable to just removing the build/test options and just leaving sync in if that is the consensus with everyone.
OK I've pruned the change to just add the sync.
On Wed, Feb 1, 2017 at 4:33 PM, Steve Kuznetsov notifications@github.com wrote:
@stevekuznetsov commented on this pull request.
In lib/vagrant-openshift/action.rb https://github.com/openshift/vagrant-openshift/pull/530:
@@ -153,6 +153,18 @@ def self.repo_sync_sti(options) end end
- def self.repo_sync_jenkins(options)
In August we furthermore made the choice not to invest time in making vagrant-openshift better but instead in focusing development time on the origin-ci-tool. We are set to see oct make it's debut in supporting Origin PR tests this sprint. The tool provides oct sync which aims to provide the generic functionality we need.
Knew about the first part but did not know oct
was this close, and
assumed we were still in that more nebulous state wrt vagrant-openshift.
I'm fine with deferring here and looking into origin-ci-tool
and oct
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openshift/vagrant-openshift/pull/530, or mute the thread https://github.com/notifications/unsubscribe-auth/ADbadBXr3D3elUPPbJ6BqftzbnxVOJ6Yks5rYPoogaJpZM4L0QSh .
@danmcp @stevekuznetsov @bparees fyi / ptal
This allows for some minimal build/sync/test of the openshift jenkins rhel7 image. download artifacts seemed like a no-op for this particular scenario.
@bparees - fyi this foray, in addition to facilitating say 32 vs. 64 bit jenkins, gave me some better exposure into what we might want to do longer term for plugin testing (including client and sync in addition to pipeline and long) from ci.openshift.