Move to zitadel/zitadel

[eliobischof]

The login should be moved to zitadel/zitadel so we can align the release cycles and released versions.

• Code is moved to zitadel/zitadel/login subfolder
• Pipelines are moved to zitadel/zitadel/.github
• A zitadel release pushes a version-tagged docker image for the login
• Move issues to zitadel/zitadel and label them
• Document how to fork the login
• Document how to pull changes from zitadel/zitadel/login to existing forks
• Typescript client builds from local protos
• Console imports local typescript client
• Archive zitadel/typescript

[eliobischof]

@peintnermax @livio-a @adlerhurst does this issue need more clarification?
Is the estimation of 4 ok?

[Fuchsoria]

How will it work with selfhosted v2 login? Will it be included in main zitadel docker image or will be just there in monorepo?

[eliobischof]

How will it work with selfhosted v2 login? Will it be included in main zitadel docker image or will be just there in monorepo?

The current proposal is to actually keep the changes to this repo as minimal as possible and only add capabilities, not remove any. The login should still have its own docker image, but with a version tag added that is aligned with the zitadel core version tag. We think this helps reducing mental overhead and the operational risk of incompatible deployments.

If you like to learn more about the technical details, please read this draft PR's description and tell us what you think. The many code additions are not so interesting, yet, I guess, it's mainly just the synced code from the zitadel/typescript repo and first attempts of dockerizing the pipelines.

Inputs are highly appreciated 🙏

[StanSocialCloud]

How would this affect the license of zitadel/typescript?
We are not making any changes so far, but this seems more like a client library that could be customized to meet specific needs and integrations with Zitadel, much like how the grpc/sdk libraries were left with an open lisence

[thethomaswagner]

This must remain as its own repository to avoid licensing issues. That would basically cripple adoption of your cloud backend when AGPL becomes part of the code distributed (node or frontend). AGPL is too vague.

[eliobischof]

We add an exception to the AGPL license, as we do already for the proto directory