Romain Baumier (0bd23b5c) at 16 Mar 16:26

... and 55 more commits

François-Guillaume Ribreau (b41109a5) at 16 Mar 12:47

• Add manual release:patch/minor/major jobs on master branch
• Add git-cliff for changelog generation
• Add cargo-release integration for version bumping
• Add semver-checks for API compatibility validation
• Disable arm64 builds to speed up CI
• Restrict release triggers to master branch only

:rotating_light::rotating_light::rotating_light: Variables to add in gitlab CI: :rotating_light::rotating_light:

  | Variable             | Description                                           | Scope                      |
  |----------------------|-------------------------------------------------------|----------------------------|
  | 🆗 GITLAB_RELEASE_TOKEN | Personal access token avec scope write_repository     | Toutes les releases        |
  | 🆗 NPM_TOKEN            | Token npm automation pour publier sur npmjs.org       | SDK release                |
  | 🆗 CARGO_TOKEN          | Token API crates.io                                   | SDK release                |
  | 🆗 DOCKERHUB_USERNAME   | Username Docker Hub                                   | Container release          |
  | 🆗 DOCKERHUB_TOKEN      | Access token Docker Hub                               | Container release          |
  | 🆗 GITHUB_USERNAME      | Username GitHub pour GHCR                             | Container release          |
  | 🆗 GITHUB_TOKEN         | GitHub PAT avec scope packages:write + contents:write | Container + GitHub release |

Summary by CodeRabbit

• New Features
  • Added automated SDK release pipeline for TypeScript and Rust clients
  • Added semantic versioning validation for SDK releases
• Chores
  • Updated SDK versions to 1.0.0
  • Enhanced release automation and CI/CD infrastructure
  • Updated CI documentation with new configuration variables and release process steps

François-Guillaume Ribreau (ee46a78d) at 16 Mar 12:47

... and 1 more commit

• Add manual release:patch/minor/major jobs on master branch
• Add git-cliff for changelog generation
• Add cargo-release integration for version bumping
• Add semver-checks for API compatibility validation
• Disable arm64 builds to speed up CI
• Restrict release triggers to master branch only

:rotating_light::rotating_light::rotating_light: Variables to add in gitlab CI: :rotating_light::rotating_light:

  | Variable             | Description                                           | Scope                      |
  |----------------------|-------------------------------------------------------|----------------------------|
  | 🆗 GITLAB_RELEASE_TOKEN | Personal access token avec scope write_repository     | Toutes les releases        |
  | 🆗 NPM_TOKEN            | Token npm automation pour publier sur npmjs.org       | SDK release                |
  | 🆗 CARGO_TOKEN          | Token API crates.io                                   | SDK release                |
  | 🆗 DOCKERHUB_USERNAME   | Username Docker Hub                                   | Container release          |
  | 🆗 DOCKERHUB_TOKEN      | Access token Docker Hub                               | Container release          |
  | 🆗 GITHUB_USERNAME      | Username GitHub pour GHCR                             | Container release          |
  | 🆗 GITHUB_TOKEN         | GitHub PAT avec scope packages:write + contents:write | Container + GitHub release |

Summary by CodeRabbit

• New Features
  • Added automated SDK release pipeline for TypeScript and Rust clients
  • Added semantic versioning validation for SDK releases
• Chores
  • Updated SDK versions to 1.0.0
  • Enhanced release automation and CI/CD infrastructure
  • Updated CI documentation with new configuration variables and release process steps

⚠️ Potential issue | 🟠 Major

Avoid direct curl | bash installer execution in CI.

Line 14 executes an unpinned remote script, which weakens supply-chain guarantees for a release gate job. Prefer a pinned installer source (commit/tag) plus checksum verification before execution.

Verify each finding against the current code and only fix it if needed.

In `@ci/semver-checks.gitlab-ci.yml` around lines 14 - 15, The CI currently pipes
an unpinned remote script (install-from-binstall-release.sh) into bash and
installs cargo-semver-checks directly, which is a supply-chain risk; update the
job to fetch a pinned release (specific commit SHA or tag) of the
installer/script and verify its checksum or GPG signature before executing, or
avoid the remote-script path entirely by using a reproducible alternative (e.g.,
install cargo-semver-checks from a verified cargo/crates.io release or use a
pinned cargo-binstall binary) — change references to
install-from-binstall-release.sh and the cargo binstall invocation for
[email protected] so the pipeline downloads a pinned artifact, performs
integrity verification, then executes the trusted installer.

