make duckdb data persist to a file
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-07-29 00:42:29 +00:00
.forgejo/workflows get log rotation going 2026-07-29 00:42:29 +00:00
debian get log rotation going 2026-07-29 00:42:29 +00:00
otel-front@81bc0cf4f5 add otel-front as submodule 2026-07-24 15:15:10 +00:00
.gitignore Initial commit 2026-07-24 02:18:51 +00:00
.gitmodules add otel-front as submodule 2026-07-24 15:15:10 +00:00
duckdb.patch add patch for persistent database 2026-07-28 00:46:46 +00:00
LICENSE Initial commit 2026-07-24 02:18:51 +00:00
local.yml put .service file in 2 places 2026-07-27 16:26:31 +00:00
localhost-binding.patch bind to localhost 2026-07-27 19:09:19 +00:00
README.md commit further instructions 2026-07-28 01:16:29 +00:00

otel-front-persistent

make duckdb data persist to a file

TODO ... Refactor

Yes, everything else is completely static. The control file is the only file that requires dynamic input because it embeds the specific build version string (${CLEAN_VER}). The Python script, the Systemd service units, the Systemd timer, and your postinst script are entirely fixed text. You can organize your repository by putting all your static files into a debian/ folder, and handling that single dynamic block directly inside your Action step.

1. Your New Repository Layout

Create a debian directory tree in your main repository containing only your static files:

debian/ ├── DEBIAN/ │ └── postinst ├── lib/ │ └── systemd/ │ └── system/ │ ├── otel-front-rotate.service │ ├── otel-front-rotate.timer │ └── otel-front.service └── usr/ └── lib/ └── otel-front/ └── rotate.py

2. The Refactored Forgejo Action Step

Your pipeline step becomes clean and compact. It copies your committed static files, writes the quick dynamic control block, drops the compiled binary into the folder tree, and builds the package:

5. Construct the Debian Package structural filesystem mapping

  - name: Build Debian Package Structure
    run: |
      CLEAN_VER="${{ github.ref_name }}"
      CLEAN_VER="${CLEAN_VER#v}"
      STAGING_DIR="otel-front_${CLEAN_VER}_amd64"
      
      # 1. Copy your committed static layout file tree
      cp -r debian "${STAGING_DIR}"
      
      # 2. Inject the dynamically built binary
      mkdir -p "${STAGING_DIR}/usr/bin"
      cp otel-front/bin/otel-front "${STAGING_DIR}/usr/bin/otel-front"
      chmod 755 "${STAGING_DIR}/usr/bin/otel-front"
      
      # 3. Generate the dynamic control file directly into the staging space
      cat << EOF > "${STAGING_DIR}/DEBIAN/control"
      Package: otel-front
      Version: ${CLEAN_VER}
      Section: utils
      Priority: optional
      Architecture: amd64
      Maintainer: DevOps Admin <admin@k3p.io>
      Description: OpenTelemetry Frontend service compiled from submodule tag
      EOF
      
      # 4. Enforce maintainer script execution rights
      chmod 755 "${STAGING_DIR}/DEBIAN/postinst"
      
      # 5. Compile the Debian package archive
      dpkg-deb --build "${STAGING_DIR}"
      
      # Pass the final file context down to the release action step
      echo "DEB_FILENAME=${STAGING_DIR}.deb" >> $GITHUB_ENV

Next Steps to Finalize

Make sure to create your static text files locally on your machine, add them to your Git stage, and commit them. When you create the debian/DEBIAN/postinst file locally on your development system, run chmod +x debian/DEBIAN/postinst before doing your git commit. Git tracks the file execution bit internally, which ensures it arrives in your Forgejo runner with the correct executable properties.