configuration.js Documentation

Official TypeScript developer resources and documentation for LizardByte/configuration.js. Verified technical context for AI.

0 stars TypeScript TypeScript 1 file · ~4,369 tokens
RAW Doc

1. Project Overview & Quickstart (LizardByte/configuration.js)

configuration.js

Open-source repository LizardByte/configuration.js

Repository Details

Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.

2. Official Technical Reference & Guides (LizardByte/LizardByte.github.io)

File: README.md

About

This repo contains the source files for the LizardByte website.

The page is built using jekyll and hosted on GitHub Pages.

CrowdIn Localization

Reusable Workflow

This repo contains a reusable workflow to allow for building gh-pages subprojects using the same configuration.

yml
---
name: Jekyll CI
permissions:
  contents: read

on:
 pull_request:
   branches:
     - master
   types:
     - opened
     - synchronize
     - reopened

concurrency:
 group: "${{ github.workflow }}-${{ github.ref }}"
 cancel-in-progress: true

jobs:
  prep:
    runs-on: ubuntu-latest
    steps:
      # Prepare your site here if needed, you can run any build steps needed to generate the site
      # The structure of the artifacts must be exactly as you expect to find the files in the final site
      # e.g. `index.html` should be at the root of the artifact, not in a subdirectory
      - name: Sample build
        run: echo "Hello, world!" > hello.txt

      - name: Upload artifact
        uses: actions/upload-artifact@v4
        with:
          name: prep  # any name except 'site' is allowed
          path: hello.txt
          if-no-files-found: error
          include-hidden-files: true
          retention-days: 1

  call-jekyll-build:
    needs: prep
    uses: LizardByte/LizardByte.github.io/.github/workflows/jekyll-build.yml@master
    secrets:
      GH_BOT_EMAIL: ${{ secrets.GH_BOT_EMAIL }}
      GH_BOT_TOKEN: ${{ secrets.GH_BOT_TOKEN }}
    with:
      gh_bot_name: ${{ vars.GH_BOT_NAME }}
      site_artifact: 'prep'  # any name except 'site' is allowed
      target_branch: 'gh-pages'
      clean_gh_pages: true

For additional options see jekyll-build.yml

PR Previews

Changes to gh-pages can be previewed, by setting up the project in ReadTheDocs.
It is recommended to use the following manual configuration:

Initial setup:

yml
Name: LizardByte-gh-pages-<repo_name>  # the project slug cannot be changed after creation
Repository URL: https://github.com/LizardByte/<repo_name>.git
Default-branch: master
Language: English

Project Settings:

yml
Connected-repository: https://github.com/LizardByte/<repo_name>.git
URL-versioning-scheme: Multiple versions without translations
Path-for-.readthedocs.yaml:  # only set if not in the root of the repo
Programming-Language: Other
Project-homepage: https://app.lizardbyte.dev/<repo_name>
Build-pull-requests-for-this-project: true

Environment Variables:

yml
# REQUIRED
GITHUB_WORKFLOW: call-jekyll-build / Build Jekyll
SITE_ARTIFACT: prep.zip  # the name of the artifact to look for in the workflow

# OPTIONAL
CONFIG_FILE: _config.yml
EXTRACT_ARCHIVE: pre_built_database.zip  # if there is a nested archive to extract
GITHUB_TIMEOUT: 10  # timeout in minutes to use when searching for GitHub artifacts, max 15
THEME_REF: master

Additionally, do the following:

  1. Deactivate the stable version
  2. Make the latest version hidden
  3. Update branch protection rules in GitHub repo settings to require status checks from ReadTheDocs
  4. Add the below .readthedocs.yaml file to the root of the repo, or a custom path as specified in the project settings
yml
---
# Read the Docs configuration file
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details

version: 2

