artin/sourcegraph
1
0
Fork 0
mirror of https://github.com/sourcegraph/sourcegraph.git synced 2026-02-06 19:51:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
98e0f75d1e
sourcegraph/cmd/executor
History
Noah S-C 98e0f75d1e
bazel: use transitions to apply cross-compile platform automatically to oci_image (#60569) 
Removes the need to pass `--config=docker-darwin` through the following mechanisms:

1. `--enable_platform_specific_config` to enable certain flags on macos only e.g. `--extra_toolchains @zig_sdk//toolchain:linux_amd64_gnu.2.34` and `--sandbox_add_mount_pair=/tmp` (see [.bazelrc change](https://github.com/sourcegraph/sourcegraph/pull/60569/files?file-filters%5B%5D=dotfile&show-viewed-files=true))
2. Apply a transition (using https://github.com/fmeum/with_cfg.bzl, please view [the following great video on it](https://www.youtube.com/watch?v=U5bdQRQY-io)) on `oci_image` targets when on the `@platforms//os:macos` platform to transition to the `@zig_sdk//platform:linux_amd64` platform. 
	- This will start at `oci_image` targets and propagate down to e.g. `go_{binary,library}` etc targets with the "transitioned" platform configuration, resulting in them being built with the transitioned-to platform
3. Remove `darwin_docker_e2e_go` config_setting and `darwin-docker` bool_flag.
	- These aren't necessary anymore, as the places where these were used were not in the transitive closure rooted at an `oci_image` target, meaning they wouldn't be transitioned.

To review, view [the following (filtered) files](https://github.com/sourcegraph/sourcegraph/pull/60569/files?file-filters%5B%5D=.bzl&file-filters%5B%5D=.sh&file-filters%5B%5D=.yaml&file-filters%5B%5D=No+extension&file-filters%5B%5D=dotfile&show-viewed-files=true)  along with [the root BUILD.bazel](https://github.com/sourcegraph/sourcegraph/pull/60569/files#diff-7fc57714ef13c3325ce2a1130202edced92fcccc0c6db34a72f7b57f60d552a3). All the other files are just changing the `load` statements from `@rules_oci` to `//dev:oci_defs.bzl`

## Test plan

CI, checked image locally and `sg test bazel-backend-integration` & `sg test bazel-e2e`
2024-02-20 13:57:56 +00:00
..
docker-mirror executors: fix path to aws_regions.json in ami.push targets (#60612) 2024-02-19 15:42:58 +00:00
internal bazel: native go-mockgen in Bazel (#60386) 2024-02-16 13:26:48 +00:00
kubernetes Move executor-kubernetes out of enterprise (#56449) 2023-09-08 16:24:05 +02:00
vm-image executors: fix path to aws_regions.json in ami.push targets (#60612) 2024-02-19 15:42:58 +00:00
_binary.push.sh ci: avoid dropping ALL executors binary if BUILDKITE_TAG is empty (#59439) 2024-01-09 19:08:49 +01:00
BUILD.bazel bazel: use transitions to apply cross-compile platform automatically to oci_image (#60569) 2024-02-20 13:57:56 +00:00
ci-should-rebuild.sh ci: fix incorrect usage of target determinator (#59171) 2023-12-21 15:50:29 +00:00
image_test.yaml Move executor to cmd/executor (#55700) 2023-08-10 02:06:12 +02:00
main.go Docs: update links to point to new site (#60381) 2024-02-13 00:23:47 +00:00
README.md Port executors building/pushing scripts to use Bazel (#58892) 2023-12-20 18:33:49 +00:00

README.md

Executor

The executor service polls the public frontend API for work to perform. The executor will pull a job from a particular queue (configured via the envvar EXECUTOR_QUEUE_NAME), then performs the job by running a sequence of docker and src-cli commands. This service is horizontally scalable.

Since executors and Sourcegraph are separate deployments, our agreement is to support 1 minor version divergence for now. See this example for more details:

Sourcegraph version Executor version Ok
3.43.0 3.43.* ✅
3.43.3 3.43.* ✅
3.43.0 3.44.* ✅
3.43.0 3.42.* ✅
3.43.0 3.41.* 🚫
3.43.0 3.45.* 🚫

See the executor queue for a complete list of queues.

Building and releasing

Building and releasing is handled automatically by the CI pipeline.

Binary

The executor binary is simply built with bazel build //cmd/executor:executor.

For publishing it, see bazel run //cmd/executor:binary.push:

  • In every scenario, the binary will be uploaded to gcs://sourcegraph-artifacts/executors/$GIT_COMMIT/.
  • If the current branch is main when this target is run, it will also be copied over to gcs://sourcegraph-artifacts/executors/latest.
  • If the env var EXECUTOR_IS_TAGGED_RELEASE is set to true, it will also be copied over to gcs://sourcegraph-artifacts/executors/$BUILDKITE_TAG.

VM image

The VM Image is built with packer, but it also uses an OCI image as a base for Firecracker, //docker-images/executor-vm:image_tarball which it depends on. That OCI image is a legacy image, see docker-images/executor-vm/README.md.

Because we're producing an AMI for both AWS and GCP, there are two steps involved:

  • bazel run //cmd/executor/vm-image:ami.build creates the AMI and names it according to the CI runtype.
  • bazel run //cmd/executor/vm-image:ami.push takes the AMIs from above and publish them (adjust perms, naming).

While gcloud is provided by Bazel, AWS cli is expected to be available on the host running Bazel.

Building AMIs on GCP is rather quick, but it's notoriously slow on AWS (about 20m) so we use target-determinator to detect when to rebuild the image. See ci-should-rebuild.sh, which is used by the pipeline generator to skip building it if we detect that nothing changed since the parent commit.

Docker Mirror

As with the VM image, we're producing an AMI for both AWS and GCP, there are two steps involved:

  • bazel run //cmd/executor/docker-mirror:ami.build creates the AMI and names it according to the CI runtype.
  • bazel run //cmd/executor/docker-mirror:ami.push takes the AMIs from above and publish them (adjust perms, naming).

While gcloud is provided by Bazel, AWS cli is expected to be available on the host running Bazel.