{"action":"created","issue":{"url":"https://api.github.com/repos/concourse/rfcs/issues/7","repository_url":"https://api.github.com/repos/concourse/rfcs","labels_url":"https://api.github.com/repos/concourse/rfcs/issues/7/labels{/name}","comments_url":"https://api.github.com/repos/concourse/rfcs/issues/7/comments","events_url":"https://api.github.com/repos/concourse/rfcs/issues/7/events","html_url":"https://github.com/concourse/rfcs/issues/7","id":342769417,"node_id":"MDU6SXNzdWUzNDI3Njk0MTc=","number":7,"title":"(RF)RFC: reusable tasks","user":{"login":"vito","id":1880,"node_id":"MDQ6VXNlcjE4ODA=","avatar_url":"https://avatars1.githubusercontent.com/u/1880?v=4","gravatar_id":"","url":"https://api.github.com/users/vito","html_url":"https://github.com/vito","followers_url":"https://api.github.com/users/vito/followers","following_url":"https://api.github.com/users/vito/following{/other_user}","gists_url":"https://api.github.com/users/vito/gists{/gist_id}","starred_url":"https://api.github.com/users/vito/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vito/subscriptions","organizations_url":"https://api.github.com/users/vito/orgs","repos_url":"https://api.github.com/users/vito/repos","events_url":"https://api.github.com/users/vito/events{/privacy}","received_events_url":"https://api.github.com/users/vito/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2018-07-19T15:05:32Z","updated_at":"2019-03-13T13:21:54Z","closed_at":null,"author_association":"MEMBER","body":"(this is a rough draft/placeholder just to centralize brainstorming before an actual RFC)\r\n\r\nref. concourse/concourse#417\r\nref. concourse/docker-image-resource#185\r\n\r\nThere is clearly a need to make tasks just as easy to share, version, and re-use just as resources are.\r\n\r\nWhat would this look like?\r\n\r\nToday you can approximate this by storing task `.yml`s in a Git repo, and then pulling them in as a resource.\r\n\r\nOne big hole is configuration. You can only really specify `params`, which for tasks are environment variables. Lots of resources use `params` for arbitrary, sometimes nested config. Should we extend tasks to have the same ability? It would actually be pretty easy to just pass it to the script on `stdin`, just like we do for resources. (Would we then rename today's `params` to `env` or something to be more clear?)"},"comment":{"url":"https://api.github.com/repos/concourse/rfcs/issues/comments/472418975","html_url":"https://github.com/concourse/rfcs/issues/7#issuecomment-472418975","issue_url":"https://api.github.com/repos/concourse/rfcs/issues/7","id":472418975,"node_id":"MDEyOklzc3VlQ29tbWVudDQ3MjQxODk3NQ==","user":{"login":"itsdalmo","id":6603877,"node_id":"MDQ6VXNlcjY2MDM4Nzc=","avatar_url":"https://avatars3.githubusercontent.com/u/6603877?v=4","gravatar_id":"","url":"https://api.github.com/users/itsdalmo","html_url":"https://github.com/itsdalmo","followers_url":"https://api.github.com/users/itsdalmo/followers","following_url":"https://api.github.com/users/itsdalmo/following{/other_user}","gists_url":"https://api.github.com/users/itsdalmo/gists{/gist_id}","starred_url":"https://api.github.com/users/itsdalmo/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/itsdalmo/subscriptions","organizations_url":"https://api.github.com/users/itsdalmo/orgs","repos_url":"https://api.github.com/users/itsdalmo/repos","events_url":"https://api.github.com/users/itsdalmo/events{/privacy}","received_events_url":"https://api.github.com/users/itsdalmo/received_events","type":"User","site_admin":false},"created_at":"2019-03-13T13:21:54Z","updated_at":"2019-03-13T13:21:54Z","author_association":"NONE","body":"> I recognise that this goes against the idea of tasks being pure and side-effect-free, but I think the more important aspect has always been that they're idempotent, and I'm interested in seeing if this change in mindset leads to a more expressive reconfiguration of existing ideas.\r\n\r\nI think this RFC and some help for reusable tasks is necessary, but I think the distinction between a `task` and a `resource` becomes somewhat blurry in this case. Since resources and tasks are both meant to be idempotent, and both can have side-effects, what then is the distinction between a task and a resource?\r\n\r\nAnd what do we mean by idempotent here? Using `terraform` as an example, strictly speaking it is impossible for the task to be idempotent because the state-file is opaque to Concourse, and the true state is not known until terraform refreshes the state?\r\n\r\n>One thing I decided against with this mockup was having tasks provided by Docker images (a-la resource types). In analyzing my current use case and cf-deployment-concourse-tasks, I noticed that there tends to be more than one task using a given image. For example, my pipeline already has a case for both terraform apply and terraform output. Forcing those to be entirely separate images feels wasteful.\r\n\r\nA simple solution to the above would just be to pass `terraform apply` or `terraform output` as arguments to the task, which would then allow us to reuse the same image for multiple tasks. I think for tasks like `terraform apply` (which has potentially large side-effects) and other tasks where correctness is paramount, it makes the most sense if the task itself is responsible for setting defaults and validating the source configuration and parameters, instead of relying on a `task.yml` which may/may not get out of sync with the code (especially if the code is delivered as part of a docker image, in the case of e.g. compiled languages).\r\n\r\nI think this RFC is nice for shaping up tasks as they exist today, but I feel like we are still missing a solution for \"serious\" tasks as mentioned above. Essentially a resource which implements only `put`, which is today considered an anti-pattern, would be perfect for something like `terraform apply` and friends 🤔 "}}
{"actor":{"display_login":"itsdalmo"}}