{"action":"created","issue":{"url":"https://api.github.com/repos/DBuildService/dock/issues/85","labels_url":"https://api.github.com/repos/DBuildService/dock/issues/85/labels{/name}","comments_url":"https://api.github.com/repos/DBuildService/dock/issues/85/comments","events_url":"https://api.github.com/repos/DBuildService/dock/issues/85/events","html_url":"https://github.com/DBuildService/dock/issues/85","id":73930082,"number":85,"title":"Proposal: redesign dock","user":{"login":"TomasTomecek","id":1662493,"avatar_url":"https://avatars.githubusercontent.com/u/1662493?v=3","gravatar_id":"","url":"https://api.github.com/users/TomasTomecek","html_url":"https://github.com/TomasTomecek","followers_url":"https://api.github.com/users/TomasTomecek/followers","following_url":"https://api.github.com/users/TomasTomecek/following{/other_user}","gists_url":"https://api.github.com/users/TomasTomecek/gists{/gist_id}","starred_url":"https://api.github.com/users/TomasTomecek/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TomasTomecek/subscriptions","organizations_url":"https://api.github.com/users/TomasTomecek/orgs","repos_url":"https://api.github.com/users/TomasTomecek/repos","events_url":"https://api.github.com/users/TomasTomecek/events{/privacy}","received_events_url":"https://api.github.com/users/TomasTomecek/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-05-07T10:19:22Z","updated_at":"2015-05-11T08:08:06Z","closed_at":null,"body":"For quite some time, I think that dock's CLI, code and architecture is getting a bit messy. This is my proposal how we could improve it. We'll have a single command for building images, which will be `build`.\r\n\r\n### Build Types\r\n\r\n`build` will have subcommands called **build types** (there will be a default build type). We'll probably start with just one build type which will precisely match the current behaviour. Build types will be very similar to what osbs-client has. Build types will be predefined recipes how to build an image (and what plugins should be used) — json templates. Every build type will have a set of its own arguments. Most build types will have similar arguments e.g. `--image`.\r\n\r\nWe could possibly even improve the json to something like:\r\n\r\n```json\r\n{\r\n  \"input\": {\r\n    \"type\": \"path\",\r\n    \"args\": {\r\n        \"path\": \"/here/is/my/dockerfile\"\r\n    },\r\n    \"source_repository\": \"...\"\r\n  },\r\n  \"output\": {\r\n    \"tag\": {\r\n      \"value\": \"...\",\r\n      \"repositories\": [...]\r\n    }\r\n  },\r\n  \"plugins\": ...\r\n```\r\n\r\n### Methods\r\n\r\nMethods will work the same:\r\n\r\n1. `--method privileged`\r\n2. `--method docker-host` (every occurrence of `host.?docker` will be changed)\r\n3. `--method local` (`dock local` could be symlink to `dock build --method local`)\r\n\r\n### Input\r\n\r\nWhen you specify build json on your own, build type will be ignored. You may be still able to override values in your json from CLI.\r\n\r\n`--input` will be direct mapping for input plugins (getting build json from env var, path,...). You'll be able to override this via CLI.\r\n\r\n\r\nIf you don't care about code, you can stop reading.\r\n\r\nIn code, I would like to have a lot of changes too:\r\n * start getting rid of `DockerBuildWorkflow` and moving logic to plugins\r\n * `InsideBuilder` should be as light as possible\r\n * I would like to see more classes rather than having one class accepting 15 arguments\r\n * we need to figure what will be the best interface to configure plugins from CLI (`--substitute` might be enough)\r\n\r\n\r\nCC @goldmann @mmilata @twaugh @jpopelka @l-d-j @adamruzicka\r\n\r\nI really would like to hear your feedback on this.\r\n"},"comment":{"url":"https://api.github.com/repos/DBuildService/dock/issues/comments/100807544","html_url":"https://github.com/DBuildService/dock/issues/85#issuecomment-100807544","issue_url":"https://api.github.com/repos/DBuildService/dock/issues/85","id":100807544,"user":{"login":"l-d-j","id":568838,"avatar_url":"https://avatars.githubusercontent.com/u/568838?v=3","gravatar_id":"","url":"https://api.github.com/users/l-d-j","html_url":"https://github.com/l-d-j","followers_url":"https://api.github.com/users/l-d-j/followers","following_url":"https://api.github.com/users/l-d-j/following{/other_user}","gists_url":"https://api.github.com/users/l-d-j/gists{/gist_id}","starred_url":"https://api.github.com/users/l-d-j/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/l-d-j/subscriptions","organizations_url":"https://api.github.com/users/l-d-j/orgs","repos_url":"https://api.github.com/users/l-d-j/repos","events_url":"https://api.github.com/users/l-d-j/events{/privacy}","received_events_url":"https://api.github.com/users/l-d-j/received_events","type":"User","site_admin":false},"created_at":"2015-05-11T08:08:06Z","updated_at":"2015-05-11T08:08:06Z","body":"this sounds great for me. I like the idea of one build command and custom recipes defining flow also with this approach dock can be used with rkt in future (if \"docker build\" will be plugin also). \r\nBut this sounds little bit like general build tool similar to maven. If I map new dock plugins to phases then recipe file seems like pom.xml without many features. I don't know python ecosystem well but  maybe there is a some \"build tool/simple workflow\" management library we should extend same way?\r\nBecause in this approach a dock seems like a recipe runner which passes some instance object to plugins(to make them communicate) and execute them in a right order.\r\n\r\n\r\n"}}