Deployment for discord-bot

[tolik518]

Description

After #252 (#254) is resolved we would need a new deployment pipeline.

Currently we always create a git tag based on the factorion-reddit-bot version in the Cargo.toml.
With factorion-discord-bot we can't deploy the same way, because the tag is only valid for reddit.

[tolik518]

Some proposals how to solve that:

1. Create a combined tag: ${reddit-version}-${discord-version} e.x: 4.0.7-1.0.0
2. Specific tags like reddit-${reddit-version} and discord-${discord-version} e.x: reddit-4.0.7 and discord-1.0.0
3. Move discord-bot to its own repo
4. ???

The first two solutions would destroy the continuation of the current tags

[tolik518]

Currently the deployment-workflow is not very refined and I deploy over the github actions by selecting the tag that I want to deploy:

[Aras14HD]

I am most in favor with solution 2, as it seems the most understandable (1 seems very abstract). And on library changes, we would just have two tags for the same commit, that seems ok.

For 3, that means it's not a monorepo, which means we would not check against it automatically. Instead, it would be downstream, likely lag behind a bit (might be something we're ok with) and have a lower priority when programming the library. If we want to have them at similar priority, I think breaking with the current tags is ok.

So do we want to treat the discord bot like the reddit bot, or just have it as a secondary one? (Personally I am on the fence, currently I see the discord bot as less important, however that might change once I see it used)

[tolik518]

@Aras14HD Thank you for the input, I'm also pretty torn rn.

Solution 1 wouldn't scale at all with further additions.

Solution 2 would add new tags with every monorepo additions and the first introduction would be a breaking change.

Solution 3 is my favorite right now. While the split repos might not get their update right away and would need one more PR - I feel like this is not a huge detour.

I think the discord bot might get more priority as discord bots are usually pretty big and there are still a lot of features that could be implemented (like support for native / commands comes to my mind).

Also somewhat related:
I would prefer that the whole project would live, some day, in its own factorion org.
There is a huge disadvantage to a factorion org - the pipelines for orgs are not free iirc. So I would either have to pay up, or host my own runners. Either way something I would rather dodge for now.

[Aras14HD]

Another point for 3: In a Monorepo, when introducing a breaking change in the library, one would have to fix every bot in one pull, slightly increasing maintenance burden.

Also, the downside of some platforms lagging behind is not actually that large. Most changes do not break bots (the comment abstraction), just need a change of some version numbers, or are very minor like adding one Const field (from env).

[Aras14HD]

Somewhat related: To run our own discord bot, after 100 servers, we need to get it verified. So we should make a Team for it and before the time comes (when/if we reach 75 servers) write a Privacy Policy and Terms of Service.

[tolik518]

I've added you to a team I've created and added you as an admin.

Another point for 3: In a Monorepo, when introducing a breaking change in the library, one would have to fix every bot in one pull, slightly increasing maintenance burden.

Also good point and I'm currently leaning for the third solution.
The deployment has not the highest priority for me, so we don't have to solve the issue as fast as possible - as I can just deploy by hand for the starters.

[tolik518]

Maybe we don't need a separate repo for the discord bot, but just for the Dockerfiles/Deployment. That way we could have a Dockerfile that just pulls the released version of factorion from crates.io and we won't have to get it from github. I'm not sure yet if this makes sence, but that way the deployment will wont be coupled with the tag of the repo, but rather with the version of the crate/application