bsquizz / content-sources-backend

Backend for content sources service

Content Sources

What is it?

Content Sources is an application for storing information about external content (currently YUM repositories) in a central location.

Developing

Requirements:

1. podman installed or docker installed (and running)

Create your configuration

Create a config file from the example:

$ cp ./configs/config.yaml.example ./configs/config.yaml

Start / Stop postgres

• Start the database container by:

  $ make db-up

---

• You can stop it by:

  $ make db-down

• And clean the volume that it uses by (this stop the container before doing it if it were running):

  $ make db-clean

• Or inspect inside the container if necessary meanwhile it is running by:

  $ podman exec -it postgresql bash

Migrate your database (and seed it if desired)

$ make db-migrate-up

$ make db-migrate-seed

Run the server!

$ make run

Hit the api:

curl http://localhost:8000/api/content_sources/v1.0/repositories/ ```

Generating new openapi docs:

$ make openapi

Configuration

The default configuration file in ./configs/config.yaml.example shows all available config options. Any of these can be overridden with an environment variable. For example "database.name" can be passed in via an environment variable named "DATABASE_NAME".

Code Layout

Path	Description
api	Openapi docs and doc generation code
db/migrations	Database Migrations
pkg/api	API Structures that are used for handling data within our API Handlers
pkg/config	Config loading and application bootstrapping code
pkg/dao	Database Access Object. Abstraction layer that provides an interface and implements it for our default database provider (postgresql). It is separated out for abstraction and easier testing
pkg/db	Database connection and migration related code
pkg/handler	Methods that directly handle API requests
pkg/models	Structs that represent database models (Gorm)
pkg/seeds	Code to help seed the database for both development and testing

Contributing

• Pull requests welcome!
• Pull requests should come with good tests
• All PRs should be backed by a JIRA ticket and included in the subject using the format:
  • Fixes 23: Some great feature - if a PR fully resolves an issue or feature, or is the last PR in a series of PRs.
  • Refs 23: Partial work for issue - if a PR partially resolves an issue or feature or is not the last PR in a series of PRs.
  • If you do not have access to the Jira (we are working on opening it up), open a PR without this and we will add it for you.

More info

• Architecture