Add interoperability smoke tests for Mastodon

[sij411]

Summary

Implements the Phase 1 (Mastodon) interoperability smoke test suite described
in #481.

What this adds

CI workflow (.github/workflows/smoke-mastodon.yml)

A GitHub Actions workflow that spins up a full Mastodon stack (web, sidekiq,
PostgreSQL, Redis) alongside a Fedify test harness via Docker Compose, then
runs E2E federation scenarios.

When it runs:

• On push to main, next, and *.*-maintenance branches
• On workflow_dispatch (manual trigger for testing specific branches)

It does not run on PRs, as the issue notes these tests are too
long-running and resource-intensive for every PR.

Fedify test harness (test/smoke/harness/)

A minimal Fedify application that runs inside the Docker network. It
exposes:

• Standard federation endpoints (actor, inbox, outbox, followers)
• Backdoor test-control APIs (/_test/reset, /_test/inbox,
  /_test/follow, /_test/unfollow, /_test/create-note,
  /_test/health)

Orchestrator (test/smoke/orchestrator.ts)

A Deno script that drives 6 E2E scenarios through both the Mastodon API
and harness backdoor endpoints:

• Mastodon → Fedify (Follow)
• Fedify → Mastodon (Follow)
• Fedify → Mastodon (Create Note)
• Mastodon → Fedify (Reply)
• Mastodon → Fedify (Unfollow)
• Fedify → Mastodon (Unfollow)

Each follow scenario includes precondition checks (ensureNotFollowing /
assertNotFollowing) that verify the relationship starts clean before
exercising the follow path.

Directory structure

test/smoke/
  orchestrator.ts              # shared test driver
  harness/                     # shared Fedify test harness
    main.ts
    federation.ts
    backdoor.ts
    store.ts
    deno.json
  mastodon/                    # Mastodon-specific
    docker-compose.yml
    mastodon.env
    provision.sh
    disable_force_ssl.rb

Mastodon-specific files live in test/smoke/mastodon/ so that future
server targets (e.g., Misskey for Phase 1, Akkoma for Phase 2) can be
added as sibling directories sharing the same harness and orchestrator
infrastructure.

Acceptance criteria (from the issue)

• CI workflow created
• Minimal Fedify test harness app built within the repo
• E2E tests (Follow, Create(Note), reply) pass against Mastodon
• Workflow runs on pushes to main, next, *.*-maintenance, and
  on workflow_dispatch

Test plan

• All 6 scenarios pass locally via act
• CI workflow smoke-mastodon passes on push to main

Related to #481

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request establishes a robust suite of interoperability smoke tests for the Fedify project, specifically targeting integration with Mastodon. By setting up a dedicated CI workflow, a specialized Fedify test harness, and an orchestrator for end-to-end scenarios, the changes ensure that Fedify's federation capabilities are validated against a widely used ActivityPub platform. This significantly enhances confidence in Fedify's ability to communicate effectively within the fediverse.

Highlights

• New CI Workflow for Mastodon Interoperability: A new GitHub Actions workflow (.github/workflows/smoke-mastodon.yml) has been introduced to run end-to-end federation scenarios against a full Mastodon stack. This workflow is configured to run on pushes to main, next, and *.*-maintenance branches, as well as via manual workflow_dispatch, but not on pull requests due to resource intensity.
• Fedify Test Harness Implementation: A minimal Fedify application (test/smoke/harness/) has been created to act as a test participant within the Docker network. This harness exposes standard federation endpoints and specialized backdoor test-control APIs for resetting state, inspecting the inbox, and initiating activities like follows, unfollows, and note creation.
• E2E Orchestrator for Federation Scenarios: A Deno script (test/smoke/orchestrator.ts) has been added to orchestrate and drive six key end-to-end federation scenarios between the Fedify harness and Mastodon. These scenarios cover various interactions including following, unfollowing, and creating notes, with bidirectional testing (Mastodon to Fedify and Fedify to Mastodon).
• Modular Test Directory Structure: The new test infrastructure is organized under test/smoke/, with Mastodon-specific configurations placed in test/smoke/mastodon/. This design allows for easy expansion to include other ActivityPub server targets (e.g., Misskey, Akkoma) in the future by adding sibling directories that share the common harness and orchestrator.

Changelog

• .gitignore
  • Added new entries to ignore test-specific environment files and logs.
• deno.json
  • Updated the imports configuration to include the new Fedify test harness directory.
• test/smoke/harness/backdoor.ts
  • Added a new module providing test-control API endpoints for the Fedify harness, enabling actions like state reset, inbox inspection, and programmatic activity sending.
• test/smoke/harness/deno.json
  • Added an empty Deno configuration file for the harness.
