{"action":"created","issue":{"url":"https://api.github.com/repos/concourse/concourse/issues/534","repository_url":"https://api.github.com/repos/concourse/concourse","labels_url":"https://api.github.com/repos/concourse/concourse/issues/534/labels{/name}","comments_url":"https://api.github.com/repos/concourse/concourse/issues/534/comments","events_url":"https://api.github.com/repos/concourse/concourse/issues/534/events","html_url":"https://github.com/concourse/concourse/issues/534","id":165446772,"number":534,"title":"New resource interface (+ add versioning)","user":{"login":"vito","id":1880,"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":[{"id":708929075,"url":"https://api.github.com/repos/concourse/concourse/labels/core/build-plan","name":"core/build-plan","color":"6eddcf","default":false},{"id":708907029,"url":"https://api.github.com/repos/concourse/concourse/labels/core/flow","name":"core/flow","color":"6eddcf","default":false},{"id":765827297,"url":"https://api.github.com/repos/concourse/concourse/labels/enhancement","name":"enhancement","color":"84b6eb","default":true}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":45,"created_at":"2016-07-13T23:47:54Z","updated_at":"2018-03-02T12:40:40Z","closed_at":null,"author_association":"OWNER","body":"## Proposed changes\r\n\r\n1. Rename `in` and `out` scripts to `get` and `put`. These are confusingly named something different because a long time ago jobs just had _in_puts and _out_puts.\r\n1. Run `./check`, `./get`, and `./put`, and `./info` (see next point) rather than `/opt/resource/X`. Having them in `/opt` is a bit Linux-specific and assumes containers have their own `chroot`, which is not the case on Darwin or Windows.\r\n1. Add a `info` script which prints the resource's API version, e.g. `{\"version\":\"2.0\"}`. This will start at `2.0`. If `/info` does not exist we'll execute today's resource interface behavior.\r\n1. Change `get` to not emit the version or metadata. This was from when `in` didn't know what it was fetching until it was done. It should now be an error if it can't fetch the requested version. We'll also move all metadata collection to `check` (see point 8).\r\n1. Add a `delete` action, which looks like `put` (can be given files and params to determine what to delete) but returns the set of versions that it deleted. This is to support bulk deletes, e.g. to garbage collect intermediate artifacts after a final build is shipped.\r\n1. Remove the `source` and `destination` arguments passed to `get` and `put` - just make it the working directory.\r\n1. Give `check` an official scratch space, which is the current working directory. No real semantics change here, just consistency with `get` and `put`, and potential for future behavior like reusing the scratch space but not reusing `check` containers for extended periods. *Note: we've introduced `/scratch` recently so this change may just mean making that the work-dir.*\r\n1. Move all metadata emitting to `check`, so that it's always present. The original thought was that metadata collection may be expensive, but so far we haven't seen that to be the case.\r\n1. Change `put` to emit an array of versions, rather than just one, and without metadata. Technically the `git` resource may push many commits, so this is necessary to track them all as outputs of a build. This could also support batch creation. Notably, the versions emitted by `put` are ordered chronologically, so that the dependent `get` knows to fetch the latest version. We would save them internally, along with an association with the build, and rely on `check` to determine the final ordering and metadata, being careful to not leave gaps in the version history (i.e. other commits pushed slightly before the `put` registered the build's).\r\n1. Change `put` to write to a specified file, rather than `stdout`, so that we don't have to be attached to process its response. This is one of the few ways a build can error after the ATC reattaches (`unexpected end of JSON`). With it written to a file, we can just try to read the file when we re-attach after seeing that the process exited. This also frees up stdout/stderr for normal logging, which has been an occasional pitfall during resource development/debugging.\r\n1. Remove the distinction between `source` and `params`; resources will receive a single `config`. The distinction will remain in the pipeline. This makes it easier to implement a resource without planning ahead for interesting dynamic vs. static usage patterns, and will get more powerful with #684."},"comment":{"url":"https://api.github.com/repos/concourse/concourse/issues/comments/369910702","html_url":"https://github.com/concourse/concourse/issues/534#issuecomment-369910702","issue_url":"https://api.github.com/repos/concourse/concourse/issues/534","id":369910702,"user":{"login":"headcr4sh","id":196779,"avatar_url":"https://avatars2.githubusercontent.com/u/196779?v=4","gravatar_id":"","url":"https://api.github.com/users/headcr4sh","html_url":"https://github.com/headcr4sh","followers_url":"https://api.github.com/users/headcr4sh/followers","following_url":"https://api.github.com/users/headcr4sh/following{/other_user}","gists_url":"https://api.github.com/users/headcr4sh/gists{/gist_id}","starred_url":"https://api.github.com/users/headcr4sh/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/headcr4sh/subscriptions","organizations_url":"https://api.github.com/users/headcr4sh/orgs","repos_url":"https://api.github.com/users/headcr4sh/repos","events_url":"https://api.github.com/users/headcr4sh/events{/privacy}","received_events_url":"https://api.github.com/users/headcr4sh/received_events","type":"User","site_admin":false},"created_at":"2018-03-02T12:40:40Z","updated_at":"2018-03-02T12:40:40Z","author_association":"NONE","body":"I was thinking about a new resource interface for quite some time now and I wanted to throw in a bunch ideas that came into my mind:\r\n\r\n#### Docker tags\r\nSince all resource_types are (right now?) basically docker images, it might make sense to use Docker labels to attach some metadata to docker images that can be used as Concourse resources. This would open up a few possibilities, e.g. having a \"Concourse Resource Registry\" that can be used to automatically list resources\r\n\r\nPossible tags:\r\n```\r\nci.concourse.resource.version=2\r\nci.concourse.resource.actions=check,in,out (or check, get, put delete, whatever... in the future...)\r\nci.concourse.resource.description=\"A dummy resource that does nothing\"\r\nci.concourse.resource.documentation=[link to documentation]\r\nci.concourse.resource.author=\"John Doe <j.doe@example.com>\r\n```\r\n\r\n#### JSON schema\r\nAn embedded schema that is part of any resource that can be used to validate the source- and params- configuration would be really neat. I think that JSON schema might be used to do that job quite nicely (http://json-schema.org/)\r\n\r\n*Advantages*:\r\n* JSON schema can be used to document the resource configuration parameters\r\n* JSON schema can be used by Editor/IDE plugins to perform validation (mandatory vs. optional fields, regex and field type constraints, etc., etc...) and show useful hints while editing (the current VSCode Concourse plugin only shows hints and tips for well-known resources)\r\n* JSON schema is a pretty solid tech and implementations for all major programming languages (including Go) seem to exist.\r\n* JSON schema can be used to extract the documentation for a resource\r\n\r\nSince Docker label values can contain any arbitrary text of any length, it *might* be a possibility to embed the schema(s) into the resource docker images by associating them with well known tag values (but I think that might be a bit complicated)\r\n\r\n\r\n\r\nJust my 2 cents."}}
{"actor":{"display_login":"headcr4sh"}}