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.
