On Mon, 15 Oct 2018 at 22:04, Antonio Terceiro antonio.terceiro@linaro.org wrote:
On Thu, Oct 11, 2018 at 11:09:01AM -0500, Dan Rue wrote:
On Thu, Oct 11, 2018 at 11:46:14AM -0300, Antonio Terceiro wrote:
[...]
Thanks for everyone's feedback. So my plan to address your concerns is the following:
allow the cleanup to be disabled completely by setting the number of days to -1. This can be used as a simple solution for projects that have new builds at a low frequency.
add a `keep forever` flag to build objects, that can be set using the REST API. This way each project can mark exactly which builds they want to keep, without needing to hardcode any specific logic in squad.
For LKFT we're still discussing what our policy should be for data retention. We link into qa-reports and lava in bugs and public mailing lists posts, and so our task is to assess the impact of such links breaking over time.
Logistically, will there be time to set this value after this feature is released, but before the first purge occurs, so that we will not lose data as a part of the deployment? We will surely want more than 180 days, but we're trying to decide if 365 is sufficient.
Good point. I could set all existing projects to -1 to give some time for a decision, or we could wait until we have a decision from most projects before deploying this in production.
Patch was merged and is now deployed in staging. I setup a testing project: https://staging-qa-reports.linaro.org/people/data-retention-test/ The data should be deleted after 1 day. This brings an interesting challenge - what should happen to calculated regressions and fixes? Should we re-calculate them when removing baselines? Keep them as they are? Maybe the baseline 'version' should be stored so we know how the calculation was made?
milosz
Squad-dev mailing list Squad-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/squad-dev