| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
In order to standardize the creation of flaky test issues, a new issue
template has been added. This template ensures that the appropriate
labels are applied automatically and tracks whether the flaky test has
been quarantined.
|
|
Onboarding Issue Template: Add PTO Calendar Integration
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/5244
Merged-by: John Cai <jcai@gitlab.com>
Approved-by: Andras Horvath <ahorvath@gitlab.com>
|
|
Add a bullet for new employees to integrate their PTO-Roots with the
shared Gitaly Team Calendar.
|
|
Some of the issue temlates are using outdated labels. This change
updates the templates with correct default labels.
|
|
|
|
|
|
Every feature flag rollout should be done gradually. Enforce this
through the feature flag issue template.
|
|
Add a line item in the onboarding document to get maintainer access to
the Gitaly retrospective repository.
|
|
|
|
New Gitaly team members need access to both Zendesk and gitaly ruby gem.
This change adds these requests to the onboarding issue template.
|
|
The `#g_create_gitaly` Slack channel has been renamed to `#g_gitaly`.
This change updates the feature flag and onboarding issue templates
accordingly.
|
|
Specify who needs to give approval on Merge Requests.
|
|
The default MR template creates unnecessary work since we already take
pains to write a coherent and detailed commit message. Once the MR
template supports automatic importing of commit messages, we can add a
default template once again.
|
|
Added information and references to the Gitaly onboarding issue.
|
|
|
|
|
|
|
|
Add onboarding issue template for Gitaly team.
See merge request gitlab-org/gitaly!4701
|
|
|
|
|
|
|
|
|
|
|
|
Issue: https://gitlab.com/gitlab-org/gitaly/-/issues/4335
|
|
ZenDesk tickets are the primary source of truth for the Support team,
and will have the most detail on the problem and troubleshooting steps
taken so far.
Let's add an explicit field for the ticket in the support request
template.
|
|
|
|
|
|
|
|
Create support request issue template
See merge request gitlab-org/gitaly!3836
|
|
|
|
|
|
Restructure feature flag rollout steps to clearly show the different
phases from staging to production to default-enabled releases to removal
of the feature flag.
|
|
Gitaly's feature flags are much more limited compared to the feature
flags by Rails given that we do not support feature gates. As such, we
cannot ever use beta groups for a feature flag rollout.
Remove the section.
|
|
Add a `/title` command instead of documenting that the title should be
set.
|
|
|
|
|
|
Adjusts security merge request template to use the new changelog
workflow.
Related to gitlab-com/gl-infra/delivery#1767
|
|
This adds a configuration file for generating changelogs using the
GitLab API (done using Release Tools), as well as change Danger to
remind developers of these upcoming changes (similar to what we're doing
in gitlab-org/gitlab).
Omnibus, Pages and Helm are already using this new approach. Our current
plan is to also roll this out to remaining projects (GitLab Rails and
Gitaly) per May 22nd.
See https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/1564 for
more information.
|
|
After a couple of releases with enabled reads distribution
feature we are removing a feature flag completely.
The special test-cases deleted as now the feature is a default
and there is no way to change it.
The change also fixes some comments around reads distribution.
Closes: https://gitlab.com/gitlab-org/gitaly/-/issues/3383
|
|
|
|
It wasn't clear from the existing checklist item added in
2d9d7f9c9 (Add roll out issue template, 2019-06-11) what the removal
steps are, and what "remove feature flag" meant.
Split this up into steps where we discuss the removal from the
codebase, and what changelog entries we expect there, and then discuss
how to remove the feature via chatops.
|
|
I screwed this up in [1] and [2] and as a result the feature didn't
get enabled 100% on January 14th like I thought, but on January 27th
when the changes [3][4] to remove the feature flag itself went
live ([4] being the relevant change).
1. https://gitlab.com/gitlab-org/gitaly/-/issues/3412#note_485304117
2. https://gitlab.com/gitlab-org/gitaly/-/issues/3413#note_485303898
3. https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3035
4. https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3033
|
|
We don't need to do manual network configuration after
441ac39f2 (Demo: configuration of direct connection to
Postgres, 2020-12-30) is merged. We also don't need to
manually enable the feature flag as it is enabled by default
by 80b10d907 (Feature flag gitaly_distributed_reads enabled
by default, 2020-12-24).
|
|
|
|
Remove the "Ensure that the documentation has been updated" item. Yes,
docs are good, but this is not actionable. What docs are you going to
update between testing on staging and giving an ETA for production
rollout?
This was just copy/pasted from 2d9d7f9c9 (Add roll out issue template,
2019-06-11), presumably it meant some SRE rollout docs or something
they use. For gitaly the rollout is much simpler, and nobody's
updating any docs at this point in the process.
|
|
I added this because of a question @pks-t had in
https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2995#note_484390302
It's easy to miss that we auto-add the featureflag::disabled flag
initially, let's cover that and provide handy links to the tracker to
see the status of each label.
|
|
Add more steps reflecting what we need to do after we have the feature
at 100%. Includes a paraphrased version of what I noted in my
a96949aef (Enable feature flag go_user_delete_{branch,tag} by default,
2021-01-12) as part of
https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2994
|
|
Variable replication factor's demo script contains some incorrect
configuration lines. This commit corrects the situation.
|
