https://github.com/datacite/events

DataCite Events Service
https://github.com/datacite/events

Last synced: 4 months ago
JSON representation

DataCite Events Service

• Host: GitHub
• URL: https://github.com/datacite/events
• Owner: datacite
• License: mit
• Created: 2025-02-27T13:13:25.000Z (over 1 year ago)
• Default Branch: main
• Last Pushed: 2026-01-16T18:31:34.000Z (5 months ago)
• Last Synced: 2026-01-17T06:27:47.686Z (5 months ago)
• Language: Ruby
• Size: 1000 KB
• Stars: 0
• Watchers: 6
• Forks: 0
• Open Issues: 2
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          
# DataCite Events Service

[![Coverage Status](https://coveralls.io/repos/github/datacite/events/badge.svg?branch=main&t=timestamp)](https://coveralls.io/github/datacite/events?branch=main&t=timestamp)

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

---

### Process Flow Diagram

![Event Service Process Flow Diagram](images/events_service_process_flow.jpg)

---

### Dependencies

Local application development is dependent on [Docker](https://www.docker.com/). Ensure that is installed locally.

Local application development is dependent on [DataCite LocalStack Repository](https://github.com/datacite/datacite_localstack). Ensure that this is cloned locally.

Local application development is dependent on [Lupo](https://github.com/datacite/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](https://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](https://github.com/nulldb/nulldb) 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