⚠️ Potential issue | 🟠 Major

Avoid embedding credentials in Git remote URLs.

Line 89 places the token directly in the URL, which is high-risk for leakage and scanner findings. Use a clean remote URL plus auth header/credential helper instead.

-    - git remote set-url origin "https://oauth2:${GITLAB_RELEASE_TOKEN}@gitlab.com/${CI_PROJECT_PATH}.git"
+    - git remote set-url origin "https://gitlab.com/${CI_PROJECT_PATH}.git"
+    - git config http.https://gitlab.com/.extraheader "Authorization: Bearer ${GITLAB_RELEASE_TOKEN}"

    - git remote set-url origin "https://gitlab.com/${CI_PROJECT_PATH}.git"
    - git config http.https://gitlab.com/.extraheader "Authorization: Bearer ${GITLAB_RELEASE_TOKEN}"

Verify each finding against the current code and only fix it if needed.

In `@ci/release-sdk.gitlab-ci.yml` at line 89, Replace the embedded-token remote
URL by setting the remote to a clean URL via the existing git remote set-url
origin command (use "https://gitlab.com/${CI_PROJECT_PATH}.git") and stop
interpolating GITLAB_RELEASE_TOKEN into the URL; then authenticate via a safe
mechanism instead (for example configure an HTTP auth header or credential
helper in CI using the GITLAB_RELEASE_TOKEN—set an auth header like
AUTHORIZATION: Bearer $GITLAB_RELEASE_TOKEN or use git credential helper) so the
token is never written into the remote URL. Ensure changes touch the git remote
set-url origin invocation and any CI steps that currently assume the
token-in-URL behavior.

