0.11.1

Bug Fixes

v0.11.0 introduced an events.json file. As noted in #35, information in this file was not complete; it left out the critical event type and event type version fields due to a misunderstanding about Concourse's data types for events.

This version fixes the bug.

Breaking Changes

The structure of entries in the events array inside events.json has changed.

An entry that previously looked like this:

{"time":1538845130,"origin":{"id":"5bb8df9a","source":"stderr"},"payload":"c018b674c414: Pull complete\n"}

Now looks like this:

{"data":{"time":1538845130,"origin":{"id":"5bb8df9a","source":"stderr"},"payload":"c018b674c414: Pull complete\n"},"event":"log","version":"5.1"} 

The key changes are:

1. The original toplevel object is now the value of the data key
2. event is added, its value is the event type
3. version is added, its value is the event type version

After these changes, the JSON objects have the same format as the objects sent by Concourse.

0.11.0

New Features

This release introduces one new feature: writing an events.json file (#20).

Embedded in the file is an events array, which is constructed from the build event stream. This is not super useful for humans. But the event stream carries useful additional information, including task/get/put completion timestamps and the metadata of resources that have been put.

If you are extracting logs for human use, stick to events.log. Same too for feeding to tools that analyse or parse plain text logs. But if you want to do something more structured, and are prepared to accept the risk of shifting and unsupported JSON structures, events.json might be for you.

0.10.1

Breaking Changes

The structure of the JSON inside versioned_resource_types.json has been switched from an array to an object.

Considering I only introduced that feature in the last few hours, I don't expect many breakages. But it's the principle of the thing.

Bug Fixes

To fix #34, the structure of the JSON has been altered to an object containing the array of versioned resource types.

0.10.0

New Features

This release introduces two new features.

UUIDs for injected metadata

In previous releases the resource began to inject metadata about itself and its execution into the data it writes out. This is intended to make it easier to understand the provenance of collected information.

But it this still left open the possibility of collisions between the data recorded in two different gets. Unlikely, but possible.

As of this release, the resource now injects a UUID alongside the other data.

versioned_resource_types.json

As noted in #32, the resources.json file has a curious mix of information: inputs get luxury treatment but outputs are incompletely specified.

Some of this information is available from another endpoint, which is now written out as versioned_resource_types.json. This is not a perfect solution, but it's better than going entirely without.

0.9.1

Bugfixes

In v0.8.0 I claimed that I had completed #22 and I was giving you version metadata. This was mostly true, but what you got was the -rc version number. Each release image always had a corresponding -rc image, so in some sense this was usable. But very confusing.

This release changes no code, but is triggered by rearranged pipeline.

0.9.0

New Features

This release introduces three new features.

job.json and friends

It turns out, I wasn't scraping everything about a build. There's an endpoint which describes the Job. A lot of the information is redundant with build, resources and plan, but the job adds key information: whether an input triggers and what the passed jobs lead to the current job.

Concourse version

You may wish to retrieve builds more than once. In addition to metadata introduced in v0.8.0, the resource now also retrieves the remote Concourse version as metadata.

Stripping trailing slashes from Concourse URL

If you provided https://example.com/ to previous releases, things would break in hard-to-understand ways. The resource now removes the trailing / when present.

0.8.0

New Features

This release introduces metadata injection.

The resource will now inject version and timestamp information into the JSON files it produces, so that you can see which version of the resource collected a build and (approximately) when it happened.

There are also files written to disk with this metadata.

Bug Fixes

The business of collecting build IDs from Concourse is now based on the API's pagination system. This hopefully removes a certain amount of jankiness, especially when using initial_build_id.

Breaking Changes

Existing K-V files (eg, build-1234.json) are no longer using kebab-case. They are now all snake_case (eg, build_1234.json) for consistency and improved readability in the team_pipeline-name_job-name_123.json case.

0.7.1

This patch release fixes #21.

0.7.0

New features

This release introduces initial_build_id and fetch_page_size configuration options, intended to give finer-grained control of version selection.

0.6.0

New features

Additional K-V files

This version introduces additional K-V files for various URLs associated with the build:

• concourse_url
• team_url
• pipeline_url
• job_url
• build_url

Version-pinned utility task YAML

All utility task YAML is now pinned to a particular release version. Previously, it was possible to pull a release image (eg. v0.5.0) that would not work with the HEAD of this repository when checked out to access the utility task YAML.

All task YAML now includes tag: configuration to ensure that, if you check out the repository directly from master, you will get a tested version of the tasks.

Breaking changes

1. The url file is longer created during get. This information is now in build_url.
2. Several other files were renamed for consistency:

• global-number -> global_number
• job-number -> job_number
• started-time -> started_time
• ended-time -> ended_time

3. Version metadata only includes the full build URL. It no longer includes team, pipeline or job names.