t.index["note"],name: "tmp_idx_on_promoted_notes",where: "(((noteable_type)::text = 'Issue'::text) AND (system IS TRUE) AND (note ~~ 'promoted to epic%'::text))"
GitLab's GraphQL API uses [Relay-style cursor pagination](https://www.apollographql.com/docs/react/data/pagination/#cursor-based)
for connection types. This means a "cursor" is used to keep track of where in the data
set the next items should be fetched from.
Every connection type (for example, `DesignConnection` and `DiscussionConnection`) has a field `pageInfo` that contains an information required for pagination:
```javascript
pageInfo{
endCursor
hasNextPage
hasPreviousPage
startCursor
}
```
Here:
-`startCursor` and `endCursor` display the cursor of the first and last items
respectively.
-`hasPreviousPage` and `hasNextPage` allow us to check if there are more pages
available before or after the current page.
When we fetch data with a connection type, we can pass cursor as `after` or `before`
parameter, indicating a starting or ending point of our pagination. They should be
followed with `first` or `last` parameter respectively to indicate _how many_ items
we want to fetch after or before a given endpoint.
For example, here we're fetching 10 designs after a cursor:
`QueryRecorder#occurrences_by_line_method` returns a sorted array based on `data`, sorted by `count`.
This will log calls to QueryRecorder into the `test.log`. For example:
1. You can output the call backtrace for the specific `QueryRecorder` instance you want
by using `ActiveRecord::QueryRecorder.new(query_recorder_debug: true)`. The output
will be in `test.log`
```plaintext
QueryRecorder SQL: SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 AND ("issues"."state" IN ('opened')) AND "issues"."confidential" = $2
1. Using the environment variable `QUERY_RECORDER_DEBUG`, the call backtrace will be output for all tests.
To enable this, run the specs with the `QUERY_RECORDER_DEBUG` environment variable set. For example:
This will log calls to QueryRecorder into the `test.log` file. For example:
```plaintext
QueryRecorder SQL: SELECT COUNT(*) FROM "issues" WHERE "issues"."deleted_at" IS NULL AND "issues"."project_id" = $1 AND ("issues"."state" IN ('opened')) AND "issues"."confidential" = $2
@@ -64,13 +64,13 @@ source projects, GitLab grants access to **Gold** features for all GitLab.com
#### Self-managed
A self-managed subscription uses a hybrid model. You pay for a subscription according to the maximum number of users enabled during the subscription period. At the end of the subscription period, the maximum number of simultaneous users in the self-managed installation is checked. If the number of users is higher than your subscription, you are billed for the extra users. The maximum number of simultaneous users is also used to calculate the cost of subscription renewal.
A self-managed subscription uses a hybrid model. You pay for a subscription according to the maximum number of users enabled during the subscription period. For instances that aren't air-gapped or on a closed network, the maximum number of simultaneous users in the self-managed installation is checked each quarter, using [Seat Link](#seat-link).
Every occupied seat, whether by person, job, or bot is counted in the subscription, with the following exceptions:
- Blocked users who are blocked prior to the renewal of a subscription won't be counted as active users for the renewal subscription. They may count as active users in the subscription period in which they were originally added.
- Members with Guest permissions on an Ultimate subscription.
-Special internal GitLab accounts: `Ghost User` and `Support Bot`.
-GitLab-created service accounts: `Ghost User` and `Support Bot`.
NOTE: **Note:**
If you have LDAP integration enabled, anyone in the configured domain can sign up for a GitLab account. This can result in an unexpected bill at time of renewal. Consider [disabling new signups](../user/admin_area/settings/sign_up_restrictions.md) and managing new users manually instead.
...
...
@@ -237,6 +237,65 @@ The following will be emailed to you:
- A payment receipt. You can also access this information in the Customers Portal under **Payment History**.
- A new license. [Upload this license](../user/admin_area/license.md#uploading-your-license) to your instance to use it.
### Seat Link
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208832) in [GitLab Starter](https://about.gitlab.com/pricing) 12.9.
Seat Link allows us to provide our self-managed customers with prorated charges for user growth throughout the year using a quarterly reconciliation process.
Seat Link sends to GitLab daily a count of all users in connected self-managed instances. That information is used to automate prorated reconciliations. The data is sent securely through an encrypted HTTPS connection.
Seat Link is mandatory because we need the user count data to enable prorated billing. Seat Link provides **only** the following information to GitLab:
For air-gapped or closed network customers, the existing [true-up model](#users-over-license) will be used. Prorated charges are not possible without user count data.
### Renew or change a GitLab.com subscription
To renew for more users than are currently active in your GitLab.com system, contact our sales team via `renewals@gitlab.com` for assistance as this can't be done in the Customers Portal.
@@ -35,24 +35,21 @@ export REGION=us-central1 # the GCP region where the GKE cluster is provisioned.
## Configure RBAC permissions
- For a non-GitLab managed cluster(s), ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group.
Manually grant GitLab's service account the ability to manage resources in the
`database.crossplane.io` API group. The Aggregated ClusterRole allows us to do that.
NOTE: **Note:**
For a non-GitLab managed cluster, ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group.
1. Save the following YAML as `crossplane-database-role.yaml`:
- For GitLab-managed clusters, RBAC is configured automatically.
```shell
cat> crossplane-database-role.yaml <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
- For non-GitLab managed clusters, ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group:
1. Save the following YAML as `crossplane-database-role.yaml`:
The example above will create an `a11y` job in your CI/CD pipeline and will run
Pa11y against the webpage you defined in `a11y_urls` to build a report.
creates an `a11y` job in your CI/CD pipeline, runs
Pa11y against the webpages defined in `a11y_urls`, and builds an HTML report for each.
NOTE: **Note:**
Only one URL may be currently passed into `a11y_urls`.
The report for each URL is saved as an artifact that can be [viewed directly in your browser](../../../ci/pipelines/job_artifacts.md#browsing-artifacts).
A single `accessibility.json` artifact is created and saved along with the individual HTML reports.
It includes report data for all URLs scanned.
The full HTML Pa11y report will be saved as an artifact that can be [viewed directly in your browser](../../../ci/pipelines/job_artifacts.md#browsing-artifacts).
NOTE: **Note:**
For GitLab versions earlier than 12.9, you can use `include:remote` and use a
link to the [current template in `master`](https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml)
NOTE: **Note:**
The job definition provided by the template does not support Kubernetes yet.
let!(:note4){notes.create!(commit_id: commit.id,noteable_type: 'Commit',project_id: project.id,author_id: author.id,note: 'note for an email@somesite.com and some other random @ ref')}
# this should have pointed to an innexisted commit record in a commits table
# but because commit is not an AR we'll just make it so that it does not have mentions
let!(:note5){notes.create!(commit_id: 'abc',noteable_type: 'Commit',project_id: project.id,author_id: author.id,note: 'note for an email@somesite.com and some other random @ ref')}
let!(:resource1){notes.create!(commit_id: commit.id,noteable_type: 'Commit',project_id: project.id,author_id: user.id,note: 'note1 for @root to check')}
let!(:resource2){notes.create!(commit_id: commit.id,noteable_type: 'Commit',project_id: project.id,author_id: user.id,note: 'note1 for @root to check')}
let!(:resource3){notes.create!(commit_id: commit.id,noteable_type: 'Commit',project_id: project.id,author_id: user.id,note: 'note1 for @root to check',system: true)}
# this note is already migrated, as it has a record in the commit_user_mentions table
let!(:resource4){notes.create!(note: 'note3 for @root to check',commit_id: commit.id,noteable_type: 'Commit')}
let!(:resource1){notes.create!(commit_id: commit.id,noteable_type: 'Commit',project_id: project.id,author_id: user.id,note: 'note1 for @root to check')}
let!(:resource2){notes.create!(commit_id: commit.id,noteable_type: 'Commit',project_id: project.id,author_id: user.id,note: 'note1 for @root to check')}
let!(:resource3){notes.create!(commit_id: commit.id,noteable_type: 'Commit',project_id: project.id,author_id: user.id,note: 'note1 for @root to check',system: true)}
# non-migrateable resources
# this note is already migrated, as it has a record in the commit_user_mentions table
let!(:resource4){notes.create!(note: 'note3 for @root to check',commit_id: commit.id,noteable_type: 'Commit')}
