As a prerequisite for running Urdr during development, you need to run a local installation of Redmine. The NBIS Redmine installation is currently maintained in the ops-redmine repository.
Follow
the instructions
to set up and run Redmine locally. The repository may be cloned in a
separate directory, away from where you cloned the urdr repository.
The setup of Redmine includes importing a database dump of Redmine
in your local Redmine database. The database dump file should be
named redmine_db.dump, and it should be placed in that repository's
initdb.d directory.
In the top-most directory of the urdr repository, create the
file urdr.env, using urdr.env.default as the template. If you
are on Linux, you need to set the variables REDMINE_URL and
PUBLIC_REDMINE_URL to the
value "http://172.17.0.1:3000". The PUBLIC_API_URL
variable should be set to the URL from which the service is publicly
accessible, e.g. "http://localhost:4567" during development.
The database used by the Urdr backend containing the Urdr schema and default values is created automatically when it is first accessed by the backend Go code. If this database, for whatever reason, needs to be manually be re-created, you may do so using the following set of commands:
rm -f backend/database.db
sqlite3 backend/database.db <backend/sql/schema.sql
sqlite3 backend/database.db <backend/sql/setting-defaults.sqlThe database must also contain information about invalid issue+activity
pairs, as well as information about Redmine groups and users. In
production, this is information that is updated on a regular basis
by running the two update script in backend/sql. On a development
system, these scripts may be invoked like so:
./backend/sql/update-invalid_entry.sh "$REDMINE_REPO"/docker-compose.yml backend/database.db
./backend/sql/update-groups.sh "$REDMINE_REPO"/docker-compose.yml backend/database.db... where "$REDMINE_REPO" is some path to the cloned ops-redmine
repository. Note that the Redmine postgres container is assumed to be
running when these scripts are called.
The name and location of the database file are configurable by setting
BACKEND_DB_PATH in the urdr.env file. The value of that variable is
a pathname relative to the backend directory, and the default value is
./database.db.
Finally, you can start Urdr by using:
docker-compose build
docker-compose upThere are tests for each part of the backend API, which can be tested by the following command:
go test -v ./...In order to rebuild the API spec you should run:
# For installing swag, follow https://github.com/swaggo/swag
swag init -g api/api.goIn order to run the node-urdr server in a Docker container, you don't need to install frontend packages locally. However, for your IDE (e.g. VSCode) to deal properly with React and other packages, a local install might be needed. To do that:
- Move to the
/frontenddirectory - Run
npm ci.
In order to avoid dependency differences between local environments we create our package-lock.json file in a separate Docker container.
If you want to add a new dependency to the project:
- add it in the
package.jsonfile using semantic versioning. We usually specify versions using the Caret (^) to automatically include minor releases, for example
"typescript": "^4.5.5"- move to the
frontendfolder and run./update-package-lock. A newpackage-lock.jsonfile will be created. - add, commit and push
package.jsonandpackage-lock.jsonto GitHub.
Have in mind that these steps will also update existing dependencies according to the rules specified in package.json.
Afterwards, you will have to rebuild the Docker container that runs the Node.js server. Do like this:
docker-compose down node-urdr --volumes
docker-compose build node-urdr
docker-compose up node-urdrIf you only want to update dependencies, follow the same steps but skip adding a new dependency.
