Testing

The build.sh script is run by the rockstor-build systemd service.
To test the modifications here the following was enacted:
(An existing 5.0.14-* rpm install was in place; but with the proposed build.sh modifications)

systemctl stop rockstor*
rm /opt/rockstor/rockstor-jslibs.tar.gz
rm /opt/rockstor/rockstor-jslibs.tar.gz.sha256sum 
rm -rf /opt/rockstor/.venv/

And a full service restart was initiated via:

[EDIT]

systemctl start rockstor-bootstrap.service

Sep 30 12:16:24 rleap15-6 build.sh[14455]: Getting rockstor-jslibs version 5.0.14
Sep 30 12:16:24 rleap15-6 build.sh[14521]: --2024-09-30 12:16:24--  https://github.com/rockstor/rockstor-jslibs/archive/refs/tags/5.0.14.tar.gz
...
Sep 30 12:16:26 rleap15-6 build.sh[14455]: Sourcing /opt/rockstor.env
Sep 30 12:16:26 rleap15-6 build.sh[14530]: Password store initialized for rockstor@localhost

N.B. we have an outstanding typo re path'/'.env file to be addressed when we are next modifying this file.

I hit this yesterday when testing but couldn't figure it out :)

@cellisten Yes, we have had these two 'version' references and it's a pain when doing releases. So I was just seeing to a little simplification hopefully. Currently there is little movement in jslibs but our next testing phase intends to focus more on updates/reductions there. So I wanted to get this in place ready. I've just got to make sure this doesnt' break our test build back-end and then I'll get to merging.

As a workaround I managed to build by running it directly with ./build.sh rather than the recommended sh build.sh from the docs

An rpm was build with this branch and looks to have a successful:

Start rockstor-bootstrap service

step.
See: https://github.com/rockstor/rockstor-rpmbuild/tree/testing for rpm spec file and procedure.
We build our distribution rpm, via poetry and two source elements, so that we can distribute the appropriate jslibs with the versioned rpm. But we maintain the flexibility for build.sh to enact it's own GitHub release download of rockstor-jslibs.

@cellisten re:

As a workaround I managed to build by running it directly with ./build.sh rather than the recommended sh build.sh from the docs

Yes, there are always improvements to be had in the docs. Do feel free to submit any corrections/enhancements that take your fancy. New folks to our build process often have valuable insite as to what is not clear.

Note however that build.sh, although handy to run by-hand, must always be ameanable to being run by it's systemd service which we mention in the docs:

rockstor-bootstrap service

As that sets up the expected environment etc. And note the sensitivity re .venv: our locally installed/build python virtual environment. We have changed a few details and added this very service in this on-going testing phase. We used to do the build via rpm's %posttrans scriptlet but that ended up being way too much overload for what is a very restrictive environment and far too much to do during an install (or stricktly the latter section post transitional install). Moving the .venv build to a systemd service has helped massively with making changes there more easily testable and eases diagnosis re failed builds of the .venv re internet access etc. As they show up as a failed service: far more approachable than a posttrans scriptlet fail.

Is the rockstor-bootstrap service still available the first time after the original install is removed and the rsync has been done? I might redo it all to verify the steps and then I will try to see if I can think of any improvements

@cellisten rockstor-bootstrap is used to do the final mounts etc . We use all these services on each boot. But rockstor-build is only enabled if there is no .venv dir, and on each rpm update we wipe that dir and re-start all services. And so the .venv is rebuild after each rpm update. Take a look at our: rockstor-rpmbuild repo for what we do there. The Web-UI also takes a part in each update.

We cover (somewhat sparsely) our systemd services in the developer docs here:

• https://rockstor.com/docs/contribute/contribute.html#developers

Hope that helps. And note that bar some minor asthetics there are no known issues with our hard-won update process. This took quite some time to settle down as it goes. See the changelog entries in the first half of this testing release:

https://forum.rockstor.com/t/v5-0-testing-channel-changelog/8898

Build.sh simply collates stuff we need to do after a fresh install or update to re-instate our python environment. It is also a convenience for developers: but is not end-user as such given it is expected to be run under systemd only.

Discussions of this sort are rather better located on the forum I think. As it can make it 'cloudy' for folks to follow the main stream of an issue or pull request.

Hope that helps.