frontend: data-pipelines build and test running CI/CD

[ivakoleva]

We need to build and run unit tests of data-pipelines library and ui application that uses it. The component is dependent on shared-components library.

Added Bash scripts to
(1) link if any shared-components rebuild was made and is about to be published, or otherwise default to latest already published one
(2) build the data-pipelines library and link @vdk/data-pipelines
(3) build the UI application
(4) lint the subprojects to verify format
(5) run the unit tests
One bash script is meant to be used to satisfy build prerequisites, the other one to rebuild and relink continuously, needed during development.
The proposed implementation triggers a data-pipelines rebuild (+test), upon any shared-components change, as well as data-pipelines changes.
A README.md link fix to the VEP.

Testing done: run the install script (that evaluates the build script) on a clean setup, and verified the unit tests were successful. Also, did start and browse the application manually, to check its operational.

[antoniivanov]

I was once told (when our open source team was reviewing our commit history) that if we have bullet points in the commit message, a change is doing too many things and should have been split. Since then when I catch myself that I make bullet points or start saying "fixing this and that" I consider if I should better split it into 2 or more.

I thought that was good advice and I am passing it on.

[ivakoleva]

I was once told (when our open source team was reviewing our commit history) that if we have bullet points in the commit message, a change is doing too many things and should have been split. Since then when I catch myself that I make bullet points or start saying "fixing this and that" I consider if I should better split it into 2 or more.

I thought that was good advice and I am passing it on.

I generally agree, it's a good advice. When you are open sourcing an existing component, a lot of stuff are known and also tested & verified already in advance. So, I also think it is normal to be confident with enumerating the changes, it rather depends on the context.

[antoniivanov]

I generally agree, it's a good advice. When you are open sourcing an existing component, a lot of stuff are known and also tested & verified already in advance. So, I also think it is normal to be confident with enumerating the changes, it rather depends on the context.

Yes I agree, for that specific case, we are fine.

I wanted to note this advice because the change reminded me.
And also want to note (especially for any new contributors) that while now we have some bigger PRs around open-sourcing the UI and that's not a practice we recommend.

[ivakoleva]

I generally agree, it's a good advice. When you are open sourcing an existing component, a lot of stuff are known and also tested & verified already in advance. So, I also think it is normal to be confident with enumerating the changes, it rather depends on the context.

Yes I agree, for that specific case, we are fine.

I wanted to note this advice because the change reminded me. And also want to note (especially for any new contributors) that while now we have some bigger PRs around open-sourcing the UI and that's not a practice we recommend.

I actually think 11 files is a pretty standard amount of file changes. The PR description does not contain bullets, it contains logical steps that the install script performs, that would be an atomic change (since the script is an atomic item itself). So I don't think artificially splitting the script, in a series of PRs, would be practical. I considered splitting the import fixes, but decided not to due arguments listed in #1671 (comment)