build:
  os: ubuntu-24.04
  tools:
    ruby: "3.3"
  apt_packages:
    - 7zip
    - jq
  jobs:
    install:
      - |
        mkdir -p "./tmp"
        branch="master"
        base_url="https://raw.githubusercontent.com/LizardByte/LizardByte.github.io"
        url="${base_url}/refs/heads/${branch}/scripts/readthedocs_build.sh"
        curl -sSL -o "./tmp/readthedocs_build.sh" "${url}"
        chmod +x "./tmp/readthedocs_build.sh"
    build:
      html:
        - "./tmp/readthedocs_build.sh"

File: _posts/guides/1970-01-01-blog-guide.md

layout: post
title: Blog Guide
gh-repo: LizardByte/LizardByte.github.io
gh-badge: [follow, star]
readtime: true
tags: []
comments: false

simple-tabs-example:

  • name: 'Tab A'
    content: 'Content of tab A'
  • name: 'Tab B'
    content: 'Content of tab B'

indexed-tabs-example:

  • name: 'cURL'
    content:
    text
    ```bash
curl -L https://example.com
```
    • |
      bash
      curl -L https://google.com
  • name: 'Python'
    content:
    text
    ```python
import requests
response = requests.get('https://example.com')
print(response.text)
```
    • |
      python
      import requests
response = requests.get('https://google.com')
print(response.text)

Admonitions

Usage

You can use admonitions with the following syntax:

markdown
{% raw %}
{% include admonition.html type="important" body="This is information intended to draw attention." %}
{% endraw %}

Optionally, a custom title can be added:

markdown
{% raw %}
{% include admonition.html type="hint" title="Custom Title" body="This is information intended to draw attention." %}
{% endraw %}

Types

Valid types of admonitions are:

  • attention
  • caution
  • danger
  • error
  • hint
  • important
  • note
  • seealso
  • tip
  • todo
  • warning

Examples

{% include admonition.html type="attention" body="This is information intended to draw attention." %}
{% include admonition.html type="caution" body="This is information intended to draw attention." %}
{% include admonition.html type="danger" body="This is information intended to draw attention." %}
{% include admonition.html type="error" body="This is information intended to draw attention." %}
{% include admonition.html type="hint" body="This is information intended to draw attention." %}
{% include admonition.html type="important" body="This is information intended to draw attention." %}
{% include admonition.html type="note" body="This is information intended to draw attention." %}
{% include admonition.html type="seealso" body="This is information intended to draw attention." %}
{% include admonition.html type="tip" body="This is information intended to draw attention." %}
{% include admonition.html type="todo" body="This is information intended to draw attention." %}
{% include admonition.html type="warning" body="This is information intended to draw attention." %}

Simple-Tabs

Usage

You can use simple tabs with the following syntax:

markdown
{% raw %}
{% include tabs.html tabs=page.simple-tabs-example %}
{% endraw %}

The tabs object must have a name and content field. The content field should be a string when using simple tabs.

Example

{% include tabs.html tabs=page.simple-tabs-example %}

Indexed-Tabs

Usage

You can use indexed tabs with the following syntax:

markdown
{% raw %}
{% include tabs.html tabs=page.indexed-tabs-examples index=0 %}
{% endraw %}

The tabs object must have a name and content field.
The content field should be an array of strings when using indexed tabs.

Examples

Index 0

{% include tabs.html tabs=page.indexed-tabs-example index=0 %}

Index 1

{% include tabs.html tabs=page.indexed-tabs-example index=1 %}

File: _posts/guides/2024-02-01-multi-platform-cpp-development-in-clion.md

layout: post
title: Multi-platform C++ development in CLion
subtitle: How to set up CLion to handle Linux, macOS, and Windows development in a single project
gh-repo: LizardByte/LizardByte.github.io
gh-badge: [follow, star]
readtime: true
tags: [clion, c++, cpp, cmake, dev, guide, linux, macos, windows]
thumbnail-img: /assets/img/thumbnails/clion.png
comments: true
authors:

  • github: ReenigneArcher

Introduction

When developing multiplatform C++ projects, it can be frustrating to have to switch between different systems to
develop, inspect, and test your code. This is especially true when you are working on a project that has dependencies.

Without the proper setup, you may find your IDE complaining about missing headers, libraries, etc.

This example shows 975 problems in this single file.

