Provide documentation on how to build/run the current dev version

[JWahle]

Hi, I really like moode and want to contribute a feature. My implementation is nearly finished, but to be able to test it locally, I branched off at the current release (commit 1dce40255b2c4f050a4a3047a4e17232892f5241). There are conflicts when rebasing on the current dev version. If I knew, how to build/run the current dev version, I could also test that my changes work after rebasing.

I took a look at the mosbuild project, but I cannot see how to get it to use a git repo instead of a zip-file downloaded via web (without modifying it or setting up a local web server).

So could you provide some documentation on how to build/run the current dev version?

[moodeaudio]

Hi,

I'd need to loop you into the Test Team forum at moodeaudio.org where the in process OS builds and dev branch repo sources are integration tested. We currently don't have any sort of automated Git repo OS/dev sources builder thing.

What the feature?

-Tim

[JWahle]

Is the Test Team forum private? I am a registered forum member and I can't see it.

The feature I would like to contribute is CamillaDSP integration. Still very basic: there is an on/off switch, a config check with possible error message and documentation with a sample config generator for the currently selected output. Configs and filters have to be created/uploaded through ssh/scp.

[JWahle]

Maybe in my first post, I didn't make it clear enough, that I was simply copying files over to my raspi with a preinstalled moode image. It took me some time to figure out, how to hack mosbuild to build from sources. I just want to know, if you know a simpler or faster method, than the one I use. If not, I will send a PR in mosbuild with updated documentation.

This is what I do on my PC:

1. check out moode and mosbuild
2. zip the whole moode repo (including the moode parent dir) to moode.zip and place it in mosbuild
3. in mosbuild.properties change MOODE_REL=http://ip_of_my_pc:8000/moode.zip
4. in mosbuild.sh change DOWNLOAD_URL="http://ip_of_my_pc:8000"
5. upload mosbuild.sh to /home/pi/ on the Raspberry Pi
6. change working dir to mosbuild repo and run python3 -m http.server 8000 (this starts a web server with the zip and mosbuild files on port 8000 of my PC)
7. on the Raspberry Pi run sudo ./mosbuild.sh and follow the instructions

[moodeaudio]

Mosbuild is not something that gets run very often. I only do it if the plan is to release an iso built from a new version of RaspiOS. I did it for the moOde 7 ISO cos I wanted to go with the new RaspiOS 10.6.

You can just use the 7.0.1 image for testing new/updated sources.

[JWahle]

I understand that this won't be used often - mainly due to the time it takes. However, when developing the CamillaDSP integration, I had plenty of problems with the configuration. That is why I wanted to build everything and see, if it still works - before making the PR. Figuring this out took me a few tries. Having a guide on how to do this would have saved me about a day of development time. This is why I ask to add this information to the mosbuild documentation. (I would provide a PR.)

It seems to me, that you don't want to add the information. Do you see any reason it might be harmful?

[moodeaudio]

Maybe there is some confusion over what mosbuild is designed to do. First it's not a development tool, it's designed to build the release image from the production sources.

Are you asking for a guide that explains how to setup a local development environment that enables working with the dev branch?

[JWahle]

Yes, exactly.

[moodeaudio]

@bitkeeper added a Gulp guide to the repo a while back. https://github.com/moode-player/moode/blob/develop/other/build/moOde%20development%20with%20gulp.odt

I used it along with his help to integrate Gulp into the existing dev workflow on my Mac. I have a local clone of the moode and mosbuild repos and I use Atom editor, GitHub desktop and SQLiteStudio for dev and release admin. I also have a home grown script that runs on each test Pi which copies the sources and other files built by Gulp from the local dev branch on my Mac (which is shared via Samba) into my test Pi's.

My workflow is basically

Mac

1. Edit sources, if any SQL changes then add the commands to in-place update script and also use them to manually update the test Pi's.
2. Run Gulp cd ./Documents/Software/moode-player/GitHub/moode sudo node_modules/.bin/gulp build sudo node_modules/.bin/gulp deploy --test

