Tags: sourcegraph/sourcegraph
Tags
[Backport 5.4.5099] release: never use build number in image family (#… …63178) the executor image and docker mirror image should now follow the following naming convention: Image family: `sourcegraph-executors-[nightly|internal|'']-<MAJOR>-<MINOR>` Image name: `sourcegraph-executor-[nightly|internal|'']-<MAJOR>-<MINOR>-<BUILD_NUMBER>` example: Image family: `sourcegraph-executors-5-4` Image name: `sourcegraph-executor-5-4-277666` ## What happens during releases and _not_ releases? #### Nightly **`nightly` suffix** Image family: `sourcegraph-executors-nightly-<MAJOR>-<MINOR>` Image name: `sourcegraph-executor-nightly-<MAJOR>-<MINOR>-<BUILD_NUMBER>` #### Internal **`internal` suffix** Image family: `sourcegraph-executors-internal-<MAJOR>-<MINOR>` Image name: `sourcegraph-executor-internal-<MAJOR>-<MINOR>-<BUILD_NUMBER>` #### Public / Promote to public ** No suffix ** Image family: `sourcegraph-executors-<MAJOR>-<MINOR>` Image name: `sourcegraph-executor-<MAJOR>-<MINOR>-<BUILD_NUMBER>` > [!IMPORTANT] > Should we keep the imagine name stable at `sourcegraph-executor-<MAJOR>-<MINOR>-<BUILD_NUMBER>` > and only change the family name? > > **Why?** > > The Image family dictates the collection of images and that changes each major minor and or release phase so there is really no use in changing the image name too, except at a glance you can see from the name what image family it belongs to? ## Test plan ## Changelog <br> Backport 8bb0ab5 from #63157 Co-authored-by: William Bezuidenhout <william.bezuidenhout@sourcegraph.com>
Revert "security: Auto-update package lockfiles for Sourcegraph base … …images (#63067)" (#63102) This reverts commit 3fc155d. <!-- 💡 To write a useful PR description, make sure that your description covers: - WHAT this PR is changing: - How was it PREVIOUSLY. - How it will be from NOW on. - WHY this PR is needed. - CONTEXT, i.e. to which initiative, project or RFC it belongs. The structure of the description doesn't matter as much as covering these points, so use your best judgement based on your context. Learn how to write good pull request description: https://www.notion.so/sourcegraph/Write-a-good-pull-request-description-610a7fd3e613496eb76f450db5a49b6e?pvs=4 --> ## Test plan - CI <!-- All pull requests REQUIRE a test plan: https://docs-legacy.sourcegraph.com/dev/background-information/testing_principles --> ## Changelog <!-- 1. Ensure your pull request title is formatted as: $type($domain): $what 2. Add bullet list items for each additional detail you want to cover (see example below) 3. You can edit this after the pull request was merged, as long as release shipping it hasn't been promoted to the public. 4. For more information, please see this how-to https://www.notion.so/sourcegraph/Writing-a-changelog-entry-dd997f411d524caabf0d8d38a24a878c? Audience: TS/CSE > Customers > Teammates (in that order). Cheat sheet: $type = chore|fix|feat $domain: source|search|ci|release|plg|cody|local|... --> <!-- Example: Title: fix(search): parse quotes with the appropriate context Changelog section: ## Changelog - When a quote is used with regexp pattern type, then ... - Refactored underlying code. -->
feat(sg: add `list-build` subcommand to ci (#63071) * sg: add `list-build` subcommand to ci Add command to list builds in various states on a pipeline * bazel remove trailing '...' from commit printing
chore/msp-example: refactor to align with service structure best prac… …tices (#62954) In monorepo: ``` cmd/my-service/main.go -> cmd/my-service/service -> cmd/my-service/internal/... ``` Outside monorepo a similar unnested structure aligns with this as well: ``` cmd/my-service <- command service/... <- entrypoint internal/... <- internal implementation ``` ## Test plan Basic example builds and runs: `sg run msp-example`
PreviousNext