In this post, I will show you how to set up CLion to handle Linux, macOS, and Windows development in a single project,
and from a single system.

Prerequisites

  • CLion
  • Method(s) of Virtualization (Docker, WSL, or virtual machine)

Setting up the remote environment

Docker

  1. Create a Dockerfile in your project, ensuring that all the project build dependencies are installed.
    Below is an example.

    dockerfile
    FROM ubuntu:22.04

RUN DEBIAN_FRONTEND="noninteractive" apt-get update && apt-get -y install tzdata

RUN apt-get update \
  && apt-get install -y build-essential \
      gcc \
      g++ \
      gdb \
      clang \
      make \
      ninja-build \
      cmake \
      autoconf \
      automake \
      libtool \
      valgrind \
      locales-all \
      dos2unix \
      rsync \
      tar \
      python \
      python-dev \
  && apt-get clean

  2. Right-click on the Dockerfile and select Modify Run Configuration.

  3. Set an image tag and container name. Optionally, enable BuildKit and set a context folder, depending on the content
    of your Dockerfile.

  4. Right-click on the Dockerfile and select Run '<name of your Dockerfile>'.

WSL

  1. Follow the how to install Linux on Windows with WSL
    instructions.
  2. Install the necessary build tools and dependencies according to the Linux distribution you have chosen.

Virtual machines

Due to the variety of hypervisors available, I will not go into detail on how to set up a virtual machine.
The general idea is to install the OS of your choice, enable SSH, and install the necessary build tools and
dependencies.

Installing Linux and Windows virtual machines is generally straightforward. Installing a macOS virtual machine is
more complicated. Therefore, I've decided to leave a link to the guide I used on how to set it up inside Proxmox.
installing macos 13 ventura on proxmox

Setting up CLion

Add SSH configurations

  1. Open CLion and go to File -> Settings -> Tools -> SSH Configurations.
  2. Click the + button and add the SSH configurations for the remote environment(s).

Adding toolchains

  1. Open CLion and go to File -> Settings -> Build, Execution, Deployment -> Toolchains.
  2. Click the + button and select the toolchain you want to add.

Docker

WSL

SSH

Adding CMake profiles

  1. Open CLion and go to File -> Settings -> Build, Execution, Deployment -> CMake.
  2. Click the + button and select the CMake profile you want to add.

Update project

The last step is to reload the project.

  1. Open the CMake tab and click the reload button.

Depending on the project and remote environment(s), this may take some time. However, once it is finished, you should
be able to build, run, and debug your project on all the remote environments simultaneously.

The number of problems detected by CLion was reduced from 975 to 367.

Conclusion

In this post, I showed you how to set up CLion to handle Linux, macOS, and Windows development in a single project,
all from a single system. Hopefully, this will help you to be more productive and efficient when developing your C++
projects.

File: _posts/guides/2024-12-08-git-commit-signing-in-windows.md

layout: post
title: Signing Git Commits in Windows
subtitle: How to sign your Git commits in Windows using GPG and Kleopatra
gh-repo: LizardByte/LizardByte.github.io
gh-badge: [follow, star]
readtime: true
tags: [dev, git, github, guide, windows]
comments: true
authors:

  • github: ReenigneArcher

Introduction

Have you ever wanted to sign your Git commits, and get the fancy Verified badge on your commits in GitHub?
This post will show you how to sign your Git commits in Windows using GPG and Kleopatra.

Prerequisites

  1. Download and install Gpg4win, ensuring that Kleopatra option is selected.

Create new OpenPGP certificate

  1. Open Kleopatra and select "New Key Pair"

  2. Enter your GitHub username and email. The email must be one you have assigned to your GitHub account.
    You can find your no-reply email https://github.com/settings/emails on this page if you have one set.

  3. Optionally, expand "Advanced Options" and change the "Key Material" option. I used "rsa4096".
    You can also change or disable the expiration date.

  4. Select "OK".

