Build Retention


#1

Curious on what is the default build retention, or how to configure?

https://concourse-ci.org/caching-and-retention.html is still missing information currently.


#2

By default I believe its infinite (storage constrained). You can configure it in the job config as part of the pipeline.


#3

To confirm, build “logs” are stored in postgres right? In terms of the containers that are retained (that are made available to be intercepted) – is there a config to change the retention on that?

Long story short, we have an external hosted postgres, but on our concourse worker nodes (btrfs over ext4) is having issues with disk capacity.


#4

To confirm, build “logs” are stored in postgres right?

Yes, they have no impact on the worker disk storage.

In terms of the containers that are retained (that are made available to be intercepted) – is there a config to change the retention on that?

I don’t know off the top of my mind. What I do in these cases if no documentation is available is looking at the output of concourse web --help, it shows all the options. For this particular request though, I advise NOT to reduce that lifetime. Being able to intercept failed builds is super important.

Long story short, we have an external hosted postgres, but on our concourse worker nodes (btrfs over ext4) is having issues with disk capacity.

The question about worker disk capacity pops up often. The official answer, the only one that gives you peace of mind, is to monitor disk capacity and increase it if needed. I suggest not to try to fight / outsmart it.We have it set to 100GB and the usage never goes above 80%.


#5

Thanks. Sounds like we just need to scale the disks.