Prox Project Service

The purpose of this service is to provide a backend for projects of Prox.

Installation

After a git clone or download the project the following command must be executed once to initialize the projects.

Windows (CMD/PowerShell)

# Switch to project folder
cd .\prox-project-service\
# Execute initial build for git hooks...
.\mvnw.cmd clean test

Linux/MacOS (Bash/Terminal)

# Switch to project folder
cd prox-project-service/
# Execute initial build for git hooks...
./mvnw clean test

Executes the Maven default lifecycle up to the test phase. During the package phase, an executable JAR and the Docker image are created.

Testing

The tests of this project are seperated in unit and integration tests. If you are unsure about the difference, please take a look here.

Unit tests are designed to run fast in the test phase while integration tests will run slower in the verify phase.

# run unit tests
./mvnw clean test

# run unit and integration tests
./mvnw clean verify

Local usage with docker

A Docker network named prox is required for the communication between services:

docker network create prox

Starts a Docker container based on the compose file and the image.

Powershell

$env:IMAGE='prox-project-service'; `
$env:TAG='latest'; `
docker-compose -f ./src/main/docker/docker-compose.yml up

Bash/Shell

export IMAGE="prox-project-service" &&
export TAG="latest" &&
docker-compose -f ./src/main/docker/docker-compose.yml up

Local usage in IntelliJ IDEA

For the necessary steps please look in Run/Debug in IntelliJ IDEA.

About the Team

This service is currently developed by members of the ArchiLab staff:

• Julian Lengelsen (@jlengelsen)
• Rudolf Grauberger (@rudolfgrauberger)

Development

Please consider our contributing guidelines.

Commit Messages

The commit messages SHOULD adhere to the Conventional Commits specification. This repository is also Commitizen-friendly. You can use Commitizen seamless in this repository.

Perform a release

In general releases are done by pushing a git tag which conforms to SemVer specification. We prefix those tags with a v, so the tag itself MUST follow the pattern vMAJOR.MINOR.PATCH. A label is not used.

The simplest way to perform a release is by relying on our standard-version configuration. If you are ready to perform a release simply call

$ npx standard-version
# or
$ npm run release

This will analyze the last commits since the last release, determine the new version, generate a changelog and create a git tag for you. Next up you will need to push the tag and version bumped files, our release pipeline will take care of the rest.

$ git push --follow-tags origin main