Test Pi's

1. Run ~/build.sh on each test Pi to load the updated sources, files, etc
2. Run any SQL commands if needed
3. Copy binaries if needed
4. Copy other files if needed

Sometimes I just copy individual files into the Pi's for testing if they are not part of a Gulp bundle.

[bitkeeper]

Tims development environment is setup to work with a single local repo (on the Mac) and deploy it to multiple test targets.

Most users can use a simpler setup with a clone of the moode repo to a Raspberry Pi (for example to /home/pi/moode). I that case

I would recomment the following setup:

• Pi 4 2GB or more (at least a Pi 3) for development
• A good ssh client ( on windows I can recomment MobaXTerm)
• clone your own or the original moOode repo on the Pi.
• Microsoft Visual Code as IDE (Works on Windows, Mac, Linux and even my Chromebook works great with it), with the some plugins like:
  • Remote SSH
  • GitLens
  • PHP, Python and C/C++ IntelliSens
• With this IDE you edit directly the files on the Pi, no need to transfer. Git actions can be done with the IDE or console. It also includes a ssh terminal.
• As @moodeaudio indicated read the gulp manual from front to back and setup the gulp tooling.
• Do build in the local repo location followed by a deploy
• Everything outside the ~/moode/www directory requires manual actions.

I have never needed to use the mosbuild(that is Tim stuff ;-) ) to get functionality working on it.

For the lucky few that only do front end stuff (no related to the php and php templates) can you even do development without updating the sources on the Pi. See the gulp manual for that.

I use the followin script for setting up the basic development env on the Pi:

#!/bin/bash
#
# Setup intial buildenv for moOde
# @bitlab 
#
#

GIT_USER_NAME="your_user_name"
cd ~

sudo apt-get update
sudo apt-get -y install npm mc htop
sudo npm install -g gulp

git config --global user.name $GIT_USER_NAME
git config --global user.email "$GIT_USER_NAME@users.noreply.github.com"
git config --global credential.helper 'cache --timeout=7200'
git config --global credential.helper cache

cd ~

git clone https://github.com/$GIT_USER_NAME/moode.git
cd moode
git remote add remote https://github.com/moode-player/moode.git
git fetch remote
git checkout develop
git pull remote develop

npm ci
npx browserslist@latest --update-db

node_modules/.bin/gulp build
node_modules/.bin/gulp deploy --test

sudo mv /var/www /var/www.org
sudo node_modules/.bin/gulp deploy

To compare the database scheme in the repo to my running database I use the script below. It generates a change file with sql statements. You have to review that file carefully and only leave the changes related to db changes in the file, not due changes for own setup. If you just apply the output without carefully review it you will break your db, for sure.

#!/bin/bash
# 2020 mvdweert
# 
#

# create fresh db
rm moode-clean.db
sqlite3 moode-clean.db < ~/moode/var/local/www/db/moode-sqlite3.db.sql 

# create hash patch script by comparing clean vs running db 
# (and remove ro protection for the hashes and aftewards reinstall it )
echo "DROP TRIGGER ro_columns;" > moode-changes.sql #
# sqldiff --table cfg_hash /var/local/www/db/moode-sqlite3.db moode-clean.db >>  moode-changes.sql
sqldiff /var/local/www/db/moode-sqlite3.db moode-clean.db >>  moode-changes.sql
echo "CREATE TRIGGER ro_columns BEFORE UPDATE OF param, value, [action] ON cfg_hash FOR EACH ROW BEGIN SELECT RAISE(ABORT, 'read only'); END;" >> moode-changes.sql

# How to apply a diff patch file:
#sqlite3 /var/local/www/db/moode-sqlite3.db < moode-changes.sql

# summary of the changes:
# sqldiff --summary /var/local/www/db/moode-sqlite3.db moode-clean.db |  grep -v "0 changes, 0 inserts, 0 deletes,"

[JWahle]

Thanks for the detailed instructions.