grafana · pstibrany · Aug 30, 2021 · Aug 24, 2021 · Aug 24, 2021 · Aug 25, 2021
@@ -1,30 +1,33 @@
 ---
 name: Bug report
 about: Create a report to help us improve
-title: ''
-labels: ''
-assignees: ''
-
+title: ""
+labels: ""
+assignees: ""
 ---
 
 **Describe the bug**
 A clear and concise description of what the bug is.
 
 **To Reproduce**
 Steps to reproduce the behavior:
+
 1. Start Mimir (SHA or version)
 2. Perform Operations(Read/Write/Others)
 
 **Expected behavior**
 A clear and concise description of what you expected to happen.
 
 **Environment:**
- - Infrastructure: [e.g., Kubernetes, bare-metal, laptop]
- - Deployment tool: [e.g., helm, jsonnet]
+
+- Infrastructure: [e.g., Kubernetes, bare-metal, laptop]
+- Deployment tool: [e.g., helm, jsonnet]
 
 **Storage Engine**
+
 - [ ] Blocks
 - [ ] Chunks
 
 **Additional Context**
+
 <!--  Additional relevant info which can help us debug this issue easily like Logs, Configuration etc. -->
@@ -1,10 +1,9 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-title: ''
-labels: ''
-assignees: ''
-
+title: ""
+labels: ""
+assignees: ""
 ---
 
 **Is your feature request related to a problem? Please describe.**

@@ -9,9 +9,11 @@
 **Which issue(s) this PR fixes**:
 
 <!-- Please make sure you don't reference cortex issues here, as the references can be publicly seen under certain conditions -->
+
 Fixes #<issue number>
 
 **Checklist**
+
 - [ ] Tests updated
 - [ ] Documentation added
 - [ ] `CHANGELOG.md` updated - the order of entries should be `[CHANGE]`, `[FEATURE]`, `[ENHANCEMENT]`, `[BUGFIX]`
@@ -10,14 +10,13 @@ If you wish to add a new CI or CD job, add it to the existing current test-build
 
 test-build-deploy.yml specifies a workflow that runs all Mimir continuous integration and continuous deployment jobs. The workflow is triggered on every pull request and commit to main, however the CD jobs only run when changes are merged onto main. The workflow combines both CI and CD jobs, because the CD jobs are dependent on artifacts produced the CI jobs.
 
-
 ## Specific Jobs
 
-| Job                    | Description                                                                                                                   | Type |
-|------------------------|-------------------------------------------------------------------------------------------------------------------------------|------|
-| lint                   | Runs linting and ensures vendor directory, protos and generated documentation are consistent.                                 | CI   |
-| test                   | Runs units tests on Cassandra testing framework.                                                                              | CI   |
-| integration            | Runs integration tests after upgrading golang, pulling necessary docker images and downloading necessary module dependencies. | CI   |
-| build                  | Builds and saves an up-to-date Mimir image and website.                                                                       | CI   |
-| deploy_website         | Deploys the latest version of Mimir website to gh-pages branch. Triggered within workflow.                                    | CD   |
-| deploy                 | Deploys the latest Mimir image.                                                                                               | CD   |
+| Job            | Description                                                                                                                   | Type |
+| -------------- | ----------------------------------------------------------------------------------------------------------------------------- | ---- |
+| lint           | Runs linting and ensures vendor directory, protos and generated documentation are consistent.                                 | CI   |
+| test           | Runs units tests on Cassandra testing framework.                                                                              | CI   |
+| integration    | Runs integration tests after upgrading golang, pulling necessary docker images and downloading necessary module dependencies. | CI   |
+| build          | Builds and saves an up-to-date Mimir image and website.                                                                       | CI   |
+| deploy_website | Deploys the latest version of Mimir website to gh-pages branch. Triggered within workflow.                                    | CD   |
+| deploy         | Deploys the latest Mimir image.                                                                                               | CD   |
@@ -10,7 +10,7 @@ jobs:
   lint:
     runs-on: ubuntu-20.04
     container:
-      image: us.gcr.io/kubernetes-dev/mimir-build-image:goimports-00767679e
+      image: us.gcr.io/kubernetes-dev/mimir-build-image:add-prettier-08d2e2a61
       credentials:
         username: _json_key
         password: ${{ secrets.gcr_json_key }}
@@ -44,7 +44,7 @@ jobs:
   test:
     runs-on: ubuntu-20.04
     container:
-      image: us.gcr.io/kubernetes-dev/mimir-build-image:goimports-00767679e
+      image: us.gcr.io/kubernetes-dev/mimir-build-image:add-prettier-08d2e2a61
       credentials:
         username: _json_key
         password: ${{ secrets.gcr_json_key }}
@@ -68,7 +68,7 @@ jobs:
   build:
     runs-on: ubuntu-20.04
     container:
-      image: us.gcr.io/kubernetes-dev/mimir-build-image:goimports-00767679e
+      image: us.gcr.io/kubernetes-dev/mimir-build-image:add-prettier-08d2e2a61
       credentials:
         username: _json_key
         password: ${{ secrets.gcr_json_key }}

@@ -0,0 +1,2 @@
+CHANGELOG.md
+vendor
@@ -2,18 +2,18 @@
 
 This is the list of organisations that are using Cortex in **production environments** to power their metrics and monitoring systems. Please send PRs to add or remove organisations.
 
-* [Amazon Web Services (AWS)](https://aws.amazon.com/prometheus)
-* [Aspen Mesh](https://aspenmesh.io/)
-* [Buoyant](https://buoyant.io/)
-* [DigitalOcean](https://www.digitalocean.com/)
-* [Electronic Arts](https://www.ea.com/)
-* [Etsy](https://www.etsy.com/)
-* [EverQuote](https://everquote.com/)
-* [GoJek](https://www.gojek.io/)
-* [GrafanaLabs](https://grafana.com/)
-* [MayaData](https://mayadata.io/)
-* [Opstrace](https://opstrace.com/)
-* [Platform9](https://platform9.com/)
-* [REWE Digital](https://rewe-digital.com/)
-* [SysEleven](https://www.syseleven.de/)
-* [Weaveworks](https://www.weave.works/)
+- [Amazon Web Services (AWS)](https://aws.amazon.com/prometheus)
+- [Aspen Mesh](https://aspenmesh.io/)
+- [Buoyant](https://buoyant.io/)
+- [DigitalOcean](https://www.digitalocean.com/)
+- [Electronic Arts](https://www.ea.com/)
+- [Etsy](https://www.etsy.com/)
+- [EverQuote](https://everquote.com/)
+- [GoJek](https://www.gojek.io/)
+- [GrafanaLabs](https://grafana.com/)
+- [MayaData](https://mayadata.io/)
+- [Opstrace](https://opstrace.com/)
+- [Platform9](https://platform9.com/)
+- [REWE Digital](https://rewe-digital.com/)
+- [SysEleven](https://www.syseleven.de/)
+- [Weaveworks](https://www.weave.works/)
@@ -1,6 +1,7 @@
 ---
 title: Governance
 ---
+
 # Governance
 
 This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Mimir community. Common terminology used in this governance document are listed below:
@@ -10,6 +11,7 @@ This document describes the rules and governance of the project. It is meant to
 - **Maintainers**: Maintainers lead an individual project or parts thereof ([`MAINTAINERS.md`][maintainers]).
 
 - **Projects**: A single repository in the Grafana GitHub organization and listed below is referred to as a project:
+
   - Mimir
 
 - **The Mimir project**: The sum of all activities performed under this governance, concerning one or more repositories or the community.
@@ -46,12 +48,12 @@ In case a member leaves, the [offboarding](#offboarding) procedure is applied.
 
 The current team members are:
 
-* Bryan Boreham - [bboreham](https://github.com/bboreham) ([Grafana Labs](https://grafana.com/))
-* Goutham Veeramachaneni - [gouthamve](https://github.com/gouthamve) ([Grafana Labs](https://grafana.com/))
-* Jacob Lisi - [jtlisi](https://github.com/jtlisi) ([Grafana Labs](https://grafana.com/))
-* Marco Pracucci - [pracucci](https://github.com/pracucci) ([Grafana Labs](https://grafana.com/))
-* Peter Štibraný - [pstibrany](https://github.com/pstibrany) ([Grafana Labs](https://grafana.com/))
-* Tom Wilkie - [tomwilkie](https://github.com/tomwilkie) ([Grafana Labs](https://grafana.com/))
+- Bryan Boreham - [bboreham](https://github.com/bboreham) ([Grafana Labs](https://grafana.com/))
+- Goutham Veeramachaneni - [gouthamve](https://github.com/gouthamve) ([Grafana Labs](https://grafana.com/))
+- Jacob Lisi - [jtlisi](https://github.com/jtlisi) ([Grafana Labs](https://grafana.com/))
+- Marco Pracucci - [pracucci](https://github.com/pracucci) ([Grafana Labs](https://grafana.com/))
+- Peter Štibraný - [pstibrany](https://github.com/pstibrany) ([Grafana Labs](https://grafana.com/))
+- Tom Wilkie - [tomwilkie](https://github.com/tomwilkie) ([Grafana Labs](https://grafana.com/))
 
 ### Maintainers
 
@@ -136,7 +138,6 @@ The new member is
 - added to the projects with commit rights.
 - added to the [team mailing list][team].
 
-
 ### Offboarding
 
 The ex-member is

@@ -50,6 +50,8 @@ fetch-build-image:
 	docker tag $(BUILD_IMAGE):$(LATEST_BUILD_IMAGE_TAG) $(BUILD_IMAGE):latest
 	touch mimir-build-image/.uptodate
 
+# push-multiarch-build-image requires the ability to build images for multiple platforms:
+# https://docs.docker.com/buildx/working-with-buildx/#build-multi-platform-images
 push-multiarch-build-image:
 	@echo
 	# Build image for each platform separately... it tends to generate fewer errors.
@@ -118,7 +120,7 @@ mimir-build-image/$(UPTODATE): mimir-build-image/*
 # All the boiler plate for building golang follows:
 SUDO := $(shell docker info >/dev/null 2>&1 || echo "sudo -E")
 BUILD_IN_CONTAINER := true
-LATEST_BUILD_IMAGE_TAG ?= goimports-00767679e
+LATEST_BUILD_IMAGE_TAG ?= add-prettier-08d2e2a61
 
 # TTY is parameterized to allow Google Cloud Builder to run builds,
 # as it currently disallows TTY devices. This value needs to be overridden
@@ -161,6 +163,7 @@ lint-packaging-scripts: packaging/deb/control/postinst packaging/deb/control/pre
 
 lint: lint-packaging-scripts
 	misspell -error docs
+	prettier --check "**/*.md"
 
 	# Configured via .golangci.yml.
 	golangci-lint run

@@ -13,7 +13,7 @@ Cortex provides horizontally scalable, highly available, multi-tenant, long term
 - **Horizontally scalable:** Cortex can run across multiple machines in a cluster, exceeding the throughput and storage of a single machine. This enables you to send the metrics from multiple Prometheus servers to a single Cortex cluster and run "globally aggregated" queries across all data in a single place.
 - **Highly available:** When run in a cluster, Cortex can replicate data between machines. This allows you to survive machine failure without gaps in your graphs.
 - **Multi-tenant:** Cortex can isolate data and queries from multiple different independent
-Prometheus sources in a single cluster, allowing untrusted parties to share the same cluster.
+  Prometheus sources in a single cluster, allowing untrusted parties to share the same cluster.
 - **Long term storage:** Cortex supports S3, GCS, Swift and Microsoft Azure for long term storage of metric data. This allows you to durably store data for longer than the lifetime of any single machine, and use this data for long term capacity planning.
 
 Cortex is a [CNCF](https://cncf.io) incubation project used in several production systems including [Weave Cloud](https://cloud.weave.works) and [Grafana Cloud](https://grafana.com/cloud).
@@ -24,6 +24,7 @@ Cortex is primarily used as a [remote write](https://prometheus.io/docs/operatin
 Read the [getting started guide](https://cortexmetrics.io/docs/getting-started) if you're new to the
 project. Before deploying Cortex with a permanent storage backend you
 should read:
+
 1. [An overview of Cortex's architecture](https://cortexmetrics.io/docs/architecture/)
 1. [Getting started with Cortex](https://cortexmetrics.io/docs/getting-started/)
 1. [Information regarding configuring Cortex](https://cortexmetrics.io/docs/configuration/)
@@ -52,8 +53,7 @@ To learn more about Cortex, consult the following talks and articles.
 
 ### Previous talks and articles
 
-- Nov 2019 KubeCon talks "[Cortex 101: Horizontally Scalable Long Term Storage for Prometheus][kubecon-cortex-101]" ([video][kubecon-cortex-101-video], [slides][kubecon-cortex-101-slides]), "[Configuring Cortex for Max
-Performance][kubecon-cortex-201]" ([video][kubecon-cortex-201-video], [slides][kubecon-cortex-201-slides], [write up][kubecon-cortex-201-writeup]) and "[Blazin’ Fast PromQL][kubecon-blazin]" ([slides][kubecon-blazin-slides], [video][kubecon-blazin-video], [write up][kubecon-blazin-writeup])
+- Nov 2019 KubeCon talks "[Cortex 101: Horizontally Scalable Long Term Storage for Prometheus][kubecon-cortex-101]" ([video][kubecon-cortex-101-video], [slides][kubecon-cortex-101-slides]), "[Configuring Cortex for Max Performance][kubecon-cortex-201]" ([video][kubecon-cortex-201-video], [slides][kubecon-cortex-201-slides], [write up][kubecon-cortex-201-writeup]) and "[Blazin’ Fast PromQL][kubecon-blazin]" ([slides][kubecon-blazin-slides], [video][kubecon-blazin-video], [write up][kubecon-blazin-writeup])
 - Nov 2019 PromCon talk "[Two Households, Both Alike in Dignity: Cortex and Thanos][promcon-two-households]" ([video][promcon-two-households-video], [slides][promcon-two-households-slides], [write up][promcon-two-households-writeup])
 - May 2019 KubeCon talks; "[Cortex: Intro][kubecon-cortex-intro]" ([video][kubecon-cortex-intro-video], [slides][kubecon-cortex-intro-slides], [blog post][kubecon-cortex-intro-blog]) and "[Cortex: Deep Dive][kubecon-cortex-deepdive]" ([video][kubecon-cortex-deepdive-video], [slides][kubecon-cortex-deepdive-slides])
 - Feb 2019 blog post & podcast; "[Prometheus Scalability with Bryan Boreham][prometheus-scalability]" ([podcast][prometheus-scalability-podcast])

@@ -7,7 +7,7 @@ This page describes the release process and the currently planned schedule for u
 Our goal is to provide a new minor release every 6 weeks. This is a new process and everything in this document is subject to change.
 
 | release series | date of first pre-release (year-month-day) | release shepherd                            |
-|----------------|--------------------------------------------|---------------------------------------------|
+| -------------- | ------------------------------------------ | ------------------------------------------- |
 | v0.1.0         | 2019-07-31                                 | Chris Marchbanks (GitHub: @csmarchbanks)    |
 | v0.2.0         | 2019-08-28                                 | Goutham Veeramachaneni (Github: @gouthamve) |
 | v0.3.0         | 2019-10-09                                 | Bryan Boreham (@bboreham)                   |
@@ -33,10 +33,10 @@ Our goal is to provide a new minor release every 6 weeks. This is a new process
 
 The release shepherd is responsible for the entire release series of a minor release, meaning all pre- and patch releases of a minor release. The process formally starts with the initial pre-release, but some preparations should be done a few days in advance.
 
-* We aim to keep the master branch in a working state at all times. In principle, it should be possible to cut a release from master at any time. In practice, things might not work out as nicely. A few days before the pre-release is scheduled, the shepherd should check the state of master. Following their best judgement, the shepherd should try to expedite bug fixes that are still in progress but should make it into the release. On the other hand, the shepherd may hold back merging last-minute invasive and risky changes that are better suited for the next minor release.
-* On the date listed in the table above, the release shepherd cuts the first pre-release (using the suffix `-rc.0`) and creates a new branch called  `release-<major>.<minor>` starting at the commit tagged for the pre-release. In general, a pre-release is considered a release candidate (that's what `rc` stands for) and should therefore not contain any known bugs that are planned to be fixed in the final release.
-* With the pre-release, the release shepherd is responsible for coordinating or running the release candidate in any [end user](https://github.com/cortexproject/cortex/blob/master/ADOPTERS.md) production environment  for 3 days. This is typically done in Grafana Labs or Weaveworks but we are looking for more volunteers!
-* If regressions or critical bugs are detected, they need to get fixed before cutting a new pre-release (called `-rc.1`, `-rc.2`, etc.).
+- We aim to keep the master branch in a working state at all times. In principle, it should be possible to cut a release from master at any time. In practice, things might not work out as nicely. A few days before the pre-release is scheduled, the shepherd should check the state of master. Following their best judgement, the shepherd should try to expedite bug fixes that are still in progress but should make it into the release. On the other hand, the shepherd may hold back merging last-minute invasive and risky changes that are better suited for the next minor release.
+- On the date listed in the table above, the release shepherd cuts the first pre-release (using the suffix `-rc.0`) and creates a new branch called `release-<major>.<minor>` starting at the commit tagged for the pre-release. In general, a pre-release is considered a release candidate (that's what `rc` stands for) and should therefore not contain any known bugs that are planned to be fixed in the final release.
+- With the pre-release, the release shepherd is responsible for coordinating or running the release candidate in any [end user](https://github.com/cortexproject/cortex/blob/master/ADOPTERS.md) production environment for 3 days. This is typically done in Grafana Labs or Weaveworks but we are looking for more volunteers!
+- If regressions or critical bugs are detected, they need to get fixed before cutting a new pre-release (called `-rc.1`, `-rc.2`, etc.).
 
 See the next section for details on cutting an individual release.
 
@@ -75,10 +75,10 @@ To prepare release branch, first create new release branch (release-X.Y) in Cort
 1. Update the version number in the `VERSION` file to say "X.Y-rc.0"
 2. Update `CHANGELOG.md`
    - Ensure changelog entries for the new release are in this order:
-     * `[CHANGE]`
-     * `[FEATURE]`
-     * `[ENHANCEMENT]`
-     * `[BUGFIX]`
+     - `[CHANGE]`
+     - `[FEATURE]`
+     - `[ENHANCEMENT]`
+     - `[BUGFIX]`
    - Run `./tools/release/check-changelog.sh LAST-RELEASE-TAG...master` and add any missing PR which includes user-facing changes
 
 Once your PR with release prepartion is approved, merge it to "release-X.Y" branch, and continue with publishing.