FOLIO-4506 Fail release builds when lockfiles pin snapshot dependencies

[alb3rtino]

https://folio-org.atlassian.net/browse/FOLIO-4506

Purpose

Release builds must not ship with snapshot dependencies pinned in yarn.lock. Snapshot versions resolve from the npm-folioci repository, whereas released versions resolve from npm-folio. If a release tag is built against a lockfile that still references npm-folioci, the resulting artifact depends on non-released FOLIO packages. This change prevents such releases from succeeding by failing the UI install-and-lint workflow when snapshot resolutions are detected on a release tag.

Approach

• Added an optional fail-on-snapshot-deps input to ui-install-and-lint.yml that, when true, greps yarn.lock for npm-folioci resolutions and fails the job if any are found.
• Wired ui.yml to pass fail-on-snapshot-deps: true only when is-release is True.

[zburke]

LGTM, thank you!

[dcrossleyau]

@alb3rtino -- Please define this new configuration variable at README-UI.md

(Is there a Jira ticket for this?)

Cc: @zburke and @ncovercash

[alb3rtino]

@dcrossleyau fail-on-snapshot-deps isn't a consumer-facing input. It's an internal input on ui-install-and-lint.yml that ui.yml sets automatically based on is-release. README-UI.md only documents inputs that consumers of ui.yml can set, so there's nothing to add there as-is.

Happy to expose it as a user input so users can opt-out. Let me know if you'd like that.

I have created FOLIO-4506 for this.

[ncovercash]

I like the idea, however, I'm not sure it's possible to get to this scenario...the NPM repository is already determined by the action depending on if it's a release or not, so if it is a release then yarn won't have any idea that folioci even exists.

[alb3rtino]

I like the idea, however, I'm not sure it's possible to get to this scenario...the NPM repository is already determined by the action depending on if it's a release or not, so if it is a release then yarn won't have any idea that folioci even exists.

It is. See stripes-components v13.1.0 release workflow.

[zburke]

@ncovercash, what advantage do you see in exposing this value as a user-settable attribute? My take on this PR had been, "Whoops, good catch, this fixes a bug." What am I missing?

[ncovercash]

@alb3rtino ah, forgot about some modules having their own lockfile (rather than most of the UI ones being generated at build time).

@zburke I'm fine not having it be user-settable, unless you can think of any scenario where we'd need to publish with a snapshot dependency (I can't). I would probably recommend renaming the step to Ensure no snapshot dependencies are included (release only) or something along those lines so it's clear at a glance when we're enforcing it, but that's a super minor nit

[dcrossleyau]

Thanks for the explanation. I mis-interpreted what "inputs" meant in this case. Leaving it to the experts.