chore: merge chatmail/filtermail into chatmail/relay to have a monorepo

[missytake]

This is a proposal to merge chatmail/filtermail and chatmail/relay into one monorepo, so we can change filtermail with only one PR in the future.

The paths in the filtermail commits have been rewritten so that they were always in the filtermail/ subdirectory, so the commit history of each file is preserved. What I did to merge the repositories, in case it needs to be repeated slightly differently:

cd $USER/code/relay/..
git clone https://github.com/chatmail/filtermail
cd filtermail
git filter-repo --to-subdirectory filtermail --tag-rename v:filtermail-
cd ../relay
git checkout main
git pull --rebase
git checkout -b merge-filtermail
git remote add filtermail-merge ../filtermail
git fetch filtermail-merge
git merge --allow-unrelated-histories filtermail-merge/main

Then I did 3cf3937 on top of it to integrate filtermail's .github/ and .gitignore into chatmail/relay.

open questions:

• how should we distinguish tags? does filtermail still need its own software versions? Other projects import filtermail, afaik. I renamed the filtermail tags from v1.2.3 to filtermail-1.2.3 for now, but didn't push them so far.
• should we rename the relay tags as well, from 1.2.3 to relay-1.2.3?

[j-g00da]

does filtermail still need its own software versions?

In theory it does not, but then we probably want to tag relay more often, as it won't be possible to deploy relay from main if filtermail changed without compiling it locally.

[j4n]

Thanks for tackling this, two non-inline comments:

• ci.yaml still polls the old filtermail release, adapt that to the build pattern from filtermail-ci.yaml.
• Changelog: There are now two and two cliff.toml; needs some --include-path work so this won't clobber.

Re versioning: prefixed filtermail-X.Y.Z tags, with relay staying unprefixed, seems the conventional shape; I would not retroactively rename relay's tags to relay-X.Y.Z as it breaks existing release-download URLs.

[missytake]

CI requires chatmail/cmlxc#31 I think - edit: apparently not, it's green :)

[j4n]

Changes looks good. Some more comments inline.

One thing for a followup-PR: RELEASE.md is currently relay-only and should have a filtermail section, something like:

# Releasing chatmail relay
...

# Releasing filtermail

filtermail is versioned independently and released from the same repo,
using `filtermail-` prefixed tags. To release filtermail 0.7.5:

1. Update the changelog:
   `git cliff --config filtermail/cliff.toml -u -t filtermail-0.7.5 -p filtermail/CHANGELOG.md`
2. Bump `version` in `filtermail/Cargo.toml` and commit `filtermail/Cargo.lock`.
3. Commit with the message `feat(release): prepare filtermail for 0.7.5`;  or chore() if it should be excluded from relay changelog.
4. Open a PR with the new commit, merge it to main after review.
5. In the web interface, create a GitHub release, tell it to create a new tag `filtermail-0.7.5`. Do not push the tag by hand: the release must exist before the upload job runs.
6. Bump the pinned version and sha256sums in`cmdeploy/src/cmdeploy/filtermail/deployer.py`.

[j4n]

Suggested change

	cmlxc -v deploy-cmdeploy --source ./repo cm0
	cmlxc -v deploy-cmdeploy --source ./repo --filtermail repo/filtermail/target/x86_64-unknown-linux-musl/release/filtermail cm0

if we do build filtermail at all times, we should probably also use it in the test, otherwise we dont need to build it; though we will have a path clash here that will need fixing in cmlxc.

[j4n]

Suggested change

	cmlxc -v deploy-cmdeploy --source ./repo --ipv4-only --filtermail repo/filtermail/target/x86_64-unknown-linux-musl/release/filtermail cm1

same as above

[j4n]

Suggested change

export CARGO_TARGET_X86_64_UNKNOWN_LINUX_MUSL_LINKER=musl-gcc

Looking at the job log, does not reach the next step as each line runs in its own environment and thus is a noop.

[j4n]

Suggested change

	exclude_paths = ["filtermail/"]
	exclude_paths = ["filtermail/"]
	tag_pattern = '^[0-9]+\.[0-9]+\.[0-9]+$'

Exclude filtermail tags and match only relay tags.

[j4n]

Suggested change

	recurse_submodules = false
	recurse_submodules = false
	include_paths = ["filtermail/"]
	tag_pattern = "^filtermail-"

match only filtermail

[j4n]

Suggested change

	run: curl -L https://github.com/chatmail/filtermail/releases/download/v0.7.4/filtermail-x86_64 -o /usr/local/bin/filtermail && chmod +x /usr/local/bin/filtermail
	run: curl -f -L https://github.com/chatmail/filtermail/releases/download/v0.7.4/filtermail-x86_64 -o /usr/local/bin/filtermail && chmod +x /usr/local/bin/filtermail

-f means failing on 404 instead of downloading the error page to filtermail binary location. Maybe we should consider always building and using https://github.com/Swatinem/rust-cache as in filtermail-ci.yaml.

[j4n]

Suggested change

	pull_request:
	branches:
	- main
	paths:
	- "filtermail/**"
	paths:
	- "filtermail/**"
	- ".github/workflows/filtermail-ci.yml"
	pull_request:
	branches:
	- main
	paths:
	- "filtermail/**"
	- ".github/workflows/filtermail-ci.yml"

push otherwise runs the full rust matrix for nothing on pushes to main; and add the workflow file.

[j4n]

This needs to be updated.

[j4n]

Suggested change

	name: Build binaries.
	name: Build binaries.
	if: startsWith(github.event.release.tag_name, 'filtermail-')

Guard here..

[j4n]

Suggested change

	push:
	tags:
	- 'filtermail-*'
	release:
	types: [published]

see filter on line 10