-
-
Notifications
You must be signed in to change notification settings - Fork 92
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
Improve fluent mapping #1089
Improve fluent mapping #1089
Conversation
@tomkerkhove I haven't done end to end testing of this change yet. I'll do that before merging. I have made sure all the unit tests pass though, so I'm fairly confident the changes work fine since we've got pretty much complete coverage of deserialization. Also, I realise I've accidentally committed this with the wrong gitconfig. I'll rebase and sort that to fix the CLA issue. |
Docker image for this PR was built and is available on Docker Hub. You can pull it locally via the CLI: docker pull tomkerkhove/promitor-agent-scraper-ci:pr1089-linux Want to verify the new version? Run it locally: docker run -d -p 8999:80 --name promitor-agent-scraper-pr1089-linux \
--env PROMITOR_AUTH_APPID='<azure-ad-app-id>' \
--env-file C:/Promitor/az-mon-auth.creds \
--volume C:/Promitor/metrics-declaration.yaml:/config/metrics-declaration.yaml \
--volume C:/Promitor/runtime-config.yaml:/config/runtime.yaml \
tomkerkhove/promitor-agent-scraper-ci:pr1089-linux You can find a CI version of our Helm chart on hub.helm.sh |
8a6a6c4
to
d784da8
Compare
I've refactored the way the fields to deserialize are built up to use a builder pattern. The reason for this is so that we can simplify the mapping methods in the `Deserializer` class down to a single `Map()` entry point, and then use separate methods to configure different aspects of the mapping. The reason I want to do this is in preparation of adding the ability to specify custom validation for fields, for example to validate that Cron expressions are in a valid format. Otherwise we'd end up having to add a load of extra overloads.
I've converted over the AzureMetadataDeserializer to give an example of what the mappers would look like going forward. Once the deserializers are converted over, the `MapOptional` and `MapRequired` methods in `Deserializer` could all be removed.
d784da8
to
128abf0
Compare
Docker image for this PR was built and is available on Docker Hub. You can pull it locally via the CLI: docker pull tomkerkhove/promitor-agent-scraper-ci:pr1089-linux Want to verify the new version? Run it locally: docker run -d -p 8999:80 --name promitor-agent-scraper-pr1089-linux \
--env PROMITOR_AUTH_APPID='<azure-ad-app-id>' \
--env-file C:/Promitor/az-mon-auth.creds \
--volume C:/Promitor/metrics-declaration.yaml:/config/metrics-declaration.yaml \
--volume C:/Promitor/runtime-config.yaml:/config/runtime.yaml \
tomkerkhove/promitor-agent-scraper-ci:pr1089-linux You can find a CI version of our Helm chart on hub.helm.sh |
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.
LGTM - Great addition Adam, thanks!
Let me know when I should merge.
@tomkerkhove that's me tested it and it's looking good. Do you want me to create an issue for this work? I'm happy to do that. |
No it's ok, thanks! Created #1091 for the follow-up to align the other deserizalizers - Thanks again! |
I've added a new way of configuring deserializers to try to simplify things a bit, and to make it easier for us to extend deserialization. So instead of writing the following:
We can write it:
Originally when I'd added the
MapOptional()
/MapRequired()
methods, I wanted to avoid going too far down the route of designing a fluent interface because this is just used internally by Promitor, but the approach of using overloads becomes pretty unwieldy very quickly. Making this change makes it easier to add extra functionality to the deserializers, for example custom validation. This would allow us to do something like this to make sure Cron expressions were in the correct format:At the moment I've just converted the
AzureMetadataDeserializer
to give an example of how it might look, but I'll go ahead and convert all the deserializers if it's all looking good.