paket restore does not fail by default on out-of-sync lock file

[yaakov-h]

With an out-of-sync lock file, paket restore succeeds with return code of zero:

There is a flag to fail in this scenario, --fail-on-checks, but this requires opting in on every single invocation. For a large build system, this requires adding it to every paket build step definition in every codebase.

Can we make this fail by default? If there isn't something built-in already, I'd be interested in either of two possible changes:

1. Invert the behaviour: Make it always fail by default and change the flag to --ignore-check-failures or similar.
2. Define an environment variable that can be set to enable --fail-on-checks by default.

Thanks.

[forki]

Actually we think different about this. The lock file is the only source of truth. The out of sync check is just convenience for the user. Tbh it's only a heuristic that tries to detect inconsistencies between deps and lock file and we still see reports about false positives from time to time. So even if we would like to change this - it would break people.

Am Mo., 5. Nov. 2018, 23:27 hat Yaakov [email protected] geschrieben:

With an out-of-sync lock file, paket restore succeeds with return code of zero:

[image: image] https://user-images.githubusercontent.com/426009/48030667-ed300200-e1a5-11e8-8063-2fe39d5910a0.png

There is a flag to fail in this scenario, --fail-on-checks, but this requires opting in on every single invocation. For a large build system, this requires adding it to every paket build step definition in every codebase.

Can we make this fail by default? If there isn't something built-in already, I'd be interested in either of two possible changes:

1. Invert the behaviour: Make it always fail by default and change the flag to --ignore-check-failures or similar.
2. Define an environment variable that can be set to enable --fail-on-checks by default.

Thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fsprojects/Paket/issues/3409, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNMqHB2y9LOY0O8_M7ANNW265Frggks5usLtqgaJpZM4YPYiy .

[yaakov-h]

How about globally opting in to a stricter mode, with an escape hatch for false-positives (e.g. --ignore-check-failures)? That wouldn't break people, would it?

[forki]

Actually we think different about this. The lock file is the only source of truth.

I wonder why you see this differently!?

[martin-hirsch]

Recently I ran into the same issue in my pipeline. If this step would have turned red or orange, instead of writing a simple info. I could have solved this problem faster. I guess most people are conditioned to the fact that green means "don't look here for problems".