Configure git

  1. Open terminal (cmd.exe or PowerShell) and run the following command.

    bash
    gpg --list-secret-keys --keyid-format LONG

  2. Copy the key id. 1234567890ABCDEF is the id in the example below.

    text
    sec   rsa4096/1234567890ABCDEF 2024-12-08 [SC]
      ABCDEF1234567890ABCDEFGH1234567890ABCDEF
uid                 [ultimate] GitHub-Username <GitHub-Email-Address>
ssb   rsa4096/0987654321FEDCBA 2024-12-08 [E]

  3. Run the following command to configure git to use the key.

    bash
    git config --global user.signingkey <KEY-ID>

  4. If git cannot find gpg you may need to add the path to the gpg executable to your git configuration.
    You can find the path to gpg by running the following command.

    bash
    where gpg

    Then add the path to your git configuration.

    bash
    git config --global gpg.program "C:\Program Files (x86)\GnuPG\bin\gpg.exe"

  5. Run the following command to enable commit signing.

    bash
    git config --global commit.gpgsign true

Configure GitHub

  1. Right-click the key in Kleopatra, select "Details", then "Export". Select all the contents and copy them.
  2. Go to your GitHub account settings, and select "SSH and GPG keys".
  3. Click "New GPG key". Give the key a title, and paste the contents of the public key into the key field.
  4. Click "Add GPG key".

Automatically start Kleopatra

  1. Open the Windows Task Scheduler.

  2. Optionally, create a new folder for the task.

  3. Select the folder, and then click "Create Task".

  4. Enter a name for the task, such as "Open Kleopatra".

  5. Select "Run only when user is logged on".

  6. Click the "Triggers" tab, then "New".

  7. Select "At log on" from the "Begin the task" dropdown.

  8. Select "Specific user", and click "OK".

  9. Click the "Actions" tab, then "New".

  10. Click "Browse", and select the Kleopatra executable.
    The default location is "C:\Program Files (x86)\Gpg4win\bin\kleopatra.exe"

  11. In the "Start in" field, enter %HOMEDRIVE%%HOMEPATH%, and click "OK".

  12. On the "Conditions" tab, uncheck everything.

  13. On the settings tab, ensure the following options are set.

    • Allow task to be run on demand (checked)
    • Run task as soon as possible after a scheduled start is missed (checked)
    • If the task fails, restart every 1 minute (checked)
    • Attempt to restart up to 3 times
    • Stop the task if it runs longer than (unchecked)
    • If the running task does not end when requested, force it to stop (checked)
    • If the task is not scheduled to run again, delete it after (unchecked)
    • If the task is already running, then the following rule applies (Do not start a new instance)

  14. Click "OK".

Revoking a Key

In some cases you may need to revoke a key. To do this follow the steps below.

  1. Open Kleopatra, right-click on the key, and select "Revoke Certificate".
  2. Select the reason for revoking the key, and click "Revoke Certificate".
  3. Right-click the key again, select "Details", then "Export". Select all the contents and copy them.
  4. Go to your GitHub account settings, and select "SSH and GPG keys".
  5. Remove the old key, and click "New GPG key". Give the key a title (such as "Revoked Key"),
    and paste the contents of the public key into the key field.

Alternatively, this can be done via command line.
See How to actually revoke a GitHub GPG key

This approach will allow previously verified commits to remain verified.

Caveats

  • Commits made before your key was created cannot be verified, even if you amend the commits. This can be annoying if
    you have any WIP commits that you want to amend. A simple workaround for this is to start an interactive rebase,
    and edit each commit to adjust. Finally, when you amend the commit do so with the following command.

    bash
    git commit --amend --date=now --no-edit

Conclusion

You should now be able to sign your Git commits in Windows using GPG and Kleopatra. I'd like to give credit to
Tom Auger for his blog post which helped me
figure out how to do this initially.

Explore Related Technologies & Topics

View All 9,111+ Repositories →

Discover similar high-velocity repositories, agent skills, and OpenAPI specifications across the ecosystem.

⚡ MCP Servers Model Context Protocol → 🧠 Agent Skills Prompt & rule files → 🔌 OpenAPI Specs REST & Swagger schemas →