-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Support Gerrit #195
Comments
@lkysow thanks for opening this ticker for gerrit support. Can you share more details on high level changes (and files that needs to be updated) required to to support gerrit. I will see if I can help contribute towards the support. I am relatively new to go language but hoping it's not going to be a big change? Gerrit support will be a huge value add at least for our team at work. I couldn't quite see what all changes you made that are specific to bitbucket support in the latest release here: https://github.com/runatlantis/atlantis/releases/tag/v0.4.3 Thanks |
First of all Atlantis needs webhooks to tell it about new pull requests and comments. It needs to know about:
Then it needs to make these additional calls:
Before starting on implementation, I would look and see if Gerrit can provide this and what the exact calls are. |
@lkysow : Here are some more details that you might be interested unless you already are aware of Gerrit's workflow. If I understand pull requests correctly, Gerrit follows a different model. Users don't create a new branch when using Gerrit, rather work on the master branch. I mean for large changes it's recommended to use branches which I don't deny, just that Gerrit does not require working from new branches. We just push to Gerrit. Gerrit also serves as a git repo on top of providing review support. Though technically for each commit Gerrit create a new branch on it's copy of the repo. Once the pushed changes on the repo held by Gerrit are reviewed and approved (verified with +1 from CI (Jenkins in our case), and +2 from reviewers), those changes are pushed to gerrit as well as replicated to primary git server. One typically use the Gerrit UI to submit the changes post review loop. Replication is enabled from gerrit to the git server and based on replication interval, the pushed changes are available on the primary git repo. We always pull and push changes to to/from Gerrit and not git server. Here is a good walk through of review life cycle with Gerrit Gerrit has good API support both for authentication as as well with all CRUD operations. For instance here is the api to list modified files https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#all-files Few more relevant API's: Some other useful links |
There are no plans to implement this unfortunately. We already support 3 of the most popular version control providers and each provider adds a lot of additional complexity and causes additional work to implement each new feature. As such, I don't think this will be implemented. |
For an all on premise installation, just wondering if the "Gerrit Integration" can be achieved by using a mix of 'Gerrit event triggers' (picked up by a Jenkins job) and then calling the Atlantis server using something like the Jenkins' webhook trigger plugin or Asking here, in case any Jenkins expert stumbles upon this question. Also, please ignore if my question is incorrect and makes no sense! 😇 |
Test modules filtering bug that was fixed in runatlantis#193
If you'd like Gerrit support please "react" with a 👍 so I can track interest
The text was updated successfully, but these errors were encountered: