-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tags as versions for acceptable task rules #787
Conversation
df030dc
to
1fb7ef1
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #787 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 87 87
Lines 3560 3691 +131
==========================================
+ Hits 3560 3691 +131
|
1fb7ef1
to
913c2b5
Compare
@lcarva this is now a completely different take, the code has no semblance to the previous version. I've restarted the work from |
I don't understand this well, but I like the more towards making it more readable. |
fbe2368
to
8591fcc
Compare
8591fcc
to
3203dd6
Compare
This contains two major changes. One is that the logic in `lib.bundles` is written to in the form prose (or close enough) to allow for easier readings of the logic. Instead of the notion of a task collection and equality of task bundle references, the code now considers business logic terms, like "is acceptable", "is out of date", "is expired" and "newer version exists". And the second is that tags provided in acceptable task bundle data are now considered in rules. If tags are provided in acceptable task bundle they further refine the set of records from acceptable task bundle data that are examined, i.e. different versions do not interfere with each other. For task bundle references tags are computed from the acceptable task bundle data records by matching against the digest. reference: EC-223
3203dd6
to
f5c8486
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation looks correct to me.
I do really like how the functions are named. I don't think that's just a cosmetic thing. It makes the first half of the file much much easier to understand, e.g.:
# Returns a subset of tasks that use an acceptable bundle reference, but
# an updated bundle reference exists.
out_of_date_task_bundle(tasks) := {task |
some task in tasks
ref := image.parse(_bundle_ref(task, data["task-bundles"]))
_newer_version_exists(ref)
not _is_unacceptable(ref)
}
I do think though that there's quite a bit of duplication when it comes to the _newer_in_effect_version_exists
, and the _newer_version_exists
functions. They are also not the easiest to read. Maybe additional helper functions would improve things a bit.
Let's merge it. We can iterate on this as needed.
This contains two major changes.
One is that the logic in
lib.bundles
is written to in the form prose (or close enough) to allow for easier
readings of the logic. Instead of the notion of a task collection and
equality of task bundle references, the code now considers business
logic terms, like "is acceptable", "is out of date", "is expired" and
"newer version exists".
And the second is that tags provided in acceptable task bundle data are
now considered in rules. If tags are provided in acceptable task bundle
they further refine the set of records from acceptable task bundle data
that are examined, i.e. different versions do not interfere with each
other.
For task bundle references tags are computed from the acceptable task
bundle data records by matching against the digest.
reference: EC-223