Add Docker + GitHub Actions + Update deps & docs

[theblackhole]

Changes made with this Pull Request:

TL;DR: ➕ Docker ➕ GitHub Actions ➡️ config.js → .env 🔄 Dependencies ✍️ Readme

• Docker support:
  • New Docker stack based on alpine. This stack is multi-arch (works both on x86/amd64 and ARM64/aarch64)
    • Based on the latest nodejs LTS (22), it includes dbus, openjdk21 (JRE) and signal-cli
    • An entrypoint script starts the signal-cli dbus daemon, wait few seconds (customizable delay) then launch telegram-signal-bridge
  • This stack has 2 variants:
    • prod (production) where code is included in the docker image (download+npm install on build)
      • Repository url and tag can be customized so contributors can test their release candidate build locally before creating a new PR
    • dev (development) where this step is skipped and the local repository is bind-mounted to the container
• GitHub Actions workflow:
  • With this workflow, Docker images are automatically built, tagged, signed and pushed on GitHub registry (ghcr.io) when:
    • A commit has been pushed on main
    • A semver tag (v*..) has been pushed
  • If this workflow is triggered from a fork, this will automatically use the fork codebase when building the image and push the result image on the fork's registry
  • Pull Requests should also trigger the workflow to check if build is valid but no image will be pushed
• Config data in .env:
  • Config data has been moved to environment variables stored in a .env file in order to both work locally and with Docker. This is also easier to work with (overrides etc) than a .js file
• Updated dependencies:
  • Dependencies has been updated (telegraf + nodejs)
    • Note: dbus-next seems abandonned, last release is from 2021. Maybe starting to look for an alternative would be wise.
• Updated Readme:
  • Docker instructions added
  • Some instructions are updated to be more detailed
  • Markdown formatting is fixed
  • Note: I also updated signal-cli's instructions with a landline registration tutorial (and mentionned in telegram-signal-bridge's readme) because I think this is a great way to use it for a bot account

[peoro]

Hello @theblackhole. Wow, that's a lot of work.

I'm no longer using this project and don't have a way to test your changes. I'm uncertain on what to do. Should I just merge your PR, or would you want to take ownership of the project?

[theblackhole]

Hello @peoro,

Hum I don't know either.
I originally did this years ago (and only finished it now) to provide a base that would facilitate the deployment of the bridge (because my server on which it runs only supports containers) and plan to experiment with media, reactions, etc. later (+ plan to find another dbus library that would be better maintained than the current one). But I don't know if I'm going to spend a lot of time on it... It could also be that, since then, someone has already done it elsewhere, I'd have to look...

If you don't want to/can't maintain the repo anymore, rather than transferring full ownership to me I see 3 options:

• either just merge the PR for this time, if you look at the files you'll see that apart from the configuration, the changes are all external to your code and everything can still run natively, without Docker.
• or add me as a contributor: you would keep the ownership but I would have direct write access to the repo and would not depend on you for the PRs.
• or create a "telegram-signal-bridge" organization (you can do it, or me if you don't want to deal with that) on which you would transfer the repo and in which we would both be owners. This is the option that gives the most flexibility if the project evolves.

I think we can start with option 1 or 2 and see later for 3 if it's worth it.

[peoro]

I sent you an invitation to become a contributor to the project. I'll be happy to further change things whenever you or others feel the need.

[theblackhole]

Thanks. I'll merge this then :)