Docs
Getting Started
Setup Frigg
Pre Docker (deprecated)

Setup Frigg

❗This section is only applicable for customers that still utilize a non-docker version of Frigg, which is no longer available to new customers

Follow these steps to set up your Frigg repository in GitLab.

Prerequisites:

  • one or more GitLab groups (with potential subgroups) that you want to start managing through Frigg
  • a local copy of Frigg’s source code

Set up repository

  1. Create a Group Access Token called “Frigg API Token” with the scope api on the GitLab group you want to manage. Hold onto the token.
  2. Make a new GitLab project called “frigg” under the GitLab group you want to manage with Frigg. (In case you do not want to let Frigg manage itself as well, you can place Frigg outside this group.)
  3. Go to your Frigg project > Settings > CI/CD and add the following environment variables:
  • GITLAB_BASE_GROUP: the GitLab short url of the base group you want to display your auth matrix for. E.g. foo/bar.
  • GITLAB_FRIGG_PROJECT: the short GitLab ID of your Frigg project. E.g. 12345678.
  • GITLAB_TOKEN: the Group Access Token as created in step 1. Ensure to mark it as masked.
  • GITLAB_URL: the URL of your GitLab instance. If using GitLab cloud it should be https://gitlab.com.
  • RESOURCES_PATH: the path to the folder holding your resource files relative to Frigg’s backend folder. This guide assumes ./../resources.

Local environment

Before pushing any files to your Frigg project and attempting to apply any resources, let’s set up the local environment first.

Project Structure

  • /backend contains a NodeJS application with all logic for exporting, validating, dry-running and applying resource files.
  • /docs contains architecture decision records of Frigg.
  • /pages-generator contains a NextJS project for generating the Auth Matrix.
  • .gitlab-ci.yml contains CI/CD pipelines for applying Frigg resources.
  • .tool-versions specifies the runtimes that should be used to run Frigg locally. See ASDF.

Local .env

Create a file named .env in /backend with the following variables.

  • RESOURCES_PATH
  • GITLAB_URL
  • GITLAB_FRIGG_PROJECT
  • GITLAB_TOKEN

These should correspond to the CI/CD variables in Frigg’s GitLab project.

Export GitLab

  1. Open your terminal in the root of your Frigg project.
  2. Set up your runtimes with ASDF.
  3. Run cd backend
  4. Run yarn install
  5. Run yarn start --help to see an overview of all commands
  6. Run yarn start --export-gitlab=<group_path,group_path2,...> to export your GitLab to resource files. The group paths should be the short GitLab URL, e.g. foo/bar.

If all steps run successfully, continue to the next step.

Adjust your defaults

Resources will leave out any configuration that matches the desired default configuration. Open /backend/src/res/defaults.yaml. Adjust the default configuration values to your desire. Make sure to re-run your exports to take the new defaults into account.

Dry-run apply

Let’s execute a local dry-run of applying the resource files once you’re content with the files exported to /resources in the previous steps:

  1. Open your terminal in /backend
  2. Run yarn start --apply --dry-run
  3. Observe the change list and resolve any validation errors printed to the console

The change list could contain only minimal changes, especially in case you haven’t adjusted any configuration after exporting resource files.

Finalising setup

To ensure Frigg can succesfully apply resource files, let’s run an actual apply locally before pushing to the repository:

  1. Open your terminal in /backend
  2. Run yarn start --apply --dry-run=false
  3. Resolve any issues if they occur
  4. Push Frigg to your Frigg repository on GitLab

This concludes the basic set up.

Scheduled Pipeline

Some people may accidentally change configuration outside of Frigg. To prevent a drifting discrepancy between your resource files and the actual configuration of your resources, let’s set up a scheduled pipeline which runs Frigg’s apply periodically:

  1. Go to your Frigg’s GitLab project > Build > Pipeline schedules.
  2. Create a new schedule with your default branch as target, and set it to active.