Forum OpenACS Development: Docker container auto-build

Posted by Malte Sussdorff on
Two things I could use some help with.

A) I can provide a hook to auto generate the openacs docker container upon code commits (as I am not sure how to subscribe to bitbucket from Gitlab / Github / Dockerhub). Then the containers could be auto updated if a commit is made into the master or oacs-5-10 branch.

B) Is there a way / best practice to trigger the testing of OpenACS installation from the command line or a single TCL command, so I can integrate this into a Gitlab CI/CD pipeline? Not entirely sure how USEFUL that is going to be in the end given the high quality of the framework, but I wondered nevertheless.

(We write our own test scripts for project-open now in as we primarily test the frontend and API calls, so are not relying on acs-automated-testing).

Posted by Malte Sussdorff on
Related to that, if A) isn’t an option, would you find it useful if I add the packages directory as something which is stored locally on the harddrive in docker-compose.yml so repository installations and updates survive a restart?
Posted by Gustaf Neumann on
Is there a way / best practice to trigger the testing of OpenACS installation from the command line or a single Tcl command...

Several years ago, i wrote a script for sending a single command or a script to nsd via nscp. Under nscp one can run arbitrary Tcl/OpenACS commands, but there is no connection. This script can be used to control a NaviServer instance either via command line or via cron job.

OpenACS testing is build around the web interface, so one needs a way to collect the output in a useful way. Since the test results are written into the database, it should be possible to trigger the start of the test run this way and to collect later the test results from the DB.

Posted by Héctor Romojaro on
Regarding B, we use a simple tcl page that can be accessed by curl during the Gitlab CI/CD pipeline, and runs the tests of different packages. This produces log entries that can be parsed afterwards to determine if the tests were successful.

That, the automatic package upgrade I posted here[1], and some other tests (coverage, ...), makes for a nice Gitlab pipeline.