-
Notifications
You must be signed in to change notification settings - Fork 10
Conversation
…ption Update README onle-line description
Rephrase getting help in README
Update README examples to use new constructor and ReadString to develop
Add shorthand for generating random alphanumeric characters
Restructure the readme
Don't add a query parameter when no subject types are given.
These iterators make it possible to iterate over an infinite stream of audit events. The events are fetched in batches (pages) from the API, but this is abstracted away in the iterator.
This makes the logs easier to read, as the logs of downloading the modules will be in a different component.
Cache go modules and download them in a different step in CI
Only add query params to request when not empty
The current paginator is not the right abstraction. There currently is nothing generic about the paginator, which results in everything being injected as functions. Once we implement link headers, we can abstract away how we get the URL of the next page, which is then done in the same way for all pages.
Instead of waiting until a request is made, return the error when constructing the client.
Now we don't go back and forth between strings and URLs. Now this also doesn't return an error anymore.
It works just like mkdir -p, creating all directories that do not exist yet recursively and it does not error when the directories already exist.
Add CreateAll func to dir service to create dirs recursively
Also, don't support filtering subject types just yet. We'll add that later.
By doing so, we can remove the error from the constructor of the iterator
We still have to add the subject type(s) filter before the full functionality of ListEvents can be achieved with EventIterator. Before then, we'll not deprecate ListEvents just yet.
Add missing validation check
Add Exists func to dir service
Add EventIterator funcs
Add a fake for dirService.Exists
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.
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.
I was just reading up on the changes and found two small things. @SimonBarendse could you have a quick look?
Also, could you walk me through the decision process for going with the AuditEventIteratorParams
struct in person?
// | ||
// // Use event | ||
// } | ||
EventIterator(path string, _ *AuditEventIteratorParams) AuditEventIterator |
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.
Why do we have an unnamed parameter here? Would params
be more descriptive?
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.
Yes, params
as a name could also work.
The paramater is unnamed because it is not currently being used; there are no parameters to pass to the event iterator yet. The paramater is already added so that we can add parameters to the params struct without requiring a breaking change.
Added
CreateAll
to create dirs recursively (Add CreateAll func to dir service to create dirs recursively #146)Exists
for directories ( Add Exists func to dir service #149, Add a fake for dirService.Exists #153)