lyft
migrated from Cobra to Kong
Hey guys!
Thank you for your Atlantis fork!
Unfortunately repo has no issues and also I cannot contact you in Linkedin to talk about the contribution before submitting PRs.
I'm from Motional, we're using Atlantis as well and would like to switch to your fork, but we're using Gitlab, which you've removed from worker, gateway and temporalworker modes.
In this MR introducing migration to Kong from Viper + Cobra to simplify configuration management and decrease amount of dependencies. Also it'll simplify moving VCS management to plugins, so we'll be able to develop Gitlab plugin and maintain it separately.
Hey @AndrewChubatiuk , we really appreciate the contribution here! We are in the process of fully deprecating the legacy worker code in this fork and therefore doing a ton of refactoring. One of the goals is to make it easier to initialize the various services in code, allowing custom interceptors and plugins to just be passed in. I'd like to opt for this route versus introducing plugins as part of the cli execution path.
Imagine something like
server := atlantis.NewServer().WithPlugin1(...).WithCustomLogger(...).WithServices(...)
server.Run()
An additional point I want to make is that, we don't really know yet what the goal of this fork is. We're going through some reorganization and reprioritization internally and its not clear whether we're going to be able to support this as a full out OSS project at this point. Until we have a bit more clarity here, I'm hesitant to support additional featuresets. Supporting a new VCS provider in this case, requires a pretty sizeable change atm since the github code is tightly coupled with all our new code. I think we'd want to avoid this for now until we simplify the code a lot more as mentioned above and we have a more concrete direction with this project.
@nishkrishnan thank you for clarification. wanted to ask if can i help you somehow to move faster toward old code deprecation? also what about migrating cli management to kong? it’ll also help to reduce that amount of structures that are used just to pass and validate cli args and config data to atlantis
@nishkrishnan thank you for clarification. wanted to ask if can i help you somehow to move faster toward old code deprecation? also what about migrating cli management to kong? it’ll also help to reduce that amount of structures that are used just to pass and validate cli args and config data to atlantis
Appreciate the offer, but we're making good progress and have a plan to hopefully have the legacy worker be unused in the next few weeks. In terms of cli management, I don't really want us to be doing much there tbh, I want all the config to just be a yaml file on the server side and I think we'll be pretty close to that once we remove all the old code. We can evaluate once the repo is cleaned up.