Home

Awesome

S3 Resource

Versions objects in an S3 bucket, by pattern-matching filenames to identify version numbers.

Source Configuration

File Names

One of the following two options must be specified:

Initial state

If no resource versions exist you can set up this resource to emit an initial version with a specified content. This won't create a real resource in S3 but only create an initial version for Concourse. The resource file will be created as usual when you get a resource with an initial version.

You can define one of the following two options:

By default the resource file will be created with no content when get runs. You can set the content by using one of the following options:

Behavior

check: Extract versions from the bucket.

Objects will be found via the pattern configured by regexp. The versions will be used to order them (using semver). Each object's filename is the resulting version.

in: Fetch an object from the bucket.

Places the following files in the destination:

Parameters

out: Upload an object to the bucket.

Given a file specified by file, upload it to the S3 bucket. If regexp is specified, the new file will be uploaded to the directory that the regex searches in. If versioned_file is specified, the new file will be uploaded as a new version of that file.

Parameters

Example Configuration

Resource

When the file has the version name in the filename

- name: release
  type: s3
  source:
    bucket: releases
    regexp: directory_on_s3/release-(.*).tgz
    access_key_id: ACCESS-KEY
    secret_access_key: SECRET

or

When the file is being versioned by s3

- name: release
  type: s3
  source:
    bucket: releases
    versioned_file: directory_on_s3/release.tgz
    access_key_id: ACCESS-KEY
    secret_access_key: SECRET

Plan

- get: release
- put: release
  params:
    file: path/to/release-*.tgz
    acl: public-read

Required IAM Permissions

Non-versioned Buckets

The bucket itself (e.g. "arn:aws:s3:::your-bucket"):

The objects in the bucket (e.g. "arn:aws:s3:::your-bucket/*"):

Versioned Buckets

Everything above and...

The bucket itself (e.g. "arn:aws:s3:::your-bucket"):

The objects in the bucket (e.g. "arn:aws:s3:::your-bucket/*"):

Development

Prerequisites

Running the tests

The tests have been embedded with the Dockerfile; ensuring that the testing environment is consistent across any docker enabled platform. When the docker image builds, the test are run inside the docker container, on failure they will stop the build.

Run the tests with the following command:

docker build -t s3-resource --target tests --build-arg base_image=paketobuildpacks/run-jammy-base:latest .
 .

Integration tests

The integration requires two AWS S3 buckets, one without versioning and another with. The docker build step requires setting --build-args so the integration will run.

Run the tests with the following command:

docker build . -t s3-resource --target tests \
  --build-arg S3_TESTING_ACCESS_KEY_ID="access-key" \
  --build-arg S3_TESTING_SECRET_ACCESS_KEY="some-secret" \
  --build-arg S3_TESTING_BUCKET="bucket-non-versioned" \
  --build-arg S3_VERSIONED_TESTING_BUCKET="bucket-versioned" \
  --build-arg S3_TESTING_REGION="us-east-1" \
  --build-arg S3_ENDPOINT="https://s3.amazonaws.com"
Speeding up integration tests by skipping large file upload

One of the integration tests uploads a large file (>40GB) and so can be slow. It can be skipped by adding the following option when running the tests:

  --build-arg S3_TESTING_NO_LARGE_UPLOAD=true
Integration tests using role assumption

If S3_TESTING_AWS_ROLE_ARN is set to a role ARN, this role will be assumed for accessing the S3 bucket during integration tests. The whole integration test suite runs either completely using role assumption or completely by direct access via the credentials.

Required IAM permissions

In addition to the required permissions above, the s3:PutObjectTagging permission is required to run integration tests.

Contributing

Please make all pull requests to the master branch and ensure tests pass locally.