{"action":"created","issue":{"url":"https://api.github.com/repos/openshift/sti-ruby/issues/89","labels_url":"https://api.github.com/repos/openshift/sti-ruby/issues/89/labels{/name}","comments_url":"https://api.github.com/repos/openshift/sti-ruby/issues/89/comments","events_url":"https://api.github.com/repos/openshift/sti-ruby/issues/89/events","html_url":"https://github.com/openshift/sti-ruby/pull/89","id":124646444,"number":89,"title":"WIP: Allow users to specify what command to run tests","user":{"login":"mfojtik","id":44136,"avatar_url":"https://avatars.githubusercontent.com/u/44136?v=3","gravatar_id":"","url":"https://api.github.com/users/mfojtik","html_url":"https://github.com/mfojtik","followers_url":"https://api.github.com/users/mfojtik/followers","following_url":"https://api.github.com/users/mfojtik/following{/other_user}","gists_url":"https://api.github.com/users/mfojtik/gists{/gist_id}","starred_url":"https://api.github.com/users/mfojtik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mfojtik/subscriptions","organizations_url":"https://api.github.com/users/mfojtik/orgs","repos_url":"https://api.github.com/users/mfojtik/repos","events_url":"https://api.github.com/users/mfojtik/events{/privacy}","received_events_url":"https://api.github.com/users/mfojtik/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2016-01-03T12:30:50Z","updated_at":"2016-01-04T03:19:23Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/openshift/sti-ruby/pulls/89","html_url":"https://github.com/openshift/sti-ruby/pull/89","diff_url":"https://github.com/openshift/sti-ruby/pull/89.diff","patch_url":"https://github.com/openshift/sti-ruby/pull/89.patch"},"body":"This PR will allow to specify what command to run as a \"test\" command by setting the `RUN_TEST` variable.\r\n\r\nThe command specified by this environment variable will be executed by the `assemble` script when installed all dependencies. If this variable is set and it fails (returns non-zero) the assemble will fail.\r\n\r\nFor the S2I this variable can be specified by using the command line `-e RUN_TEST=\"bundle exec rake test\" ` in OpenShift you can specify this in the `BuildConfig` as any other environment variable.\r\nIn OpenShift, when the test fail, the image will not be produced.\r\n\r\nThis also allows to pass any additional variable to the build to customize the test run ($RUN_TEST pick up any variable specified for `assemble`)."},"comment":{"url":"https://api.github.com/repos/openshift/sti-ruby/issues/comments/168571151","html_url":"https://github.com/openshift/sti-ruby/pull/89#issuecomment-168571151","issue_url":"https://api.github.com/repos/openshift/sti-ruby/issues/89","id":168571151,"user":{"login":"bparees","id":4974046,"avatar_url":"https://avatars.githubusercontent.com/u/4974046?v=3","gravatar_id":"","url":"https://api.github.com/users/bparees","html_url":"https://github.com/bparees","followers_url":"https://api.github.com/users/bparees/followers","following_url":"https://api.github.com/users/bparees/following{/other_user}","gists_url":"https://api.github.com/users/bparees/gists{/gist_id}","starred_url":"https://api.github.com/users/bparees/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bparees/subscriptions","organizations_url":"https://api.github.com/users/bparees/orgs","repos_url":"https://api.github.com/users/bparees/repos","events_url":"https://api.github.com/users/bparees/events{/privacy}","received_events_url":"https://api.github.com/users/bparees/received_events","type":"User","site_admin":false},"created_at":"2016-01-04T03:19:23Z","updated_at":"2016-01-04T03:19:23Z","body":"> So then the follow up question for scenario 1 is - why would scenario 1 be specified (to a consumer of openshift) differently than scenario 2? Does the user actually care, as long as they can easily run their tests?\r\n\r\nI suppose it doesn't have to be, you're just saying \"implement scenario 2, but if they're doing an s2i build, optimize it by running tests in the build container instead of committing the container first and running the new image\".  Which we can start by just implementing the generic solution and then adding the s2i optimization (as discussed for scenario 1) later.\r\n\r\nbtw, scenario 2 sure sounds like build-hooks to me, but we previously concluded we didn't want to implement build-hooks (https://trello.com/c/Sk3aSNxG/516-13-build-lifecycle-hooks).  Do we think we now have a valid use case for a post-build-hook (similar to a post-deploy-hook except this would potentially fail the build if it fails, and prevent pushing the image)."}}