DataCite Events Service

This is the code repository for the DataCite Events REST API.

---

Process Flow Diagram

---

Dependencies

Local application development is dependent on Docker. Ensure that is installed locally.

Local application development is dependent on DataCite LocalStack Repository. Ensure that this is cloned locally.

Local application development is dependent on Lupo. Ensure this is cloned locally.

---

Release management

What is semantic versioning?

Semantic versioning (SemVer) is a way of numbering software releases using the format MAJOR.MINOR.PATCH (like 1.4.2) to indicate the type of changes made.

Why do we use it?

Semantic versioning helps developers and users quickly understand whether an update will:

• break existing code,
• add new features, or
• just fix bugs.

This makes it easier to manage dependencies and upgrades safely.

How does it work?

• MAJOR version (X.y.z):
  Increment when you make incompatible (breaking) changes.
  Example: 1.2.3 → 2.0.0 (old code may break)

• MINOR version (x.Y.z):
  Increment when you add new, backward-compatible features.
  Example: 1.2.3 → 1.3.0 (new features, old code still works)

• PATCH version (x.y.Z):
  Increment when you make backward-compatible bug fixes.
  Example: 1.2.3 → 1.2.4 (only bug fixes, safe to update)

Examples

Version Change	What Happened	Example
1.2.3 → 2.0.0	Breaking change	MAJOR
1.2.3 → 1.3.0	New feature, no breakage	MINOR
1.2.3 → 1.2.4	Bug fix, no breakage	PATCH

Special labels

• Pre-release: 2.0.0-beta, 1.3.0-rc.1
• Build metadata: 1.2.3+exp.sha.5114f85

Summary

Semantic versioning uses a 3-part number to clearly communicate the impact of software changes, helping everyone update safely and confidently.

For more: semver.org

---

How to run the application

Step 1

Start the DataCite Localstack Container. docker compose up --build

Step 2

Start the Lupo Container. docker compose -f ./docker-compose.localstack.yml up --build

Step 3

Start the Events Service Container. docker compose up --build

Where is the Events Service API available?

The API is available locally at http://localhost:8700

Where is the database?

Currently the database and it's schema is managed by the Lupo application. The Events Service simply communicates with this database. The Events services does not own any part of the database and is not responsible for mutating the schema. For local and testing purposes we use the activerecord-nulldb-adapter Ruby Gem.

---

Adding new Shoryuken workers

1. Add workers to the app/workers directory
2. Ensure you set the shoryuken_options e.g. shoryuken_options queue: -> { "#{ENV['RAILS_ENV']}\_events" }, auto_delete: true
3. Queues use environment prefixes. The prefix is set with the environment variable RAILS_ENV locally.

---

Starting the Shoryuken workers

1. Workers are spun up by default on app start.
2. The environment variable DISABLE_QUEUE_WORKER is used in development to switch the worker on or off when you start the container.
3. The DISABLE_QUEUE_WORKER is set to false by defalt in the docker-compose.yml i.e. DISABLE_QUEUE_WORKER=false
4. If you you want to disable the queue workers from starting up you can set DISABLE_QUEUE_WORKER to true i.e. DISABLE_QUEUE_WORKER=true