Skip to content

Conversation

@phillbaker
Copy link

Similar to #14, adds an option to the params to skip any downloading on a put - there's usually no need for this as it's immediately discarded and results in additional bandwidth.

Example usage:

resources:
- name: <resource name>
  type: <resource type name>
  source:
    access_key_id: {{aws-access-key}}
    secret_access_key: {{aws-secret-key}}
    bucket: {{aws-bucket}}
jobs:
- name: <job name>
  plan:
  - put: <resource name>
     params:
       skip_download: true

Example usage:
```
resources:
- name: <resource name>
  type: <resource type name>
  source:
    access_key_id: {{aws-access-key}}
    secret_access_key: {{aws-secret-key}}
    bucket: {{aws-bucket}}
jobs:
- name: <job name>
  plan:
  - put: <resource name>
     params:
       skip_download: true
```
@afeld
Copy link
Contributor

afeld commented Apr 26, 2017

Sorry for the slow response. I like it for efficiency's sake, but don't love the additional complexity, variance in behavior, or additional option that we need to explain to the user. @LinuxBozo Thoughts?

@LinuxBozo
Copy link
Contributor

Ok, if I'm understanding correctly, this option is solely useful for when doing a put on the resource, since the Concourse lifecycle does a get right after a put to verify that it receives the same "version" that it just placed. In most cases where you don't care, you can do a no-op, which is the intent here it appears. Unfortunately, by using the params to a put, the get/in has no clue about this param, so it would have no effect. See: vmware-archive/atc#72

@phillbaker
Copy link
Author

Hm, thanks for the link @LinuxBozo, I'm not sure how, but it is working 😀 .

screen shot 2017-04-27 at 1 12 40 pm

In my mind this parallels the skip_download on the official docker image resource, which was worth an optional parameter.

I'll close this PR for now and if there're other folks interested we can re-open. Thanks!

@da1nerd
Copy link

da1nerd commented Sep 24, 2018

I think this would be a valuable feature. We have a server set up that is generating builds for all of our github branches which we cache for 30 days. Right now this resource is needlessly downloading 65GB of data my pipeline will never use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants