feat(pkg/config/filter): only warn on date parse error

[mbarneyjr]

In current state when you use a dateOlderThan filter, it'll return an error if it comes across a resource/field that it cannot parse as a date, and will prevent aws-nuke from running on all of the other resources it may have successfully processed

This change will instead only log a warning when an error occurs, which the user will be able to see. The resource will not be filtered out (although I'm not opinionated either way, my main goal is to not hold up aws-nuke from running because one resource was misconfigured)

I'm open to feedback/change requests

Here's an example output with these changes:

Do you really want to nuke the account with the ID 123456789012 and the alias 'my-account'?
Waiting 3s before continuing.
time="2024-07-11T21:22:47Z" level=warning msg="Failed to parse date IAMNOTADATE: unable to parse time IAMNOTADATE"
us-west-1 - DynamoDBTable - testing - [Identifier: "testing", tag:expiration-date: "IAMNOTADATE"] - would remove
Scan complete: 1 total, 1 nukeable, 0 filtered.

The above resources would be deleted with the supplied configuration. Provide --no-dry-run to actually destroy resources.

[ekristen]

Interesting idea. I generally like it, however this might be considered a breaking change as it would change the default behavior of the tool. I'm trying to think of any ramifications.

[mbarneyjr]

I wouldn't feel opposed to a could be a config option to enable this functionality, leaving the previous functionality as the default, if that's the approach you'd like to go with I'd be happy to push another change to this PR

[mbarneyjr]

@ekristen I've pushed a change to add a nuke-on-date-parse-error feature flag, that if left default (false), will cause aws-nuke to behave exactly the same as it did before this change. I'm happy to tweak anything you'd like to get this merged

[mbarneyjr]

@ekristen just checking if there's anything we can do to get this merged, I'm happy to make any changes if there's anything you have in mind

[ekristen]

@mbarneyjr I have no control over this unfortunately. I'm only a contributor. I only try and help folks here as I can. I've started my own managed fork over at https://github.com/ekristen/aws-nuke that's diverged greatly from this in terms of test-ability and core code.

[mbarneyjr]

Interesting, would you say this repo is unmaintained? Looking at the commit history it's mostly bot activity, April ec40ba being the last regular push

[ekristen]

It's less maintained then mine, hence why I split off. They do bulk maintenance every few months, so it's not completely unmaintained. Just my two cents.

[ekristen]

This is being looked at in the upstream library libnuke that powers that now actively maintained fork of aws-nuke ekristen/libnuke#70 -- if you have anything to add, please do it there.

---

Please see the copy of the notice from the README about the deprecation of this project. Sven was kind enough to grant me access to help triage and close issues and pull requests that have already been addressed in the actively maintained fork. Some additional information is located in the welcome issue for more information.

Caution

This repository for aws-nuke is no longer being actively maintained. We recommend users to switch to the actively maintained fork of this project at ekristen/aws-nuke.
We appreciate all the support and contributions we've received throughout the life of this project. We believe that the fork will continue to provide the functionality and support that you have come to expect from aws-nuke.
Please note that this deprecation means we will not be addressing issues, accepting pull requests, or making future releases from this repository.
Thank you for your understanding and support.