This change implements a request by @vito to generate unique versions per pipeline.
This implementation hashes a combination of the BUILD_TEAM_NAME and BUILD_PIPELINE_NAME environmental variables using the FNV-1a algorithm. I chose FNV-1a based as the "best bang for the buck" (best distribution for algorithms readily available in Go).
The Offset function then determines what percentile the hashed value falls in, relative to the maximum possible value, and returns a time that is in the same percentile of the specified range/interval (as calculated by the TimeLord instance). All math rounds down to the nearest minute to align with the existing precision provided by this resource.
I think this approach creates:
an even distribution of versions generated by different pipelines across an identical range. So if lots of pipelines have resources that define a span of the same 4 hour range or are on a 4 hour interval, those pipelines will progressively trigger across the range/interval (but I need some help checking the logic here)
identical percentiles for versions generated by the same pipeline across different ranges. So if a pipeline has multiple resources defined that span a 4 hour range or are on a 4 hour interval, all of those resources will generate the exact same offset for each resource instance (🤔 is this is a problem?)
I know the common approach to these kinds of requests is to do some bitwise manipulation of inputs. But I took this approach in hopes of implementing a mechanism that is good enough to meet the need while promoting readability and maintainability.
One implication to this percentile approach is that non-standard days (e.g. the start/end of DST) will trigger pipelines in the same order as any other day. If/when days are 23 or 25 hours, the time that each pipeline triggers will adjust slightly (up to ~57 minutes), but each pipeline will have a similar offset. There won't be any wild swings of multiple hours due to a locale-related time zone change.
NOTE: This implementation is intentionally not integrated in to any of the executables and does not address any documentation updates (in order to avoid confusion).
This change implements a request by @vito to generate unique versions per pipeline.
This implementation hashes a combination of the
BUILD_TEAM_NAMEandBUILD_PIPELINE_NAMEenvironmental variables using the FNV-1a algorithm. I chose FNV-1a based as the "best bang for the buck" (best distribution for algorithms readily available in Go).The
Offsetfunction then determines what percentile the hashed value falls in, relative to the maximum possible value, and returns a time that is in the same percentile of the specified range/interval (as calculated by theTimeLordinstance). All math rounds down to the nearest minute to align with the existing precision provided by this resource.I think this approach creates:
I know the common approach to these kinds of requests is to do some bitwise manipulation of inputs. But I took this approach in hopes of implementing a mechanism that is good enough to meet the need while promoting readability and maintainability.
One implication to this percentile approach is that non-standard days (e.g. the start/end of DST) will trigger pipelines in the same order as any other day. If/when days are 23 or 25 hours, the time that each pipeline triggers will adjust slightly (up to ~57 minutes), but each pipeline will have a similar offset. There won't be any wild swings of multiple hours due to a locale-related time zone change.
NOTE: This implementation is intentionally not integrated in to any of the executables and does not address any documentation updates (in order to avoid confusion).