Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • dev protected
  • ckan-2.11.0
  • add-package-custom-fields
  • fix-adding-datasets-for-users-and-editors
  • add-auth-subroute
  • 71-migrate-custom-fields-to-ckanext-scheming
  • add-author-maintainer-information
  • fix-inline-flex-btns
  • fix-known-spatial-uri-validation
  • py3
  • 47-aktuelle-resource-einer-collection-wird-nicht-mehr-gefunden
  • 10-eingabe-der-dct-accrualperiodicity-in-weboberflache
  • v1.3
  • 2.5.2
  • 2.5.1
  • 2.5.0
  • 2.4.7
  • 2.4.6
  • 2.4.5
  • 2.4.4
  • 2.4.3
  • 2.4.2
  • 2.4.1
  • 2.4.0
  • 2.3.1
  • 2.3.0
  • 2.2.0
  • 2.1.0
  • 2.0.0
  • 1.4.3
  • 1.4.2
  • 1.4.1
  • 1.4.0
34 results

ckanext

  • Clone with SSH
  • Clone with HTTPS
  • OZG Frontend

    The front end project for the OZG cloud.

    Quickstart

    Runs all the build scripts in antragsraum-client/client folder

    $ npm install
    $ npm run build

    And start the development server:

    $ npm start

    Docker build ozg-frontend-client locally

    (Ensure, Docker daemon is running)

    cd /client/docker
    $ docker compose up

    Docker build ozg-frontend-docs (Styleguidist) locally

    (Ensure, Docker daemon is running)

    If you only need to run the docker container without all the build steps:

    cd /client/docs
    $ docker compose up

    Run the CSS regression tests

    The CSS tests run with BackstopJS. This framework compares the snapshots from a running URL against some reference images. The references are saved in **client/backstop/backstop_data/bitmaps_reference **.

    At the moment we test the desktop and mobile view of the styleguidist component documentation page. So before running the CSS regression tests you need to first run the component docs:

    $ npm run styleguidist

    And then run the test css script:

    $ npm run test:css

    This will start a docker container with a headless browser. If it fails you need to check in the directory * client/backstop/backstop_data/bitmaps_test* and find in the last directory the failed diff.

    If the change was intentional you can update the references with the following script:

    $ npm run backstop:approve

    Available NPM Scripts

    In the client directory, you can run:

    npm start

    Runs the app in the development mode.
    Open http://localhost:8082 to view it in the browser.

    The page will reload if you make edits.
    You will also see any lint errors in the console.

    npm run build:typescript

    Compiles the TypeScript files into JavaScript and stores the result in the build folder.

    npm run build:webpack

    Runs Webpack to create the deployment artefacts for the application in the /dist folder.

    npm run test:unit

    Launches the test runner in the interactive watch mode.
    See the section about running tests for more information.

    npm run test:e2e

    To open the Cypress to create and run e2e test.

    npm run check

    Runs all the checks

    npm run check:prettier

    To run prettier find format problems with your JavaScript code.

    npm run check:lint

    To run eslint find and fix problems with your JavaScript code.

    npm run prettier:write

    To run prettier to format the sources.

    npm run styleguidist

    To run the styleguidist component documentation server.
    Open http://localhost:6060 to view the documentation.

    npm run styleguidist:build

    To build the styleguidist artefacts under the /styleguide folder.

    npm run test:css

    Runs the CSS regression tests (see bellow for more details).

    npm run backstop:approve

    Updates the CSS regression test references according to the last test result (see bellow for more details).

    Environment configuration

    There are two types of env configuration variables:

    • ones set via an .env file/manually setting environment variables that are read at compile-time with fixed values afterwards (or alternatively read at startup of the Webpack dev server for development purposes). There is a whitelist in webpack.config.js that makes sure that only the specific environment variables we actually use are passed to the application. Currently defined variables are the following:

      • NODE_ENV: should be either "production", "development" or empty (which then assumes "development") to activate/deactivate features that should only be available in a dev build
      • PROJECT_NAME: set by Webpack and is shown in version info
      • PROJECT_VERSION: set by Webpack and is shown in version info
      • ANTRAGSRAUM_HOST: the base URL of the Antragsraum API if the Webpack dev server is used
      • INFO_MANAGER_HOST: the base URL of the Info Manager if the Webpack dev server is used
    • ones set via an env.js file. These are environment variables that should be configurable at run time. These are the following:

      • REDIRECT_URL: The URL where the login entry point is located. For use with BayernId this should be something like '/antragsraum/saml2/authenticate/bayernid'. When using with BayernId this must match the entry in the metadata document send to Akdb. For local dev use this value must be '/antragsraum/login'.
      • LOCALE_BUTTON: if set to "true", show a button on the overview page that toggles the language between German and English (to demonstrate the currently available localisation features)

    Running with a local backend

    To run the frontend alongside a locally running backend, you need to set the respective env variable so that the backend can be found by the frontend:

    ANTRAGSRAUM_HOST=http://localhost:8080

    You need to start the backend according to the documentation in antragsraum-server. The most simple way to get a working backend with mocked data is to run the backend in standalone mode.