« Changelog History


concourse v6.3.0 Release Notes

Release Date: 2020-06-11 // almost 4 years ago

  • 🍱 🔗 feature

    🚀 After switching the default resource checking component to be lidar during the v6.0.0 release, users have noticed the resource checking rate has been very spiky. This spiky behaviour is caused by the fact that lidar runs all the checks that have been queued up at once, causing the spikes of checks to happen all at the same time when the checker runs on its interval.

    We added a rate limit to resource checking in order to help spread out the rate of checks. Before, without the rate limit resource checking was like .|.|.|.| and now it's like ~~~~~~~.

    0️⃣ This rate limit is defaulted to be determined by calculating the number of checkables (resources and resource types) that need to be checked per second in order to check everything within the default checking interval. This means that if there are 600 checkables and the default checking interval is 60 seconds, we would need to run 10 checks per second in order to check everything in 60 seconds. This rate limit of checks can be modified through the max-checks-per-second flag to be a static number and also turned off by setting it to -1.

    0️⃣ On top of adding a rate limit, we also changed the default for the lidar-scanner-interval to be 10 seconds rather than the previous default of 1 minute. This will also help spread out the number of checks to happen on more intervals of the checker. #5676

    🚀 When we upgraded our large deployment to v6.3.0 with the default rate limiter on resource checking, we saw that the number of checks started became much more spread out when compared to before. This first metric shows the number of resource checks started per minute before v6.3.0.

    The following metric shows the number of checks started per minute after adding the rate limiting.

    🍱 🔗 feature

    • ⏱ When distributed tracing is configured, Concourse will now emit spans for several of its backend operations, including resource scanning, check execution, and job scheduling. These spans will be appropriately linked when viewed in a tracing tool like Jaeger, allowing operators to better observe the events that occur between resource checking and build execution. #5659

    🍱 🔗 feature

    🔧 When distributed tracing is configured, all check, get, put, and task containers will be run with the TRACEPARENT environment variable set, which contains information about the parent span following the w3c trace context format:

    TRACEPARENT=version-trace_id-parent_id-trace_flags

    👍 Using this information, your tasks and custom resource_types can emit spans to a tracing backend, and these spans will be appropriately linked to the step in which they ran. This can be particularly useful when integrating with downstream services that also support tracing. #5653

    🍱 🔗 feature

    • 🔧 The set_pipeline step now supports vars within its plan configuration (the file:, vars:, and var_files: fields), thanks to @evanchaoli! #5277

    🍱 🔗 feature

    • ⏱ When the scheduler tries to start a build with a version that does not exist, it will print an error message to the pending preparation build page. This should help give visibility into why a build is stuck pending. #5477

    🍱 🔗 feature

    • ⏱ When the scheduler starts a build, it will send a notification to the build tracker to run it. Without this notification from the scheduler to the build tracker, it can take up to approximately 10 seconds before your build gets run after being in a started state. #5631

    🍱 🔗 feature

    • 👍 Proxy support for NewRelic emitter

    🍱 🔗 feature

    • ➕ Add tracing to allow users and developers to observe volume streaming from source to destination volumes. #5579

    🍱 🔗 feature

    🍱 🔗 fix

    • 🛠 Fixed a bug introduced in v6.1.0 that caused admin users to no longer be able to login to any team. #5741

    🍱 🔗 fix

    • ⏱ The algorithm within the job scheduler component will now take into account whether or not a version exists in the database while determining a set of input versions for the next build of a job. Previously, when you had an input with passed constraints, it could pick a version that did not exist in the database because it picked versions purely based on if they have passed the upstream passed constraint jobs, regardless if that version did not exist anymore. This fix makes the algorithm skip over versions that do not exist. #5724

    🍱 🔗 fix

    • 🛠 Fixed a bug where task caches were getting garbage collected everytime you set the pipeline. #5497

    🍱 🔗 fix

    • 🛠 Fixed a bug "invalid memory address or nil pointer dereference" in NewRelic emitter. #5697