| Age | Commit message (Collapse) | Author |
|---|
|
The Gitaly Training and resources playlist will house all of our Gitaly
videos. Replace the current bullet point with a link to the playlist.
|
|
|
|
* inlcude how to request gcp-host-profiles-sg group access
|
|
|
|
|
|
issue_templates: Make feature flag rollout a multi issue template
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6276
Merged-by: karthik nayak <knayak@gitlab.com>
Approved-by: Andras Horvath <ahorvath@gitlab.com>
Reviewed-by: Patrick Steinhardt <psteinhardt@gitlab.com>
Reviewed-by: Andras Horvath <ahorvath@gitlab.com>
Reviewed-by: karthik nayak <knayak@gitlab.com>
|
|
Rolling out feature flag is generally done over multiple issues. Most
often the work can be stretched for 3 releases:
1. Deploy code with feature flag <Release X>
2. Enable feature flag on staging <Release X>
3. Enable feature flag on production <Release X>
4. Default enable the feature flag <Release X+1>
5. Remove feature flag <Release X+2>
Currently we create a single issue from the `Feature Flag Roll Out`
template and use the same issue to track work over the releases. This is
problematic since:
1. Most of the time the issue is blocked waiting for a release to
happen.
2. Often we prematurely close the issue without removal of feature flag,
which means a lot of flags remain as is.
To solve both these problems, let's split the `Feature Flag Roll Out`
issue template into three:
1. `Feature Flag Roll Out`
2. `Feature Flag Default Enable`
3. `Feature Flag Removal`
with this, the first issue can be closed in <Release X> after creating
the required subsequent issues. This ensures we have discrete work which
can be tracked easily and also ensures that cleanup tasks are created in
our backlog making it easier to track/delete old flags.
|
|
|
|
Update Gitaly's Team Member Onboarding.md
See merge request https://gitlab.com/gitlab-org/gitaly/-/merge_requests/5995
Merged-by: karthik nayak <knayak@gitlab.com>
Approved-by: karthik nayak <knayak@gitlab.com>
Approved-by: Furhan Shabir <fshabir@gitlab.com>
Co-authored-by: Andras Horvath <ahorvath@gitlab.com>
|
|
|
|
|
|
The old Git version and feature flag cannot be removed in the same
release. Update the issue template to clarify this.
|
|
Add a new issue template for the Git version upgrade. This should help
us streamline our Git updates more.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
