{"action":"opened","issue":{"url":"https://api.github.com/repos/deis/jenkins-jobs/issues/174","repository_url":"https://api.github.com/repos/deis/jenkins-jobs","labels_url":"https://api.github.com/repos/deis/jenkins-jobs/issues/174/labels{/name}","comments_url":"https://api.github.com/repos/deis/jenkins-jobs/issues/174/comments","events_url":"https://api.github.com/repos/deis/jenkins-jobs/issues/174/events","html_url":"https://github.com/deis/jenkins-jobs/issues/174","id":168683650,"number":174,"title":"Component release e2e strategy","user":{"login":"vdice","id":9322017,"avatar_url":"https://avatars.githubusercontent.com/u/9322017?v=3","gravatar_id":"","url":"https://api.github.com/users/vdice","html_url":"https://github.com/vdice","followers_url":"https://api.github.com/users/vdice/followers","following_url":"https://api.github.com/users/vdice/following{/other_user}","gists_url":"https://api.github.com/users/vdice/gists{/gist_id}","starred_url":"https://api.github.com/users/vdice/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vdice/subscriptions","organizations_url":"https://api.github.com/users/vdice/orgs","repos_url":"https://api.github.com/users/vdice/repos","events_url":"https://api.github.com/users/vdice/events{/privacy}","received_events_url":"https://api.github.com/users/vdice/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-08-01T16:11:12Z","updated_at":"2016-08-01T16:11:12Z","closed_at":null,"body":"https://github.com/deis/jenkins-jobs/issues/158 rolled out the initial iteration of a component release pipeline.  The e2e stage of this pipeline simply retrieved the last released `workflow-<release>` chart, plugged in the release candidate for its respective component docker tag and ran that against the `workflow-<release>-e2e` chart.\r\n\r\nThe drawback to this approach is other components may have released in the interim since the last released workflow chart.  For the most accurate test results, we would want an up-to-date `workflow` chart wherein all components' docker tags are the very latest semver tags straight from git or image registry.  \r\n\r\nTo save manual effort from having to look up each component's latest semver tags, a corresponding tool would need to be made (perhaps in https://github.com/deis/deisrel) that could ping either the GitHub API or Quay.io/DockerHub API to derive each component's latest semver tag and produce the chart used for testing..."}}
{"actor":{"display_login":"vdice"}}