Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

migrated from Cobra to Kong #616

Open
wants to merge 1 commit into
base: release-v0.17.3-lyft.1
Choose a base branch
from

Conversation

AndrewChubatiuk
Copy link

@AndrewChubatiuk AndrewChubatiuk commented Apr 26, 2023

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.

@AndrewChubatiuk AndrewChubatiuk force-pushed the cobra-to-kong-migration branch from 1150ebb to b3ff1c0 Compare April 26, 2023 08:50
@nishkrishnan
Copy link
Contributor

nishkrishnan commented May 4, 2023

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.

@AndrewChubatiuk
Copy link
Author

AndrewChubatiuk commented May 4, 2023

@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
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants