Fragnet

Fragment network tooling from Informatics Matters. This is primarily Java based tooling using RDKit and the Neo4j graph database and is the underlying service used by the Fragnet UI application.

Current components:

1. fragnet-search - fragment network query REST web service.
2. fragnet-depict - Depicting smiles as SVG.
3. orchestration - legacy orchestration of fragnet-search to AWS.

For more information see:

• Talk at 2018 RDKit UGM.
• Informatics Matters website
• Fragnet Search application

Building and deploying (CI)

The project containers are built automatically using GitHub Actions (see the project workflows in .github/workflows for details of the build).

• latest images pushed to Docker Hub for each change on the master branch.
• Tagged releases are built and pushed to Docker hub, with stable images also produced when the release is official (i.e. of the form N.N[.N]).

Deployment to the designated staging site is AUTOMATIC and occurs for every change to Master.

Deployment to the designated production site is AUTOMATIC and occurs for every official tag (i.e. of the form N.N[.N]).

Building (developer)

Run the buildDockerImages target to build the container images ./gradlew buildDockerImages. This builds two Docker images running Tomcat and deploys the war files for fragnet-search and fragnet-depict. These container images are squonk/fragnet-search and squonk/fragnet-depict. The squonk/fragnet-search image contains the Keycloak jars, but authentication needs to be enabled by modifying the web app.

Test the container using the docker-compose.yml file:

docker-compose up

This uses a sample Neo4j database with a small amount of data. It takes a short time to initialise.

Official deployments

Official deployments (to Kubernetes) use AWX and our fragnet-ansible playbooks.

Image versions

Official image versions are defined by and obtained from repository tags, passed on the Travis build process through the FRAGNET_IMAGE_TAG environment variable. This variable over-rides any built-in default present in the gradle build (see below)...

The application version is defined in build.gradle's version string.

During active development the version number (on the master branch) is typically the next anticipated formal release and must have a -SNAPSHOT suffix.

BEFORE making and pushing a formal release you must: -

1. Remove the -SNAPSHOT suffix
2. Adjust the version number accordingly (if required)
3. Commit the change to Git
4. Tag the Git repository using the chosen version number

AFTER making a formal release your next actions are to: -

1. Increment the version number
2. Append the -SNAPSHOT suffix
3. Commit your change to Git