fix: trivy ci fail

[keyvaann]

The issue with the trivy seems to be known and there is a workaround for it.

[baixiac]

Wrt -upgrade, if users update their infrastructure first and commit some changes afterwards, does this mean the newly added hooks can make the module versions used during infrastructure update differ from the module versions eventually committed and pushed?

[keyvaann]

Wrt -upgrade, if users update their infrastructure first and commit some changes afterwards, does this mean the newly added hooks can make the module versions used during infrastructure update differ from the module versions eventually committed and pushed?

Yes that is true! But I don't know what is the best solution. I made the change to prevent the CI from failing. Maybe we can pin the exact module version instead of giving it a range or have another way to solve it.

[baixiac]

You meant -upgrade is required to make the CI green?

[keyvaann]

Yes!

[baixiac]

Alright. May be pin down the versions then. I did notice every time I run those hooks the HCL lock files and TF docs get updated with another version of aws-provider.

[baixiac]

The devbox hook upgraded dependency modules/providers on every run and didn't honour the lock files. This change stops that and works for me. Would you mind reverting the change related to introducing -upgrade?

[keyvaann]

You have added the change to init_hook and it runs only when you run devbox shell and after that it doesn't run anymore and in the meantime there might be an update to the provider which will fail the CI during push. I'm not sure if the change introduced in the other PR will solve the issue.

[baixiac]

in the meantime there might be an update to the provider which will fail the CI during push

The CI shouldn't do that but always honour the lock files, right? The CI may fail only if GitHub changes the CI instance's platform or architecture which has no corresponding hash recorded in the lock file.