• test/smoke/harness/federation.ts
  • Added the core Fedify federation setup for the test harness, including actor dispatchers, key pair dispatchers, and inbox listeners for various ActivityPub activities.
• test/smoke/harness/main.ts
  • Added the main entry point for the Fedify harness server, handling both federation routes and backdoor test-control APIs.
• test/smoke/harness/store.ts
  • Added a simple in-memory store to track received activities within the Fedify harness for testing purposes.
• test/smoke/mastodon/disable_force_ssl.rb
  • Added a Ruby script to disable force_ssl in Mastodon's Rails application, allowing HTTP communication for smoke tests.
• test/smoke/mastodon/docker-compose.yml
  • Added a Docker Compose configuration to spin up a complete Mastodon stack (web, sidekiq, PostgreSQL, Redis) alongside the Fedify test harness within a shared network.
• test/smoke/mastodon/mastodon.env
  • Added environment variables for configuring the Mastodon instance specifically for smoke testing, including database, Redis, and network settings.
• test/smoke/mastodon/provision.sh
  • Added a shell script to provision the Mastodon instance for testing, including creating a test user, generating an API token, pre-registering the Fedify remote account, and establishing initial follow relationships.
• test/smoke/orchestrator.ts
  • Added the Deno script responsible for orchestrating the end-to-end federation scenarios, interacting with both Mastodon's API and the Fedify harness's backdoor endpoints.

Ignored Files

• Ignored by pattern: .github/workflows/** (1)
  • .github/workflows/smoke-mastodon.yml

Activity

• All six defined end-to-end scenarios have been verified to pass locally using act.
• The CI workflow smoke-mastodon is expected to pass on pushes to main once merged, confirming successful integration.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces an extensive and well-designed interoperability smoke test suite for Mastodon. The use of Docker Compose to spin up the full stack is robust, and the workarounds for testing federation over HTTP are clever. The test harness and orchestrator are well-structured. I've identified a couple of opportunities to reduce code duplication in the new test files, which will improve their long-term maintainability. Overall, this is a great addition for ensuring Fedify's compatibility with Mastodon.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Adds a Mastodon-focused interoperability smoke test suite to validate Fedify’s federation behavior end-to-end in CI, aligning with the Phase 1 plan in issue #481.

Changes:

• Introduces a GitHub Actions workflow that boots a Mastodon stack + Fedify harness via Docker Compose and runs Deno-driven E2E scenarios.
• Adds a minimal Fedify “harness” app with federation endpoints and backdoor test-control APIs.
• Adds Mastodon provisioning scripts/config to create a test user, seed remote account data, and generate an API token for orchestrated scenarios.

Reviewed changes

Copilot reviewed 12 out of 14 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
.github/workflows/smoke-mastodon.yml	CI workflow to generate Mastodon secrets, start stack, provision, run orchestrator, and collect logs.
test/smoke/orchestrator.ts	Deno E2E driver for follow/create/reply/unfollow scenarios between Mastodon and the harness.
test/smoke/harness/main.ts	HTTP server wiring: routes /_test/* to backdoor and everything else to federation fetch handler.
test/smoke/harness/federation.ts	Minimal Fedify federation setup (actor + inbox listeners) for the harness.
test/smoke/harness/backdoor.ts	Backdoor endpoints to reset state and initiate follow/unfollow/create-note actions.
test/smoke/harness/store.ts	In-memory inbox activity store used by backdoor endpoints.
test/smoke/harness/deno.json	Harness workspace config placeholder.
test/smoke/mastodon/docker-compose.yml	Defines Mastodon (web/sidekiq) + db/redis + fedify-harness services on a shared network.
test/smoke/mastodon/mastodon.env	Baseline Mastodon env config used by Compose (with secrets appended in CI).
test/smoke/mastodon/provision.sh	Provisions Mastodon user/token and pre-registers the harness account/key and initial follow relationship.
test/smoke/mastodon/disable_force_ssl.rb	Disables Rails force_ssl to allow HTTP in production-mode Mastodon container.
deno.json	Adds test/smoke/harness to the Deno workspace members.
.gitignore	Ignores generated smoke-test artifacts (e.g., .env.test, logs).

[Copilot]

Pull request overview

Copilot reviewed 12 out of 14 changed files in this pull request and generated 1 comment.

[sij411]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces an extensive interoperability smoke test suite for Mastodon, which is a great addition for ensuring Fedify's compatibility. The setup using Docker Compose, a test harness, and an orchestrator is well-thought-out. My review focuses on ensuring the new test infrastructure is correct and maintainable. I've found one critical issue regarding an invalid Docker image version that would prevent the tests from running, and a medium-severity suggestion to improve code clarity in the test harness.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 14 changed files in this pull request and generated 3 comments.