Update base models, and do so with each "make composerupdate"

silinternational / idp-id-broker

API to abstract identity persistence in IdP-in-a-box solution

MIT License

1 stars 1 forks source link

Update base models, and do so with each "make composerupdate" #351

Closed forevermatt closed 1 month ago

forevermatt commented 1 month ago

Added

Revise Makefile to update base models after every composer update
- Occasionally Yii updates their template for Active Record model files. It seems more helpful to see the effects of those changes in that same PR (where Yii was updated), rather than seeing them in a later, unrelated PR. Updating the base models only takes around 10 seconds, so it seems like a minimal time cost (percentage-wise) that we're adding to each composer update call.

Fixed

Update the base models (using our current version of Yii). Insignificant changes.

sonarcloud[bot] commented 1 month ago

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
45.8% Duplication on New Code

See analysis details on SonarCloud

briskt commented 1 month ago

Occasionally Yii updates their template for Active Record model files. It seems more helpful to see the effects of those changes in that same PR (where Yii was updated), rather than seeing them in a later, unrelated PR. Updating the base models only takes around 10 seconds, so it seems like a minimal time cost (percentage-wise) that we're adding to each composer update call.

This reminds me that you have significant automation in mail-admin. Would any of that be of value in IdP repos? The one I'm most curious about is the one that updates dependencies on every release.

forevermatt commented 1 month ago

This reminds me that you have significant automation in mail-admin. Would any of that be of value in IdP repos? The one I'm most curious about is the one that updates dependencies on every release.

The auto-update-dependencies automation (when creating a new release) is actually minimally problematic, because we end up deploying dependencies to production before they have been tested on staging.

I think a better approach would be to simply include an "Update dependencies" step in the feature-branch PR checklist. (I'll be glad to share with you the details of Mail Admin's automated dependency updates, it just comes with some drawbacks.)