Actionable comments posted: 2

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@ci/release-sdk.gitlab-ci.yml`:
- Line 89: Replace the embedded-token remote URL by setting the remote to a
clean URL via the existing git remote set-url origin command (use
"https://gitlab.com/${CI_PROJECT_PATH}.git") and stop interpolating
GITLAB_RELEASE_TOKEN into the URL; then authenticate via a safe mechanism
instead (for example configure an HTTP auth header or credential helper in CI
using the GITLAB_RELEASE_TOKEN—set an auth header like AUTHORIZATION: Bearer
$GITLAB_RELEASE_TOKEN or use git credential helper) so the token is never
written into the remote URL. Ensure changes touch the git remote set-url origin
invocation and any CI steps that currently assume the token-in-URL behavior.

In `@ci/semver-checks.gitlab-ci.yml`:
- Around line 14-15: The CI currently pipes an unpinned remote script
(install-from-binstall-release.sh) into bash and installs cargo-semver-checks
directly, which is a supply-chain risk; update the job to fetch a pinned release
(specific commit SHA or tag) of the installer/script and verify its checksum or
GPG signature before executing, or avoid the remote-script path entirely by
using a reproducible alternative (e.g., install cargo-semver-checks from a
verified cargo/crates.io release or use a pinned cargo-binstall binary) — change
references to install-from-binstall-release.sh and the cargo binstall invocation
for [email protected] so the pipeline downloads a pinned artifact,
performs integrity verification, then executes the trusted installer.

---

Nitpick comments:
In `@ci/README.md`:
- Around line 89-105: Update the "SDK Release Process" docs to explicitly list
required CI variables (NPM_TOKEN and CARGO_TOKEN) and where they must be set
(pipeline/CI project settings) and clarify whether the semver-checks validation
runs in the release pipeline or during merge requests (reference the
semver-checks job and the trigger-release stage and
sdk-release:patch/minor/major jobs); add a short note about any additional
required permissions or scopes for those tokens and a one-line pointer to the
semver-checks behavior (e.g., "semver-checks runs on MRs" or "semver-checks runs
as part of the SDK release pipeline") so readers know when validation occurs.
- Around line 17-23: Update the "Setup in GitLab" section to list all required
CI variables (e.g., GITLAB_RELEASE_TOKEN, NPM_TOKEN, CRATES_IO_TOKEN,
DOCKERHUB_USERNAME, DOCKERHUB_TOKEN, GITHUB_TOKEN) and add one-line guidance for
obtaining each (link or source: npm personal access token, crates.io API token,
Docker Hub settings, GitHub PAT), then instruct adding them under Settings >
CI/CD > Variables and mark only sensitive secrets (tokens/passwords) as
"Protected" and "Masked" while noting that usernames (e.g., DOCKERHUB_USERNAME)
should be "Protected" but not "Masked"; update the bullet steps in the "Setup in
GitLab" block to reflect these variable names and masking/protection guidance.

In `@cliff.toml`:
- Around line 56-62: There are two duplicate commit-parsing entries matching the
same pattern { message = "^ci" } which makes the later { message = "^ci", group
= "CI" } unreachable; remove or consolidate the duplicate by keeping a single {
message = "^ci", group = "CI" } (or change the original to the intended group)
and delete the other { message = "^ci", ... } entry so only one CI mapping
remains.

Romain Baumier (b41109a5) at 16 Mar 08:43

... and 40 more commits

@dsferruzza aie tu m'as pas ping sur ce commentaire donc je ne l'ai pas vu :/

(je pensais l'avoir fix) pour moi ces tests devraient utiliser nos repository pour créer les ressources, par contre valider la suppression c'est très pertinent car ça nous permet de faire évoluer ce code pour faire du load-test (un user avec beaucoup de données d'associées)

@rbaumier please rebase it and I will merge it then

closing, will re-do it later

Closes #97 !155

closing, will re-do it later

Fixes #29 & #94

Fixes #42 & #29

• Add retry_config column to subscription table (JSONB)
• Update API Subscription struct with RetryConfig
• Modify subscription creation/update handlers to handle retry config
• Update output-worker to read and use per-subscription retry settings
• Add UI components for configuring retry settings in subscription forms
• Add tests for retry configuration functionality

Allows each subscription to have custom retry configuration including:

• Max fast retries (exponential backoff)
• Max slow retries (fixed interval)
• Fast retry delay (initial delay for exponential backoff)
• Max fast retry delay (cap for exponential backoff)
• Slow retry delay (fixed interval between slow retries)

closing, will re-do it later

Fixes #104

• Add OAuth2 Bearer token authentication with scopes and expiration
• Implement client certificate authentication with X.509 validation
• Add basic authentication support with credential validation
• Create modular authentication architecture with provider abstraction
• Add secure secret management with encryption at rest
• Implement database schema for authentication configuration
• Add frontend components for authentication provider configuration
• Create comprehensive ADR documentation for architectural decisions

Database changes:

• New authentication table with encrypted secrets storage
• Support for OAuth2, Certificate, and Basic auth configurations
• Proper indexing and constraints for security

Security features:

• AES-256-GCM encryption for sensitive data
• Secure key derivation with PBKDF2
• Certificate validation and parsing
• Token expiration and scope validation

Frontend enhancements:

• Authentication provider configuration UI
• OAuth2 scope and endpoint management
• Certificate upload and validation interface
• Integration with existing application management

Documentation:

• ADR 0001: Authentication architecture decisions
• ADR 0002: Secret management strategy
• ADR 0003: Authentication provider selection
• Comprehensive API documentation and examples

closing, will re-do it later

Fixes #95

Implement operational webhooks similar to Svix for monitoring webhook system health and status.

Features:

• Operational webhook endpoints management (CRUD operations)
• Event types for system events (endpoint.created, message.failed, etc.)
• HMAC-SHA256 signature verification for security
• Retry logic with exponential backoff (up to 5 attempts)
• Auto-disable endpoints after 10 consecutive failures
• Message delivery statistics tracking
• Background worker for webhook processing
• Rate limiting support per endpoint

Database changes:

• Add operational_endpoint table for webhook configurations
• Add operational_event and operational_event_type tables
• Add operational_attempt table for delivery tracking
• Add message_stats table for statistics
• Add triggers for automatic event generation

API endpoints:

• GET/POST /api/v1/operational_webhooks/ - List and create endpoints
• GET/PUT/DELETE /api/v1/operational_webhooks/{id} - Manage specific endpoint
• GET /api/v1/operational_webhooks/event_types - List available event types
• GET /api/v1/operational_webhooks/stats - Get delivery statistics

Security:

• IAM integration with proper authorization
• Unique secrets per endpoint for signature verification
• Custom headers support for additional security

This enables monitoring of webhook delivery health, automatic failure handling, and proactive issue detection in the webhook system.