Closes SRCH-741
Closes SRCH-716
This PR removes the GitHub installation code from the redirect flow to a
webhook-based appraoch. We expect that the GitHub server calls the
webhook when the installation is ready, and therefore shouldn't see the
errors explained in the issues above.
To handle the potential delay until the webhook is called and the
credential is set up, I added a scrappy info notice that the user should
refresh their page:
<img width="928" alt="Screenshot 2024-07-24 at 13 48 24"
src="https://github.com/user-attachments/assets/4d298f2a-d7b8-423b-9e2f-2ae53fbce1ac">
Below is what you see after you refreshed (or if the webhook was called
faster than the user being redirected back to the settings):
<img width="929" alt="Screenshot 2024-07-24 at 13 50 14"
src="https://github.com/user-attachments/assets/b6826158-8561-476d-b20e-e36f8cfb86fd">
I'm able to create PRs for sourcegraph-testing with an app that was
created this way.
<img width="1171" alt="Screenshot 2024-07-24 at 16 16 06"
src="https://github.com/user-attachments/assets/86e20acb-136f-4a46-a33b-bdfdd0d51d71">
I'm seeing an error when getting an access token with a personal github
app to run a batch change, but that will be handled with another PR.
<img width="1053" alt="Screenshot 2024-07-24 at 16 38 38"
src="https://github.com/user-attachments/assets/5655ba91-1ae4-453a-8d5c-1bcdbe34bc17">
## Test plan
Manual testing locally, and more testing to be done on S2 where we have
a more production like environment
## Changelog
- When installing a GitHub app for batch changes, the instance now waits
for a callback from GitHub to complete the installation to avoid issues
from eventual consistency.
---------
Co-authored-by: Peter Guy <peter.guy@sourcegraph.com>
Recently, this was refactored to also allow using the redispool.Store.
However, that makes it very implicit to know where something is being
written, so instead we pass down the pool instance at instantiation.
This also gives a slightly better overview of where redispool is
actually required.
Test plan: CI passes.
Closes SRCH-663
This is a follow-up to previous PRs, where we added database fields to
support the new github apps integration.
See initiative "Batch Changes using GitHub App auth" on linear.
## Test plan
- Manual testing
## Changelog
<!-- OPTIONAL; info at
https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c
-->
---------
Co-authored-by: Bolaji Olajide <25608335+BolajiOlajide@users.noreply.github.com>
Adds a new:
- gazelle generator
- rule + rule targets + catchall target
for generating go-mockgen mocks & testing for their being up-to-date.
Each go_mockgen macro invocation adds targets for generating mocks, copying to the source tree, as well as testing whether the current source tree mocks are up-to-date.
How to use this: `bazel run //dev:go_mockgen` for the catch-all, or `bazel run //some/target:generate_mocks` for an individual package, and `bazel test //some/target:generate_mocks_tests` to test for up-to-date-ness. There is no catch-all for testing
This currently uses a fork of go-mockgen, with an open PR for upstream here: https://github.com/derision-test/go-mockgen/pull/50.
Closes https://github.com/sourcegraph/sourcegraph/issues/60099
## Test plan
Extensive testing during development, including the following cases:
- Deleting a generated file and its entry in a go_library/go_test `srcs` attribute list and then re-running `sg bazel configure`
- Adding a non-existent output directory to mockgen.test.yaml and running the bash one-liner emitted to prepare the workspace for rerunning `sg bazel configure`
The existing config tests a lot of existing paths anyway (creating mocks for a 3rd party library's interface, entries for a given output file in >1 config file etc)
[Context](https://sourcegraph.slack.com/archives/C04UV9ZVBB2/p1696374182439959)
The customer reported an issue where a Sourcegraph instance configured with a GitHub app for Batch Changes couldn't sign commits on forked changesets even when the GitHub app was granted access to the forked repo.
This happens because while creating an authenticator used to create the signed commits, we always assume the repository to find the GitHub app installation for is the original repository where the Batch CHange was executed.
https://github.com/sourcegraph/sourcegraph/blob/main/internal/batches/sources/sources.go#L161
In this PR, I changed the approach and instead checked if the changeset is pushed to a fork, then figured out the namespace where the forked changeset is created and used that to get the GitHub app installation record.
## Test plan
* MAnual testing
- Add a GitHub app for BAtch Changes commit signing. Ensure you give it access to the forked repository of your choice.
- Add `batchChanges.enforceForks` to your site config, and create a batch change.
- The changeset should be verified and created in your repository fork once published.
* Updated unit tests
* fix: normalize github app base_url on read path
Previously, if github app baseURL did not contain a trailing slash
but the code host did, it would not match correctly. This code fixes
current and future problems by always trimming the / suffix.
* fix other unit test that I broke
* PR feedback
This moves a bunch of stuff out of enterprise. Notably, the final result
is `EnterpriseDB` no longer exists. This is one of the biggest sticking
points for moving other stuff out of the `enterprise` directory, so this
should help speed up future cleanups.
