You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to discuss a possible workflow/feature and gather some feedback in regards if you consider it useful (should become feature request), or useless (in this case - why).
It concerns a production environment. CI build job runs automatically and regularly. Theoretically, updates of indirect dependencies (deps of toml file deps) should not cause problems. In reality, they some time do. Due to safety reasons, if an indirect dep package is vulnerable, it is possible to update the lock file. But that causes the entire dep graph to be resolved and that can lead to any changes on indirect deps. So even though all primary deps are pinned to an exact version in toml file, there may be even major updates on indirect deps. And this may cause problems.
The possible workflow in question is following:
There would be 2 CI jobs:
CI bump job: It would do a regular update, which would update all dependencies according to constraints in toml file. Since this can cause problems and potentially needs attention of developers, it would run only once every few weeks/months.
CI patch job: This job would use a (feature request) functionality, to update dependencies, but if possible, update all packages, even indirect ones, only on a patch level (x.y.*) (even though, there would be newer versions available). This should be much safer in regards to conflicts, so this job could be run every day to prevent security vulnerabilities.
It is basically a different resolving strategy. The current one is "aggressive" as it tries to find the newest versions possible (within constraints). The new strategy would be "defensive" one, as it would try to find new patch level version but in the same time, it would try to avoid any minor and major bump if possible.
Do you think, you would benefit from such a feature? Do you think this is a reasonable prod strategy? How do you approach prod env builds?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
I would like to discuss a possible workflow/feature and gather some feedback in regards if you consider it useful (should become feature request), or useless (in this case - why).
It concerns a production environment. CI build job runs automatically and regularly. Theoretically, updates of indirect dependencies (deps of toml file deps) should not cause problems. In reality, they some time do. Due to safety reasons, if an indirect dep package is vulnerable, it is possible to update the lock file. But that causes the entire dep graph to be resolved and that can lead to any changes on indirect deps. So even though all primary deps are pinned to an exact version in toml file, there may be even major updates on indirect deps. And this may cause problems.
The possible workflow in question is following:
There would be 2 CI jobs:
It is basically a different resolving strategy. The current one is "aggressive" as it tries to find the newest versions possible (within constraints). The new strategy would be "defensive" one, as it would try to find new patch level version but in the same time, it would try to avoid any minor and major bump if possible.
Do you think, you would benefit from such a feature? Do you think this is a reasonable prod strategy? How do you approach prod env builds?
Reference to @abn in #5494 (reply in thread)
Beta Was this translation helpful? Give feedback.
All reactions