Follow-up to https://github.com/sourcegraph/devx-support/issues/1130
Moving the doc links to a comment is merely a few lines of GitHub
Script, so it's worth doing it for better merge commit messages.
## Test plan
This PR itself was the test, as you can see below the comments that
resulted from this new GH workflow. Btw, the second one is the one
you'll see in the code here. I went for a oneliner to avoid cluttering
the UI.
closes CLO-527
[context](https://sourcegraph.slack.com/archives/CHXHX7XAS/p1721835847010889)
cloud uses a lot of the GraphQL API to pre-configure instances on
customer behave, and it's very sensitive to breaking changes to the
schema upstream.
currently, we have a [cronjob github
actions](https://github.com/sourcegraph/controller/actions/workflows/srcgql-compat.yaml)
that periodically check the schema compatibility every day.
such approach works but we're always playing catch up and will have to
result in extra work on the product team to re-work the PR. it is much
better to catch this in CI time within the monorepo.
This PR added a new github actions to the monorepo that will run on any
`*.graphql` changes. Then it will remotely trigger the cronjob github
action in sourcegraph/controller to run and poll the result. See test
plan for demo.
## FAQ
### Why not run the test in buildkite or directly in this repo using
github actions?
- sourcegraph/controller is a huge repo forhistorical reason (> 2G) and
cloning it is very expensive
- the repo contains sensitive information, and we don't want to make it
possible to expose it accidentally.
### How does authentication work?
We use a [GitHub
App](https://github.com/organizations/sourcegraph/settings/apps/cloud-srcgql-compat-test-invoker)
with extremely limited permissions. It only permits the workflow to
trigger/read the workflow without any access to the source code itself.
Also, GitHub App installation access token has a life span of 1h, much
better than PAT.
## Test plan
it triggered the job and it worked:
good: https://github.com/sourcegraph/sourcegraph/pull/64094
bad: https://github.com/sourcegraph/sourcegraph/pull/64095
We have nice release names in https://github.com/sourcegraph/sg/releases, but it's not actually programmatically available - this causes a discrepancy between the `sg` version one might pull, and the version of `sg` that is known in-code, and means that we can't do something like #62134.
This change adds a `ReleaseName` variable to be stamped at build/release time, and updates a few references to `BuildCommit` where I think it might be more prudent to report `ReleaseName` instead, and also fixes some yellow squiggles in my IDE on files I visited (sorry) and some noisy `-v` output (sorry again)
## Test plan
```
$ go build -ldflags "-s -w -X main.BuildCommit=$(git rev-list -1 HEAD .) -X main.ReleaseName=hello-world" -o ./sg ./dev/sg
$ ./sg version
hello-world
$ ./sg -v version
Version: hello-world
Build commit: b23db0be5e
```
* ci: init trigger to pipeline on release
* ci: add release number as env var
* ci: testing action now that the env var is in place
* ci: more testing
* ci: add name
* ci: tested!
* ci(AMIs): pin GHA trigger BK
* ci: add workflow_dispatch
* ci: change branch to main
Lets get rid of PG_UTILS_PATH! :allthethings: 🎉
## Test plan
CI and a _lot_ of `nix build .#pg-utils && ldd ./result/bin/pg_dump`
also tested e2e with the following diff: 61e0eb0d55
Cody no longer needs it and it is obsolete now!
Since App added a non-insignificant amount of new concepts and alternative code paths, I decided to take some time and remove it from out codebase.
This PR removes ~21k lines of code. If we ever want parts of single binary (app), the redis kv alternatives, or the release pipeline for a native mac app back, we can look back at this PR and revert parts of it, but maintaining 21k lines of code and many code paths for which I had to delete a surprisingly small amount of tests justifies this move for me very well.
Technically, to some extent SG App and Cody App both still existed in the codebase, but we don't distribute either of them anymore, so IMO we shouldn't keep this weight in our code.
So.. here we go.
This should not affect any of the existing deployments, we only remove functionality that was special-cased for app.
