Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
a009356633
commit
8936551eb6
|
|
@ -86,7 +86,6 @@ export default {
|
|||
:discussions-by-diff-order="true"
|
||||
:line="line"
|
||||
:help-page-path="helpPagePath"
|
||||
:should-scroll-to-note="false"
|
||||
>
|
||||
<template v-if="renderAvatarBadge" #avatar-badge>
|
||||
<design-note-pin
|
||||
|
|
|
|||
|
|
@ -1,8 +1,6 @@
|
|||
import ScrollParent from 'scrollparent';
|
||||
import { contentTop } from './common_utils';
|
||||
|
||||
const interactionEvents = ['mousedown', 'touchstart', 'keydown', 'wheel'];
|
||||
|
||||
export function createResizeObserver() {
|
||||
return new ResizeObserver((entries) => {
|
||||
entries.forEach((entry) => {
|
||||
|
|
@ -14,15 +12,13 @@ export function createResizeObserver() {
|
|||
/**
|
||||
* Watches for change in size of a container element (e.g. for lazy-loaded images)
|
||||
* and scrolls the target note to the top of the content area.
|
||||
* Stops watching after any user input. So if user opens sidebar or manually
|
||||
* scrolls the page we don't hijack their scroll position
|
||||
*
|
||||
* @param {Object} options
|
||||
* @param {string} options.targetId - id of element to scroll to
|
||||
* @param {string} options.container - Selector of element containing target
|
||||
* @param {Element} options.component - Element containing target
|
||||
*
|
||||
* @return {ResizeObserver|null} - ResizeObserver instance if target looks like a note DOM ID
|
||||
* @return {Function} - Cleanup function to stop watching
|
||||
*/
|
||||
export function scrollToTargetOnResize({
|
||||
targetId = window.location.hash.slice(1),
|
||||
|
|
@ -30,47 +26,87 @@ export function scrollToTargetOnResize({
|
|||
} = {}) {
|
||||
if (!targetId) return null;
|
||||
|
||||
const scrollContainer =
|
||||
ScrollParent(document.getElementById(targetId)) || document.documentElement;
|
||||
const scrollContainerIsDocument = scrollContainer === document.documentElement;
|
||||
let scrollContainer;
|
||||
let scrollContainerIsDocument;
|
||||
|
||||
let targetTop = 0;
|
||||
let currentScrollPosition = 0;
|
||||
let userScrollOffset = 0;
|
||||
|
||||
// start listening to scroll after the first keepTargetAtTop call
|
||||
let scrollListenerEnabled = false;
|
||||
// can't tell difference between user and el.scrollTo, so use a flag
|
||||
let skipProgrammaticScrollEvent = false;
|
||||
|
||||
const containerEl = document.querySelector(container);
|
||||
const ro = createResizeObserver();
|
||||
// if we are scrolling document, add the resizeobserver to container el instead - we don't
|
||||
// want to observe the whole document
|
||||
const containerEl = scrollContainerIsDocument
|
||||
? document.querySelector(container)
|
||||
: scrollContainer;
|
||||
let interactionListenersAdded = false;
|
||||
|
||||
function keepTargetAtTop() {
|
||||
const anchorEl = document.getElementById(targetId);
|
||||
function handleScroll() {
|
||||
if (skipProgrammaticScrollEvent) {
|
||||
skipProgrammaticScrollEvent = false;
|
||||
return;
|
||||
}
|
||||
currentScrollPosition = scrollContainerIsDocument ? window.scrollY : scrollContainer.scrollTop;
|
||||
userScrollOffset = currentScrollPosition - targetTop;
|
||||
}
|
||||
|
||||
if (!anchorEl) return;
|
||||
|
||||
const anchorTop = anchorEl.getBoundingClientRect().top + window.scrollY;
|
||||
const top = anchorTop - contentTop();
|
||||
scrollContainer.scrollTo({
|
||||
top,
|
||||
});
|
||||
|
||||
if (!interactionListenersAdded) {
|
||||
interactionEvents.forEach((event) =>
|
||||
// eslint-disable-next-line no-use-before-define
|
||||
document.addEventListener(event, removeListeners),
|
||||
);
|
||||
interactionListenersAdded = true;
|
||||
function addScrollListener() {
|
||||
if (scrollContainerIsDocument) {
|
||||
// For document scrolling, we need to listen to window
|
||||
window.addEventListener('scroll', handleScroll, { passive: true });
|
||||
} else {
|
||||
scrollContainer.addEventListener('scroll', handleScroll, { passive: true });
|
||||
}
|
||||
}
|
||||
|
||||
function removeListeners() {
|
||||
interactionEvents.forEach((event) => document.removeEventListener(event, removeListeners));
|
||||
function removeScrollListener() {
|
||||
if (scrollContainerIsDocument) {
|
||||
window.removeEventListener('scroll', handleScroll);
|
||||
} else {
|
||||
scrollContainer?.removeEventListener('scroll', handleScroll);
|
||||
}
|
||||
}
|
||||
|
||||
ro.unobserve(containerEl);
|
||||
containerEl.removeEventListener('ResizeUpdate', keepTargetAtTop);
|
||||
function keepTargetAtTop() {
|
||||
const anchorEl = document.getElementById(targetId);
|
||||
if (!anchorEl) return;
|
||||
|
||||
scrollContainer = ScrollParent(document.getElementById(targetId)) || document.documentElement;
|
||||
scrollContainerIsDocument = scrollContainer === document.documentElement;
|
||||
|
||||
if (!scrollContainer) return;
|
||||
|
||||
skipProgrammaticScrollEvent = true;
|
||||
|
||||
const anchorTop = anchorEl.getBoundingClientRect().top;
|
||||
currentScrollPosition = scrollContainerIsDocument ? window.scrollY : scrollContainer.scrollTop;
|
||||
|
||||
// Add scrollPosition as getBoundingClientRect is relative to viewport
|
||||
// Add the accumulated scroll offset to maintain relative position
|
||||
// subtract contentTop so it goes below sticky headers, rather than top of viewport
|
||||
targetTop = anchorTop - contentTop() + currentScrollPosition + userScrollOffset;
|
||||
|
||||
scrollContainer.scrollTo({
|
||||
top: targetTop,
|
||||
behavior: 'instant',
|
||||
});
|
||||
|
||||
if (!scrollListenerEnabled) {
|
||||
addScrollListener();
|
||||
scrollListenerEnabled = true;
|
||||
}
|
||||
}
|
||||
|
||||
containerEl.addEventListener('ResizeUpdate', keepTargetAtTop);
|
||||
|
||||
ro.observe(containerEl);
|
||||
return ro;
|
||||
|
||||
return function cleanup() {
|
||||
// add a slight delay to this to allow for a final scroll to the
|
||||
// element once notes have finished
|
||||
setTimeout(() => {
|
||||
ro.unobserve(containerEl);
|
||||
containerEl.removeEventListener('ResizeUpdate', keepTargetAtTop);
|
||||
removeScrollListener();
|
||||
}, 100);
|
||||
};
|
||||
}
|
||||
|
|
|
|||
|
|
@ -54,11 +54,6 @@ export default {
|
|||
required: false,
|
||||
default: false,
|
||||
},
|
||||
shouldScrollToNote: {
|
||||
type: Boolean,
|
||||
required: false,
|
||||
default: true,
|
||||
},
|
||||
},
|
||||
computed: {
|
||||
...mapGetters(['userCanReply']),
|
||||
|
|
@ -146,7 +141,6 @@ export default {
|
|||
:discussion-root="true"
|
||||
:discussion-resolve-path="discussion.resolve_path"
|
||||
:is-overview-tab="isOverviewTab"
|
||||
:should-scroll-to-note="shouldScrollToNote"
|
||||
:internal-note="isDiscussionInternal"
|
||||
:class="{ '!gl-border-t-0': isFileDiscussion }"
|
||||
@handleDeleteNote="$emit('deleteNote')"
|
||||
|
|
@ -202,7 +196,6 @@ export default {
|
|||
:discussion-root="index === 0"
|
||||
:discussion-resolve-path="discussion.resolve_path"
|
||||
:is-overview-tab="isOverviewTab"
|
||||
:should-scroll-to-note="shouldScrollToNote"
|
||||
:internal-note="isDiscussionInternal"
|
||||
@handleDeleteNote="$emit('deleteNote')"
|
||||
>
|
||||
|
|
|
|||
|
|
@ -111,13 +111,7 @@ export default {
|
|||
</script>
|
||||
|
||||
<template>
|
||||
<noteable-note
|
||||
v-if="showNote"
|
||||
:id="`note_${noteId}`"
|
||||
:note="note"
|
||||
:show-reply-button="false"
|
||||
should-scroll-to-note
|
||||
>
|
||||
<noteable-note v-if="showNote" :id="`note_${noteId}`" :note="note" :show-reply-button="false">
|
||||
<template #note-body>
|
||||
<div ref="noteBody" class="note-body">
|
||||
<div v-safe-html:[$options.safeHtmlConfig]="noteHtml" class="note-text md"></div>
|
||||
|
|
|
|||
|
|
@ -76,11 +76,6 @@ export default {
|
|||
required: false,
|
||||
default: false,
|
||||
},
|
||||
shouldScrollToNote: {
|
||||
type: Boolean,
|
||||
required: false,
|
||||
default: true,
|
||||
},
|
||||
},
|
||||
data() {
|
||||
return {
|
||||
|
|
@ -331,7 +326,6 @@ export default {
|
|||
:line="line"
|
||||
:should-group-replies="shouldGroupReplies"
|
||||
:is-overview-tab="isOverviewTab"
|
||||
:should-scroll-to-note="shouldScrollToNote"
|
||||
@startReplying="showReplyForm"
|
||||
>
|
||||
<template #avatar-badge>
|
||||
|
|
|
|||
|
|
@ -99,11 +99,6 @@ export default {
|
|||
required: false,
|
||||
default: false,
|
||||
},
|
||||
shouldScrollToNote: {
|
||||
type: Boolean,
|
||||
required: false,
|
||||
default: true,
|
||||
},
|
||||
discussion: {
|
||||
type: Object,
|
||||
required: false,
|
||||
|
|
@ -273,12 +268,6 @@ export default {
|
|||
});
|
||||
},
|
||||
|
||||
mounted() {
|
||||
if (this.isTarget && this.shouldScrollToNote) {
|
||||
this.$el.scrollIntoView({ duration: 0 });
|
||||
}
|
||||
},
|
||||
|
||||
methods: {
|
||||
...mapActions([
|
||||
'deleteNote',
|
||||
|
|
|
|||
|
|
@ -175,6 +175,7 @@ export default {
|
|||
if (!isReady) return;
|
||||
this.$nextTick(() => {
|
||||
window.mrTabs?.eventHub.$emit('NotesAppReady');
|
||||
this.cleanup?.();
|
||||
});
|
||||
},
|
||||
immediate: true,
|
||||
|
|
@ -195,7 +196,7 @@ export default {
|
|||
window.addEventListener('hashchange', this.handleHashChanged);
|
||||
|
||||
if (this.targetNoteHash && this.targetNoteHash.startsWith('note_')) {
|
||||
scrollToTargetOnResize();
|
||||
this.cleanup = scrollToTargetOnResize();
|
||||
}
|
||||
|
||||
eventHub.$on('notesApp.updateIssuableConfidentiality', this.setConfidentiality);
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ import { __, n__, s__, sprintf } from '~/locale';
|
|||
|
||||
const digitText = ({ digit, bold = false } = {}) =>
|
||||
bold ? `%{strong_start}${digit}%{strong_end}` : digit;
|
||||
const noText = (bold = false) => (bold ? '%{strong_start}no%{strong_end}' : 'no');
|
||||
const noText = (bold = false) => (bold ? __('%{strong_start}no%{strong_end}') : __('no'));
|
||||
|
||||
export const TESTS_FAILED_STATUS = 'failed';
|
||||
export const ERROR_STATUS = 'error';
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ import toast from '~/vue_shared/plugins/global_toast';
|
|||
import { __ } from '~/locale';
|
||||
import Tracking from '~/tracking';
|
||||
import { updateDraft, clearDraft } from '~/lib/utils/autosave';
|
||||
import { scrollToTargetOnResize } from '~/lib/utils/resize_observer';
|
||||
import { renderMarkdown } from '~/notes/utils';
|
||||
import { getLocationHash } from '~/lib/utils/url_utility';
|
||||
import { getIdFromGraphQLId } from '~/graphql_shared/utils';
|
||||
|
|
@ -167,10 +166,7 @@ export default {
|
|||
return `note_${getIdFromGraphQLId(this.note.id)}`;
|
||||
},
|
||||
isTarget() {
|
||||
return this.targetNoteHash === this.noteAnchorId;
|
||||
},
|
||||
targetNoteHash() {
|
||||
return getLocationHash();
|
||||
return getLocationHash() === this.noteAnchorId;
|
||||
},
|
||||
noteUrl() {
|
||||
const routeParamType = this.$route?.params?.type;
|
||||
|
|
@ -204,11 +200,7 @@ export default {
|
|||
return this.note.discussion.resolvedBy;
|
||||
},
|
||||
},
|
||||
mounted() {
|
||||
if (this.isTarget) {
|
||||
scrollToTargetOnResize();
|
||||
}
|
||||
},
|
||||
|
||||
apollo: {
|
||||
workItem: {
|
||||
query: workItemByIidQuery,
|
||||
|
|
|
|||
|
|
@ -25,6 +25,7 @@ import {
|
|||
updateCacheAfterDeletingNote,
|
||||
} from '~/work_items/graphql/cache_utils';
|
||||
import { convertToGraphQLId, getIdFromGraphQLId } from '~/graphql_shared/utils';
|
||||
import { scrollToTargetOnResize } from '~/lib/utils/resize_observer';
|
||||
import { getLocationHash } from '~/lib/utils/url_utility';
|
||||
import { collapseSystemNotes } from '~/work_items/notes/collapse_utils';
|
||||
import WorkItemDiscussion from '~/work_items/components/notes/work_item_discussion.vue';
|
||||
|
|
@ -234,6 +235,11 @@ export default {
|
|||
return Boolean(n);
|
||||
},
|
||||
},
|
||||
mounted() {
|
||||
if (this.targetNoteHash) {
|
||||
this.cleanup = scrollToTargetOnResize();
|
||||
}
|
||||
},
|
||||
apollo: {
|
||||
previewNote: {
|
||||
skip() {
|
||||
|
|
@ -256,6 +262,8 @@ export default {
|
|||
// make sure skeleton notes are placed below the preview note
|
||||
if (result?.data?.note && this.$apollo.queries.workItemNotes?.loading) {
|
||||
this.isLoadingMore = true;
|
||||
} else {
|
||||
this.cleanup?.();
|
||||
}
|
||||
},
|
||||
error(error) {
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ module Ci
|
|||
private
|
||||
|
||||
# rubocop: disable CodeReuse/ActiveRecord
|
||||
def ids_for_ref(items, refs)
|
||||
def pipelines_for_ref(items)
|
||||
unfiltered_items =
|
||||
if Feature.enabled?(:exclude_child_pipelines_from_tag_branch_query, project)
|
||||
items
|
||||
|
|
@ -52,13 +52,34 @@ module Ci
|
|||
pipelines
|
||||
end
|
||||
|
||||
unfiltered_items.where(ref: refs).group(:ref).select('max(id)')
|
||||
where_query = Arel.sql("#{Ci::Pipeline.table_name}.ref = refs.ref")
|
||||
|
||||
unfiltered_items
|
||||
.where(where_query)
|
||||
.order(id: :desc)
|
||||
.limit(1) # Limit to 1 because we only want the latest pipeline per ref
|
||||
end
|
||||
# rubocop: enable CodeReuse/ActiveRecord
|
||||
|
||||
def refs_values(refs)
|
||||
# Create list of form `[['main'], ['branch1']]`
|
||||
list = refs.map { |ref| Array(ref) }
|
||||
|
||||
# Create values list of form `(VALUES ('main'), ('branch1'))`
|
||||
values_list = Arel::Nodes::Grouping.new(Arel::Nodes::ValuesList.new(list))
|
||||
|
||||
# (VALUES ('main'), ('branch1')) AS refs(ref)
|
||||
Arel::Nodes::As.new(values_list, Arel.sql('refs(ref)'))
|
||||
end
|
||||
|
||||
# rubocop: disable CodeReuse/ActiveRecord
|
||||
def from_ids(ids)
|
||||
pipelines.unscoped.where(project_id: project.id, id: ids)
|
||||
def from_derived_table(derived_pipelines_table, refs_values_table)
|
||||
pipelines
|
||||
.unscoped
|
||||
.from([
|
||||
refs_values_table,
|
||||
derived_pipelines_table.arel.lateral.as(Ci::Pipeline.table_name)
|
||||
])
|
||||
end
|
||||
# rubocop: enable CodeReuse/ActiveRecord
|
||||
|
||||
|
|
@ -102,9 +123,9 @@ module Ci
|
|||
when ALLOWED_SCOPES[:FINISHED]
|
||||
items.finished
|
||||
when ALLOWED_SCOPES[:BRANCHES]
|
||||
from_ids(ids_for_ref(items, branches))
|
||||
from_derived_table(pipelines_for_ref(items), refs_values(branches))
|
||||
when ALLOWED_SCOPES[:TAGS]
|
||||
from_ids(ids_for_ref(items, tags))
|
||||
from_derived_table(pipelines_for_ref(items), refs_values(tags))
|
||||
else
|
||||
items
|
||||
end
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
name: show_diff_if_head_sha_commit_is_missing
|
||||
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/511302
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/177932
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/513174
|
||||
milestone: '17.8'
|
||||
group: group::code review
|
||||
type: ops
|
||||
default_enabled: false
|
||||
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
For updates and details about this deprecation, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
|
||||
|
||||
GitLab self-managed customers can still use the feature [with a feature flag](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).
|
||||
GitLab Self-Managed customers can still use the feature [with a feature flag](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).
|
||||
stage: Configure
|
||||
tiers: [Free, Premium, Ultimate]
|
||||
issue_url: 'https://gitlab.com/groups/gitlab-org/configure/-/epics/8'
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
breaking_change: true
|
||||
reporter: abellucci
|
||||
body: |
|
||||
In GitLab 14.4, GitLab released an integrated error tracking backend that replaces Sentry. This feature caused database performance issues. In GitLab 14.9, integrated error tracking is removed from GitLab.com, and turned off by default in GitLab self-managed. While we explore the future development of this feature, please consider switching to the Sentry backend by [changing your error tracking to Sentry in your project settings](https://docs.gitlab.com/ee/operations/error_tracking.html#sentry-error-tracking).
|
||||
In GitLab 14.4, GitLab released an integrated error tracking backend that replaces Sentry. This feature caused database performance issues. In GitLab 14.9, integrated error tracking is removed from GitLab.com, and turned off by default in GitLab Self-Managed. While we explore the future development of this feature, please consider switching to the Sentry backend by [changing your error tracking to Sentry in your project settings](https://docs.gitlab.com/ee/operations/error_tracking.html#sentry-error-tracking).
|
||||
|
||||
For additional background on this removal, please reference [Disable Integrated Error Tracking by Default](https://gitlab.com/groups/gitlab-org/-/epics/7580). If you have feedback please add a comment to [Feedback: Removal of Integrated Error Tracking](https://gitlab.com/gitlab-org/gitlab/-/issues/355493).
|
||||
stage: monitor
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
breaking_change: true # If this deprecation is a breaking change, set this value to true
|
||||
reporter: abellucci # GitLab username of the person reporting the deprecation
|
||||
body: | # Do not modify this line, instead modify the lines below.
|
||||
GitLab self-monitoring gives administrators of GitLab self-managed instances the tools to monitor the health of their instances. This feature is deprecated in GitLab 14.9, and is scheduled for removal in 16.0.
|
||||
GitLab self-monitoring gives instance administrators the tools to monitor the health of their instances. This feature is deprecated in GitLab 14.9, and is scheduled for removal in 16.0.
|
||||
# The following items are not published on the docs page, but may be used in the future.
|
||||
stage: Monitor # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
|
||||
tiers: [Core, Premium, Ultimate] # (optional - may be required in the future) An array of tiers that the feature is available in currently. e.g., [Free, Silver, Gold, Core, Premium, Ultimate]
|
||||
|
|
|
|||
|
|
@ -7,12 +7,12 @@
|
|||
Whether your existing project access tokens have expiry dates automatically applied depends on what GitLab offering you have, and when you upgraded to GitLab 16.0 or later:
|
||||
|
||||
- On GitLab.com, during the 16.0 milestone, existing project access tokens without an expiry date were automatically given an expiry date of 365 days later than the current date.
|
||||
- On GitLab self-managed, if you upgraded from GitLab 15.11 or earlier to GitLab 16.0 or later:
|
||||
- On GitLab Self-Managed, if you upgraded from GitLab 15.11 or earlier to GitLab 16.0 or later:
|
||||
- On or before July 23, 2024, existing project access tokens without an expiry date were automatically given an expiry date of 365 days later than the current date.
|
||||
This change is a breaking change.
|
||||
- On or after July 24, 2024, existing project access tokens without an expiry date did not have an expiry date set.
|
||||
|
||||
On GitLab self-managed, if you do a new install of one of the following GitLab versions, your existing project access tokens do not have expiry dates automatically applied:
|
||||
On GitLab Self-Managed, if you do a new install of one of the following GitLab versions, your existing project access tokens do not have expiry dates automatically applied:
|
||||
|
||||
- 16.0.9
|
||||
- 16.1.7
|
||||
|
|
@ -43,7 +43,7 @@
|
|||
default is applied:
|
||||
|
||||
- On GitLab.com during the 16.0 milestone.
|
||||
- On GitLab self-managed instances when they are upgraded to 16.0.
|
||||
- On GitLab Self-Managed when they are upgraded to 16.0.
|
||||
stage: Foundations
|
||||
tiers: [Free, Premium, Ultimate]
|
||||
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/369122
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@
|
|||
|
||||
As an alternative we recommend using the new OpenTofu CI/CD component on GitLab.com
|
||||
or the new OpenTofu CI/CD template on self-managed.
|
||||
CI/CD components are not yet available on GitLab self-managed,
|
||||
CI/CD components are not yet available on GitLab Self-Managed,
|
||||
but [Issue #415638](https://gitlab.com/gitlab-org/gitlab/-/issues/415638)
|
||||
proposes to add this feature. If CI/CD components become available on self-managed,
|
||||
the OpenTofu CI/CD template will be removed.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ If the GitLab instance uses Admin Mode, you must [enable Admin Mode for your ses
|
|||
the **Admin** button is visible.
|
||||
|
||||
NOTE:
|
||||
Only administrators on GitLab self-managed or GitLab Dedicated can access the **Admin** area. On GitLab.com the **Admin** area feature is not available.
|
||||
Only administrators on GitLab Self-Managed or GitLab Dedicated can access the **Admin** area. On GitLab.com the **Admin** area feature is not available.
|
||||
|
||||
## Administering organizations
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ DETAILS:
|
|||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed
|
||||
|
||||
You can update your settings to change the look and feel of your GitLab self-managed instance.
|
||||
You can update your settings to change the look and feel of your instance.
|
||||
|
||||
To open the **Appearance** settings:
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ To test OIDC/OAuth in GitLab, you must:
|
|||
|
||||
Before you can test OIDC/OAuth on GitLab, you must:
|
||||
|
||||
- Have a publicly accessible GitLab self-managed instance.
|
||||
- Have a publicly accessible instance.
|
||||
- Be an administrator for that instance.
|
||||
- Have a client application that you want to use to test OIDC/OAuth.
|
||||
|
||||
|
|
|
|||
|
|
@ -213,7 +213,7 @@ For more information, see how to
|
|||
|
||||
## Incremental logging architecture
|
||||
|
||||
> - To use in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-incremental-logging).
|
||||
> - To use in your instance, ask a GitLab administrator to [enable it](#enable-or-disable-incremental-logging).
|
||||
|
||||
By default, job logs are sent from the GitLab Runner in chunks and cached
|
||||
temporarily on disk. After the job completes, a background job archives the job
|
||||
|
|
|
|||
|
|
@ -222,3 +222,37 @@ set the following parameter in `/etc/gitlab/gitlab.rb`. Replace `gitlab.example.
|
|||
```ruby
|
||||
gitlab_kas['gitlab_address'] = 'http://gitlab.example.com'
|
||||
```
|
||||
|
||||
### Error: `x509: certificate signed by unknown authority`
|
||||
|
||||
If you encounter this error when trying to reach the GitLab URL, it means it doesn't trust the GitLab certificate.
|
||||
|
||||
You might see a similar error in the Kubernetes Agent Server (KAS) logs of your GitLab application server:
|
||||
|
||||
```json
|
||||
{"level":"error","time":"2023-03-07T20:19:48.151Z","msg":"AgentInfo()","grpc_service":"gitlab.agent.agent_configuration.rpc.AgentConfiguration","grpc_method":"GetConfiguration","error":"Get \"https://gitlab.example.com/api/v4/internal/kubernetes/agent_info\": x509: certificate signed by unknown authority"}
|
||||
```
|
||||
|
||||
To fix this error, install the public certificate of your internal CA in the `/etc/gitlab/trusted-certs` directory.
|
||||
|
||||
Alternatively, you can configure your KAS to read the certificate from a custom directory. To do this, add to `/etc/gitlab/gitlab.rb` the following configuration:
|
||||
|
||||
```ruby
|
||||
gitlab_kas['env'] = {
|
||||
'SSL_CERT_DIR' => "/opt/gitlab/embedded/ssl/certs/"
|
||||
}
|
||||
```
|
||||
|
||||
To apply the changes:
|
||||
|
||||
1. Reconfigure GitLab:
|
||||
|
||||
```shell
|
||||
sudo gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Restart GitLab KAS:
|
||||
|
||||
```shell
|
||||
gitlab-ctl restart gitlab-kas
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ group: Authentication
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Credentials inventory for GitLab self-managed
|
||||
# Credentials inventory for GitLab Self-Managed
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Ultimate
|
||||
|
|
@ -14,7 +14,7 @@ As a GitLab administrator, you are responsible for the overall security of your
|
|||
To assist, GitLab provides an inventory of all the credentials that can be used to access
|
||||
your self-managed instance.
|
||||
|
||||
This page describes how to manage the credentials inventory for GitLab self-managed. To manage credentials on GitLab.com, see [Credentials inventory for GitLab.com](../user/group/credentials_inventory.md).
|
||||
This page describes how to manage the credentials inventory for GitLab Self-Managed. To manage credentials on GitLab.com, see [Credentials inventory for GitLab.com](../user/group/credentials_inventory.md).
|
||||
|
||||
In the credentials inventory, you can view all:
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ If you've been granted access to Switchboard, you will receive an email invitati
|
|||
credentials to sign in.
|
||||
|
||||
The credentials for Switchboard are separate from any other GitLab credentials you may already have
|
||||
to sign in to a GitLab self-managed or GitLab.com instance.
|
||||
to sign in to a GitLab Self-Managed instance or GitLab.com.
|
||||
|
||||
After you first sign in to Switchboard, you must update your password and set up MFA before you can
|
||||
complete your onboarding to create a new instance.
|
||||
|
|
|
|||
|
|
@ -192,7 +192,7 @@ The following are required to run Geo:
|
|||
Geo sites. If using different operating system versions between Geo sites, you
|
||||
**must** [check OS locale data compatibility](replication/troubleshooting/common.md#check-os-locale-data-compatibility)
|
||||
across Geo sites to avoid silent corruption of database indexes.
|
||||
- [Supported PostgreSQL versions](https://handbook.gitlab.com/handbook/engineering/infrastructure/core-platform/data_stores/database/postgresql-upgrade-cadence/) for your GitLab releases with [Streaming Replication](https://wiki.postgresql.org/wiki/Streaming_Replication).
|
||||
- [Supported PostgreSQL versions](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/) for your GitLab releases with [Streaming Replication](https://wiki.postgresql.org/wiki/Streaming_Replication).
|
||||
- [PostgreSQL Logical replication](https://www.postgresql.org/docs/current/logical-replication.html) is not supported.
|
||||
- All sites must run [the same PostgreSQL versions](setup/database.md#postgresql-replication).
|
||||
- Git 2.9 or later
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ The replication for some data types is behind a corresponding feature flag:
|
|||
> - They're enabled on GitLab.com.
|
||||
> - They can't be enabled or disabled per-project.
|
||||
> - They are recommended for production use.
|
||||
> - For GitLab self-managed instances, GitLab administrators can opt to [disable them](#enable-or-disable-replication-for-some-data-types).
|
||||
> - For a GitLab Self-Managed instance, GitLab administrators can opt to [disable them](#enable-or-disable-replication-for-some-data-types).
|
||||
|
||||
#### Enable or disable replication (for some data types)
|
||||
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ GitLab provides backup methods to keep your data safe and recoverable. Whether y
|
|||
- Run a test backup and restore.
|
||||
- Set up a way to periodically verify the backups.
|
||||
|
||||
### Back up a GitLab self-managed instance
|
||||
### Back up an instance
|
||||
|
||||
The routine differs, depending on whether you deployed with the Linux package or the Helm chart.
|
||||
|
||||
|
|
@ -205,7 +205,7 @@ Learn more about using [Geo as a disaster recovery solution](../administration/g
|
|||
Geo replicates your database, your Git repositories, and a few other assets.
|
||||
Learn more about the [data types Geo replicates](../administration/geo/replication/datatypes.md#replicated-data-types).
|
||||
|
||||
## Support for GitLab self-managed
|
||||
## Support for GitLab Self-Managed
|
||||
|
||||
GitLab provides support for GitLab Self-Managed through different channels.
|
||||
|
||||
|
|
|
|||
|
|
@ -1010,9 +1010,9 @@ read about [Helm IMAP secrets](https://docs.gitlab.com/charts/installation/secre
|
|||
|
||||
### Email ingestion doesn't work in 16.6.0
|
||||
|
||||
GitLab self-managed `16.6.0` introduced a regression that prevents `mail_room` (email ingestion) from starting.
|
||||
In GitLab 16.6, a regression prevents `mail_room` (email ingestion) from starting.
|
||||
Service Desk and other reply-by-email features don't work.
|
||||
[Issue 432257](https://gitlab.com/gitlab-org/gitlab/-/issues/432257) tracks fixing this problem.
|
||||
This issue was fixed in 16.6.1. See [issue 432257](https://gitlab.com/gitlab-org/gitlab/-/issues/432257) for details.
|
||||
|
||||
The workaround is to run the following commands in your GitLab installation
|
||||
to patch the affected files:
|
||||
|
|
|
|||
|
|
@ -342,7 +342,7 @@ Blocked recursive webhook calls are logged in `auth.log` with the message `"Recu
|
|||
|
||||
The number of [placeholder users](../user/project/import/index.md#placeholder-users) created during an import can be limited per top-level namespace.
|
||||
|
||||
The default limit for [GitLab self-managed](../subscriptions/self_managed/index.md) is `0` (unlimited).
|
||||
The default limit for [GitLab Self-Managed](../subscriptions/self_managed/index.md) is `0` (unlimited).
|
||||
|
||||
To change this limit for a self-managed installation, run the following in the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
|
||||
|
||||
|
|
@ -458,7 +458,7 @@ any job with an [`environment`](../ci/environments/index.md) specified. The numb
|
|||
of deployments in a pipeline is checked at pipeline creation. Pipelines that have
|
||||
too many deployments fail with a `deployments_limit_exceeded` error.
|
||||
|
||||
The default limit is 500 for all [GitLab self-managed and SaaS plans](https://about.gitlab.com/pricing/).
|
||||
The default limit is 500 for all [GitLab Self-Managed and GitLab.com plans](https://about.gitlab.com/pricing/).
|
||||
|
||||
To change the limit for a self-managed installation, change the `default` plan's limit with the following
|
||||
[GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session) command:
|
||||
|
|
@ -671,7 +671,7 @@ Plan.default.actual_limits.update!(ci_max_artifact_size_junit: 10)
|
|||
The total number of file entries (including directories and symlinks) is limited to `200,000` per
|
||||
GitLab Pages website.
|
||||
|
||||
This is the default limit for all [GitLab self-managed and SaaS plans](https://about.gitlab.com/pricing/).
|
||||
This is the default limit for all [GitLab Self-Managed and GitLab.com plans](https://about.gitlab.com/pricing/).
|
||||
|
||||
You can update the limit in your self-managed instance using the
|
||||
[GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session).
|
||||
|
|
@ -685,7 +685,7 @@ Plan.default.actual_limits.update!(pages_file_entries: 100)
|
|||
|
||||
The total number of custom domains per GitLab Pages website is limited to `150` for [GitLab SaaS](../subscriptions/gitlab_com/index.md).
|
||||
|
||||
The default limit for [GitLab self-managed](../subscriptions/self_managed/index.md) is `0` (unlimited).
|
||||
The default limit for [GitLab Self-Managed](../subscriptions/self_managed/index.md) is `0` (unlimited).
|
||||
To set a limit on your self-managed instance, use the
|
||||
[**Admin** area](pages/index.md#set-maximum-number-of-gitlab-pages-custom-domains-for-a-project).
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ To activate your instance with an activation code:
|
|||
1. Copy the activation code, a 24-character alphanumeric string, from either:
|
||||
- Your subscription confirmation email.
|
||||
- The [Customers Portal](https://customers.gitlab.com/customers/sign_in), on the **Manage Purchases** page.
|
||||
1. Sign in to your GitLab self-managed instance.
|
||||
1. Sign in to your instance.
|
||||
1. On the left sidebar, at the bottom, select **Admin**.
|
||||
1. Select **Subscription**.
|
||||
1. Paste the activation code in **Activation code**.
|
||||
|
|
|
|||
|
|
@ -10,10 +10,10 @@ DETAILS:
|
|||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed
|
||||
|
||||
If you are the administrator of a GitLab self-managed instance, you have several options to moderate and control user access.
|
||||
If you are an instance administrator, you have several options to moderate and control user access.
|
||||
|
||||
NOTE:
|
||||
This topic is specifically related to user moderation in a GitLab self-managed instance. For information related to groups, see the [group documentation](../user/group/moderate_users.md).
|
||||
This topic is specifically related to user moderation in GitLab Self-Managed. For information related to groups, see the [group documentation](../user/group/moderate_users.md).
|
||||
|
||||
## Users pending approval
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Read more about update policies and warnings in the PostgreSQL
|
|||
|
||||
| First GitLab version | PostgreSQL versions | Default version for fresh installs | Default version for upgrades | Notes |
|
||||
| -------------- | ------------------- | ---------------------------------- | ---------------------------- | ----- |
|
||||
| 17.5.0 | 14.11, 16.4 | 14.11 | 16.4 | Single node upgrades from PostgreSQL 14 to PostgreSQL 16 are now supported. |
|
||||
| 17.5.0 | 14.11, 16.4 | 14.11 | 16.4 | Single node upgrades from PostgreSQL 14 to PostgreSQL 16 are now supported. Starting with GitLab 17.5.0, PostgreSQL 16 is fully supported for both new installations and upgrades in Geo deployments (the restriction from 17.4.0 no longer applies). |
|
||||
| 17.4.0 | 14.11, 16.4 | 14.11 | 14.11 | PostgreSQL 16 is available for new installations if not using [Geo](../geo/index.md#requirements-for-running-geo) or [Patroni](../postgresql/index.md#postgresql-replication-and-failover-for-linux-package-installations). |
|
||||
| 17.0.0 | 14.11 | 14.11 | 14.11 | Package upgrades are aborted if PostgreSQL is not upgraded to 14 already. |
|
||||
| 16.10.1, 16.9.3, 16.8.5 | 13.14, 14.11 | 14.11 | 14.11 | |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ DETAILS:
|
|||
**Tier:** Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed
|
||||
|
||||
If you're a Free user of GitLab self-managed, consider using a cloud-hosted solution.
|
||||
If you're a Free user of GitLab Self-Managed, consider using a cloud-hosted solution.
|
||||
This document doesn't cover self-compiled installations.
|
||||
|
||||
If a setup with replication and failover isn't what you were looking for, see
|
||||
|
|
|
|||
|
|
@ -76,7 +76,7 @@ The authentication process for self-hosted models is secure, efficient, and made
|
|||
|
||||
- **Offline environments**: In offline setups, there are no connections to `cloud.gitlab.com`. All requests are routed exclusively to the self-hosted AI gateway.
|
||||
|
||||
- **Token minting and verification**: The GitLab self-managed instance mints the token, which is then verified by the AI gateway against the GitLab instance.
|
||||
- **Token minting and verification**: The instance mints the token, which is then verified by the AI gateway against the GitLab instance.
|
||||
|
||||
- **Model configuration and security**: When an administrator configures a model, they can incorporate an API key to authenticate requests. Additionally, you can enhance security by specifying connection IP addresses within your network, ensuring that only trusted IPs can interact with the model.
|
||||
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ If you do not meet the use case criteria for self-hosted models, you can use the
|
|||
GitLab.com AI gateway with default GitLab external vendor LLMs.
|
||||
|
||||
The GitLab.com AI gateway is the default Enterprise offering and is not self-hosted. In this configuration,
|
||||
you connect your GitLab Self-Managed instance to the GitLab-hosted AI gateway, which
|
||||
you connect your instance to the GitLab-hosted AI gateway, which
|
||||
integrates with external vendor LLM providers (such as Google Vertex or Anthropic).
|
||||
|
||||
These LLMs communicate through the [GitLab Cloud Connector](../../development/cloud_connector/index.md),
|
||||
|
|
|
|||
|
|
@ -263,11 +263,11 @@ By default, the log does not contain LLM prompt input and response output to sup
|
|||
|
||||
## Logging Scenarios
|
||||
|
||||
### GitLab self-managed and self-hosted AI gateway
|
||||
### GitLab Self-Managed and self-hosted AI gateway
|
||||
|
||||
In this configuration, both GitLab and the AI gateway are hosted by the customer.
|
||||
|
||||
- **Logging Behavior**: Full logging is enabled, and all prompts, inputs, and outputs are logged to `llm.log` on the GitLab self-managed instance.
|
||||
- **Logging Behavior**: Full logging is enabled, and all prompts, inputs, and outputs are logged to `llm.log` on the instance.
|
||||
- **Expanded Logging**: When the `:expanded_ai_logging` feature flag is activated, extra debugging information is logged, including:
|
||||
- Preprocessed prompts.
|
||||
- Final prompts.
|
||||
|
|
@ -276,7 +276,7 @@ In this configuration, both GitLab and the AI gateway are hosted by the customer
|
|||
- The customer has full control over data handling.
|
||||
- Logging of sensitive information can be enabled or disabled at the customer's discretion.
|
||||
|
||||
### GitLab self-managed and GitLab-managed AI gateway (cloud-connected)
|
||||
### GitLab Self-Managed and GitLab-managed AI gateway (cloud-connected)
|
||||
|
||||
In this scenario, the customer hosts GitLab but relies on the GitLab-managed AI gateway for AI processing.
|
||||
|
||||
|
|
@ -291,8 +291,8 @@ The `:expanded_ai_logging` feature flag controls whether additional debugging in
|
|||
|
||||
### Behavior by Deployment Setup
|
||||
|
||||
- **GitLab self-managed and self-hosted AI gateway**: The feature flag enables detailed logging to `llm.log` on the self-hosted instance, capturing inputs and outputs for AI models.
|
||||
- **GitLab self-managed and GitLab-managed AI gateway**: The feature flag enables logging on your self-managed instance. However, the flag does **not** activate expanded logging for the GitLab-managed AI gateway side. Logging remains disabled for the cloud-connected AI gateway to protect sensitive data.
|
||||
- **GitLab Self-Managed and self-hosted AI gateway**: The feature flag enables detailed logging to `llm.log` on the self-hosted instance, capturing inputs and outputs for AI models.
|
||||
- **GitLab Self-Managed and GitLab-managed AI gateway**: The feature flag enables logging on your self-managed instance. However, the flag does **not** activate expanded logging for the GitLab-managed AI gateway side. Logging remains disabled for the cloud-connected AI gateway to protect sensitive data.
|
||||
For more information, see the [Feature Flag section under Privacy Considerations](../../development/ai_features/index.md#privacy-considerations) documentation.
|
||||
|
||||
### Logging in cloud-connected AI gateways
|
||||
|
|
|
|||
|
|
@ -279,7 +279,7 @@ If you are experiencing issues accessing Code Suggestions after setup, try the f
|
|||
|
||||
## Verify GitLab setup
|
||||
|
||||
To verify your GitLab self-managed setup, run the following command:
|
||||
To verify your GitLab Self-Managed setup, run the following command:
|
||||
|
||||
```shell
|
||||
gitlab-rake gitlab:duo:verify_self_hosted_setup
|
||||
|
|
|
|||
|
|
@ -250,10 +250,10 @@ DETAILS:
|
|||
**Tier:** Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163726) in GitLab 17.5 [with a feature flag](../feature_flags.md) named `allow_top_level_group_owners_to_create_service_accounts` for GitLab self-managed. Disabled by default.
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163726) in GitLab 17.5 [with a feature flag](../feature_flags.md) named `allow_top_level_group_owners_to_create_service_accounts` for GitLab Self-Managed. Disabled by default.
|
||||
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172502) in GitLab 17.6. Feature flag `allow_top_level_group_owners_to_create_service_accounts` removed.
|
||||
|
||||
By default, in GitLab self-managed, top-level group Owners can not create service accounts. GitLab administrators can allow top-level group Owners to create service accounts.
|
||||
By default, in GitLab Self-Managed, top-level group Owners can not create service accounts. GitLab administrators can allow top-level group Owners to create service accounts.
|
||||
|
||||
1. On the left sidebar, at the bottom, select **Admin**.
|
||||
1. Select **Settings > General**.
|
||||
|
|
|
|||
|
|
@ -203,7 +203,7 @@ The default job limit is:
|
|||
|
||||
- For the GitHub importer, 1000.
|
||||
- For the Bitbucket Cloud and Bitbucket Server importer, 100. The Bitbucket importers have a low default limit because
|
||||
we haven't yet determined a good default limit. Administrators of GitLab Self-Managed instances should experiment with
|
||||
we haven't yet determined a good default limit. Instance administrators should experiment with
|
||||
a higher limit.
|
||||
|
||||
To modify this setting:
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ DETAILS:
|
|||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed
|
||||
|
||||
As an administrator of a GitLab self-managed instance, you can manage the behavior of your
|
||||
As an instance administrator, you can manage the behavior of your
|
||||
deployment.
|
||||
|
||||
Use **Settings** to control settings across the instance.
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ To configure your Jira instance so you can install apps from outside the Atlassi
|
|||
on your instance configuration.
|
||||
|
||||
By default, your manifest file is located at `/-/jira_connect/app_descriptor.json`.
|
||||
For example, if your GitLab self-managed instance domain is `app.pet-store.cloud`,
|
||||
For example, if your instance domain is `app.pet-store.cloud`,
|
||||
your manifest file is located at `https://app.pet-store.cloud/-/jira_connect/app_descriptor.json`.
|
||||
|
||||
1. Select **Upload**.
|
||||
|
|
|
|||
|
|
@ -129,7 +129,7 @@ Depending on how you installed the app, you might want to check the following:
|
|||
|
||||
- If you [installed the app manually](jira_cloud_app.md#install-the-gitlab-for-jira-cloud-app-manually):
|
||||
- Ask [Jira Cloud Support](https://support.atlassian.com/jira-software-cloud/) to verify that Jira can connect to your
|
||||
GitLab Self-Managed instance.
|
||||
instance.
|
||||
- [Reinstall the app](jira_cloud_app.md#install-the-gitlab-for-jira-cloud-app-manually). This method might remove all [synced data](../../integration/jira/connect-app.md#gitlab-data-synced-to-jira) from the [Jira development panel](../../integration/jira/development_panel.md).
|
||||
|
||||
## Error: `Failed to update the GitLab instance`
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ DETAILS:
|
|||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed
|
||||
|
||||
As an administrator of a GitLab self-managed instance, you can manage the behavior of your
|
||||
As an instance administrator, you can manage the behavior of your
|
||||
deployment.
|
||||
|
||||
## Change the default first day of the week
|
||||
|
|
|
|||
|
|
@ -114,8 +114,8 @@ for all authenticated users, and on the **Admin** area pages. The statuses are:
|
|||
|
||||
### Request flow example
|
||||
|
||||
The following example shows a basic request/response flow between a
|
||||
GitLab Self-Managed instance and the GitLab Version Application:
|
||||
The following example shows a basic request/response flow between your
|
||||
instance and the GitLab Version Application:
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ To avoid having a breaking change affect your integrations, you should:
|
|||
|
||||
For more information, see [Deprecating GitLab features](../../development/deprecation_guidelines/index.md).
|
||||
|
||||
For GitLab self-managed instances, [downgrading](../../downgrade_ee_to_ce/index.md) from an EE instance to CE causes breaking changes.
|
||||
For GitLab Self-Managed, [downgrading](../../downgrade_ee_to_ce/index.md) from an EE instance to CE causes breaking changes.
|
||||
|
||||
### Breaking change exemptions
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ DETAILS:
|
|||
> - [Delete project introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/139696) in GitLab 16.8.
|
||||
> - [Manage group access tokens introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/140115) in GitLab 16.8.
|
||||
> - [Admin terraform state introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/140759) in GitLab 16.8.
|
||||
> - Ability to create and remove an instance-wide custom role on GitLab self-managed [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141562) in GitLab 16.9.
|
||||
> - Ability to create and remove an instance-wide custom role on GitLab Self-Managed [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141562) in GitLab 16.9.
|
||||
|
||||
Use this API to interact with member roles for your GitLab.com groups or entire self-managed instance.
|
||||
|
||||
|
|
|
|||
|
|
@ -462,4 +462,4 @@ notice:
|
|||
[experimental or beta](../../policy/development_stages_support.md).
|
||||
- Fields behind a feature flag and disabled by default.
|
||||
|
||||
For GitLab self-managed instances, [downgrading](../../downgrade_ee_to_ce/index.md) from an EE instance to CE causes breaking changes.
|
||||
For GitLab Self-Managed, [downgrading](../../downgrade_ee_to_ce/index.md) from an EE instance to CE causes breaking changes.
|
||||
|
|
|
|||
|
|
@ -177,7 +177,7 @@ On GitLab SaaS:
|
|||
/chatops run feature set ci_unlock_pipelines_extra_low true
|
||||
```
|
||||
|
||||
On GitLab self-managed:
|
||||
On GitLab Self-Managed:
|
||||
|
||||
- [Enable the feature flag](../../administration/feature_flags.md) named `ci_unlock_pipelines_extra_low`.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ and deploying your code. Both share similarities including:
|
|||
Additionally, there are some important differences between the two:
|
||||
|
||||
- GitHub has a marketplace for downloading 3rd-party actions, which might require additional support or licenses.
|
||||
- GitLab Self-Managed instances support both horizontal and vertical scaling, while
|
||||
- GitLab Self-Managed supports both horizontal and vertical scaling, while
|
||||
GitHub Enterprise Server only supports vertical scaling.
|
||||
- GitLab maintains and supports all features in house, and some 3rd-party integrations
|
||||
are accessible through templates.
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ in a CI/CD pipeline, but variables are less secure than secrets management provi
|
|||
Variable values:
|
||||
|
||||
- Are stored in the GitLab project, group, or instance settings. Users with access
|
||||
to the settings have access to the variables.
|
||||
to the settings have access to variables values that are not [hidden](../variables/index.md#hide-a-cicd-variable).
|
||||
- Can be [overridden](../variables/index.md#use-pipeline-variables),
|
||||
making it hard to determine which value was used.
|
||||
- Can be exposed by accidental pipeline misconfiguration.
|
||||
|
|
@ -53,3 +53,4 @@ sensitivity data that you want to store in a CI/CD variable, be sure to always:
|
|||
- [Mask the variables](../variables/index.md#mask-a-cicd-variable)
|
||||
or [Mask and hide the variable](../variables/index.md#hide-a-cicd-variable).
|
||||
- [Protect the variables](../variables/index.md#protect-a-cicd-variable) when possible.
|
||||
- [Hide the variables](../variables/index.md#hide-a-cicd-variable) when possible.
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ To continue using registration tokens after GitLab 17.0:
|
|||
|
||||
- On GitLab.com, you can manually [enable the legacy runner registration process](runners_scope.md#enable-use-of-runner-registration-tokens-in-projects-and-groups)
|
||||
in the top-level group settings until GitLab 18.0.
|
||||
- On GitLab self-managed, you can manually [enable the legacy runner registration process](../../administration/settings/continuous_integration.md#allow-runner-registrations-tokens)
|
||||
- On GitLab Self-Managed, you can manually [enable the legacy runner registration process](../../administration/settings/continuous_integration.md#allow-runner-registrations-tokens)
|
||||
in the **Admin** area settings until GitLab 18.0.
|
||||
|
||||
## Impact on existing runners
|
||||
|
|
|
|||
|
|
@ -230,7 +230,7 @@ To add a new unit primitive, follow [Register new feature for Self-Managed, Dedi
|
|||
|
||||
#### CustomersDot configuration
|
||||
|
||||
For GitLab Dedicated and GitLab Self-Managed instances we are delegating trust to the CustomersDot, the access token issuer.
|
||||
For GitLab Dedicated and GitLab Self-Managed we are delegating trust to the CustomersDot, the access token issuer.
|
||||
|
||||
The configuration is located in [`cloud_connector.yml`](https://gitlab.com/gitlab-org/customers-gitlab-com/-/blob/main/config/cloud_connector.yml),
|
||||
and represents an almost exact copy of the GitLab.com configuration.
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ because we do not currently have interfaces in place to self-service this.
|
|||
|
||||
#### Register the new feature in the JWT issuer
|
||||
|
||||
- For GitLab Dedicated and GitLab Self-Managed instances, the CustomersDot is the **JWT issuer**.
|
||||
- For GitLab Dedicated and GitLab Self-Managed, the CustomersDot is the **JWT issuer**.
|
||||
- For GitLab.com deployment, GitLab.com is the **JWT issuer**, because it's able to [self-sign and create JWTs](architecture.md#gitlabcom) for every request to a Cloud Connector feature.
|
||||
|
||||
#### Register new feature for Self-Managed, Dedicated and GitLab.com customers
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ For versioning and upgrade details, see our [Release and Maintenance policy](../
|
|||
|
||||
## Requesting a breaking change in a minor release
|
||||
|
||||
GitLab self-managed packages are semantically versioned and follow our [maintenance policy](../../policy/maintenance.md). This process applies to features and APIs that are generally available, not beta or experimental.
|
||||
GitLab Self-Managed packages are semantically versioned and follow our [maintenance policy](../../policy/maintenance.md). This process applies to features and APIs that are generally available, not beta or experimental.
|
||||
|
||||
This maintenance policy is in place to allow our customers to prepare for disruptive changes by establishing a clear and predictable pattern that is widely used in the software industry. For many of our customers, GitLab is a business-critical application and surprising changes can cause damages and erode trust.
|
||||
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@ For screenshots:
|
|||
When including sample URLs in the documentation, use:
|
||||
|
||||
- `example.com` when the domain name is generic.
|
||||
- `gitlab.example.com` when referring only to GitLab Self-Managed instances.
|
||||
- `gitlab.example.com` when referring only to GitLab Self-Managed.
|
||||
Use `gitlab.com` for GitLab SaaS instances.
|
||||
|
||||
### Fake tokens
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ DETAILS:
|
|||
> - `product_analytics_internal_preview` replaced with `product_analytics_dashboards` in GitLab 15.11.
|
||||
> - Snowplow integration [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398253) in GitLab 15.11 [with a flag](../../administration/feature_flags.md) named `product_analytics_snowplow_support`. Disabled by default.
|
||||
> - Snowplow integration feature flag `product_analytics_snowplow_support` [removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/130228) in GitLab 16.4.
|
||||
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/414865) from GitLab self-managed to GitLab.com in 16.7.
|
||||
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/414865) from GitLab Self-Managed to GitLab.com in 16.7.
|
||||
> - Enabled in GitLab 16.7 as a [beta](../../policy/development_stages_support.md#beta) feature.
|
||||
> - `product_analytics_dashboards` [enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/398653) by default in GitLab 16.11.
|
||||
> - Feature flag `product_analytics_dashboards` [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/454059) in GitLab 17.1.
|
||||
|
|
@ -118,7 +118,7 @@ A self-managed product analytics provider is a deployed instance of the
|
|||
|
||||
On GitLab.com, the self-managed provider details are defined in [project-level settings](#project-level-settings).
|
||||
|
||||
On GitLab self-managed, you must define the self-managed analytics provider in [instance-level settings](#instance-level-settings).
|
||||
On GitLab Self-Managed, you must define the self-managed analytics provider in [instance-level settings](#instance-level-settings).
|
||||
If you need different providers for different projects, you can define additional analytics providers in [project-level settings](#project-level-settings).
|
||||
|
||||
::EndTabs
|
||||
|
|
@ -132,7 +132,7 @@ Prerequisites:
|
|||
- You must have administrator access for the instance.
|
||||
|
||||
NOTE:
|
||||
These instance-level settings are required to enable product analytics on GitLab self-managed,
|
||||
These instance-level settings are required to enable product analytics on GitLab Self-Managed,
|
||||
and cascade to all projects by default.
|
||||
|
||||
To enable product analytics on your instance:
|
||||
|
|
|
|||
|
|
@ -12,12 +12,12 @@ See the [high-level architecture](../../user/application_security/secret_detecti
|
|||
to understand the Secret Detection post-processing and revocation flow.
|
||||
|
||||
GitLab.com uses the internally-maintained [Secret Revocation Service](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/secret-revocation-service)
|
||||
(team-members only) as its Token Revocation API. For GitLab self-managed, you can create
|
||||
(team-members only) as its Token Revocation API. For GitLab Self-Managed, you can create
|
||||
your own API and configure GitLab to use it.
|
||||
|
||||
## Implement a Token Revocation API for self-managed
|
||||
|
||||
GitLab self-managed instances interested in using the revocation capabilities must:
|
||||
GitLab Self-Managed instances interested in using the revocation capabilities must:
|
||||
|
||||
- Implement and deploy your own Token Revocation API.
|
||||
- Configure the GitLab instance to use the Token Revocation API.
|
||||
|
|
|
|||
|
|
@ -61,6 +61,6 @@ Once you have a project identified to use:
|
|||
|
||||
## Related design documents
|
||||
|
||||
- [GitLab Observability in GitLab.com and GitLab Self-Managed instances](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/observability_for_self_managed/)
|
||||
- [GitLab Observability in GitLab.com and GitLab Self-Managed](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/observability_for_self_managed/)
|
||||
- [GitLab Observability - Metrics](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/observability_metrics/)
|
||||
- [GitLab Observability - Logging](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/observability_logging/)
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ OpenShift - GitLab compatibility can be addressed in three different aspects. Th
|
|||
|
||||
OpenShift helps you to develop, deploy, and manage container-based applications. It provides you with a self-service platform to create, modify, and deploy applications on demand, thus enabling faster development and release lifecycles.
|
||||
|
||||
## Use OpenShift to run GitLab self-managed
|
||||
## Use OpenShift to run GitLab Self-Managed
|
||||
|
||||
You can run GitLab in an OpenShift cluster with the GitLab Operator. For more information about
|
||||
setting up GitLab on OpenShift, see [GitLab Operator](https://docs.gitlab.com/operator/).
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ request from your browser.
|
|||
To use the GitLab Gitpod integration, you must enable it for your GitLab instance and in your preferences. Users of:
|
||||
|
||||
- GitLab.com can use it immediately after it's [enabled in their user preferences](#enable-gitpod-in-your-user-preferences).
|
||||
- GitLab self-managed instances can use it after:
|
||||
- GitLab Self-Managed instances can use it after:
|
||||
1. It's [enabled and configured by a GitLab administrator](#configure-a-self-managed-instance).
|
||||
1. It's [enabled in their user settings](#enable-gitpod-in-your-user-preferences).
|
||||
|
||||
|
|
@ -45,7 +45,7 @@ DETAILS:
|
|||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
For GitLab Self-Managed instances, a GitLab administrator must:
|
||||
For GitLab Self-Managed, a GitLab administrator must:
|
||||
|
||||
1. Enable the Gitpod integration in GitLab:
|
||||
1. On the left sidebar, at the bottom, select **Admin**.
|
||||
|
|
@ -54,7 +54,7 @@ For GitLab Self-Managed instances, a GitLab administrator must:
|
|||
1. Select the **Enable Gitpod integration** checkbox.
|
||||
1. Enter the Gitpod instance URL (for example, `https://gitpod.example.com` or `https://gitpod.io`).
|
||||
1. Select **Save changes**.
|
||||
1. Register the GitLab Self-Managed instance in Gitpod. For more information, see the [Gitpod documentation](https://www.gitpod.io/docs/configure/authentication/gitlab#registering-a-self-hosted-gitlab-installation).
|
||||
1. Register the instance in Gitpod. For more information, see the [Gitpod documentation](https://www.gitpod.io/docs/configure/authentication/gitlab#registering-a-self-hosted-gitlab-installation).
|
||||
|
||||
GitLab users can then [enable the Gitpod integration for themselves](#enable-gitpod-in-your-user-preferences).
|
||||
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ For this issue, check:
|
|||
WebHook Error => execution expired
|
||||
```
|
||||
|
||||
On GitLab Self-Managed instances, you can fix this issue by [increasing the webhook timeout value](../administration/instance_limits.md#webhook-timeout).
|
||||
On GitLab Self-Managed, you can fix this issue by [increasing the webhook timeout value](../administration/instance_limits.md#webhook-timeout).
|
||||
|
||||
### Enable job logs in Jenkins
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ For error tracking to work, you need:
|
|||
- To use the GitLab backend, see [GitLab integrated error tracking](integrated_error_tracking.md).
|
||||
Integrated error tracking is available only on GitLab.com.
|
||||
- To use Sentry as the backend, see [Sentry error tracking](sentry_error_tracking.md).
|
||||
Sentry-based error tracking is available for GitLab.com, GitLab Dedicated, and GitLab self-managed.
|
||||
Sentry-based error tracking is available for GitLab.com, GitLab Dedicated, and GitLab Self-Managed.
|
||||
|
||||
## How error tracking works
|
||||
|
||||
|
|
@ -32,4 +32,4 @@ The following table gives an overview of the capabilities for each GitLab offeri
|
|||
| Feature | Availability | Data collection | Data storage | Data query |
|
||||
| ----------- | ----------- | ----------- | ----------- | ----------- |
|
||||
| [GitLab integrated Error Tracking](integrated_error_tracking.md) | GitLab.com | With [Sentry SDK](https://github.com/getsentry/sentry?tab=readme-ov-file#official-sentry-sdks) | On GitLab.com | With GitLab.com |
|
||||
| [Sentry-based Error Tracking](sentry_error_tracking.md) | GitLab.com, GitLab Dedicated, GitLab self-managed | With [Sentry SDK](https://github.com/getsentry/sentry?tab=readme-ov-file#official-sentry-sdks) | On Sentry instance (Cloud Sentry.io or [self-hosted Sentry](https://develop.sentry.dev/self-hosted/)) | With GitLab.com or Sentry instance |
|
||||
| [Sentry-based Error Tracking](sentry_error_tracking.md) | GitLab.com, GitLab Dedicated, GitLab Self-Managed | With [Sentry SDK](https://github.com/getsentry/sentry?tab=readme-ov-file#official-sentry-sdks) | On Sentry instance (Cloud Sentry.io or [self-hosted Sentry](https://develop.sentry.dev/self-hosted/)) | With GitLab.com or Sentry instance |
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ next to any feature flag in the list.
|
|||
|
||||
## Maximum number of feature flags
|
||||
|
||||
The maximum number of feature flags per project on GitLab Self-Managed instances
|
||||
The maximum number of feature flags per project on GitLab Self-Managed
|
||||
is 200. For GitLab SaaS, the maximum number is determined by [tier](https://about.gitlab.com/pricing/):
|
||||
|
||||
| Tier | Feature flags per project (SaaS) | Feature flags per project (self-managed) |
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ under [Configuring Git Protocol](../administration/git_protocol.md).
|
|||
|
||||
## Incoming Email
|
||||
|
||||
You can configure a GitLab self-managed instance to allow for incoming email to be
|
||||
You can configure GitLab Self-Managed to allow for incoming email to be
|
||||
used for commenting or creating issues and merge requests by registered users on
|
||||
the GitLab instance. In a hardened environment you should not configure
|
||||
this feature as it involves outside communications sending in information.
|
||||
|
|
|
|||
|
|
@ -13,6 +13,45 @@ DETAILS:
|
|||
This document lists tokens used in GitLab, their purpose and, where
|
||||
applicable, security guidance.
|
||||
|
||||
## Security considerations
|
||||
|
||||
To keep your tokens secure:
|
||||
|
||||
- Treat tokens like passwords and keep them secure.
|
||||
- When creating a scoped token, use the most limited scope possible to reduce the impact of an accidentally leaked token.
|
||||
- If separate processes require different scopes (for example, `read` and `write`), consider using separate tokens, one for each scope. If one token leaks, it gives reduced access than a single token with a wide scope like full API access.
|
||||
- When creating a token, consider setting a token that expires when your task is complete. For example, if you need to perform a one-time import, set the token to expire after a few hours.
|
||||
- If you set up a demo environment to showcase a project you have been working on, and you record a video or write a blog post describing that project, make sure you don't accidentally leak a secret.
|
||||
After the demo is finished, revoke all the secrets created during the demo.
|
||||
- Adding tokens to URLs can be a security risk. Instead, pass the token with a header like [`Private-Token`](../../api/rest/authentication.md#personalprojectgroup-access-tokens).
|
||||
- When cloning or adding a remote with a token in the URL, Git writes the URL to its `.git/config` file in plaintext.
|
||||
- URLs are often logged by proxies and application servers, which could leak those credentials to system administrators.
|
||||
- You can store tokens using [Git credential storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
|
||||
- Review all active access tokens of all types on a regular basis and revoke any you don't need.
|
||||
|
||||
Do not:
|
||||
|
||||
- Store tokens in plaintext in your projects. If the token is an external secret for GitLab CI/CD,
|
||||
review how to [use external secrets in CI/CD](../../ci/secrets/index.md) recommendations.
|
||||
- Include tokens when pasting code, console commands, or log outputs into an issue, MR description, comment, or any other free text inputs.
|
||||
- Log credentials in the console logs or artifacts. Consider [protecting](../../ci/variables/index.md#protect-a-cicd-variable) and
|
||||
[masking](../../ci/variables/index.md#mask-a-cicd-variable) your credentials.
|
||||
|
||||
### Tokens in CI/CD
|
||||
|
||||
Avoid using personal access tokens as CI/CD variables wherever possible due to their wide scope.
|
||||
If access to other resources is required from a CI/CD job, use one of the following, ordered by least to most access scope:
|
||||
|
||||
1. Job tokens (lowest access scope)
|
||||
1. Project tokens
|
||||
1. Group tokens
|
||||
|
||||
Additional recommendations for [CI/CD variable security](../../ci/variables/index.md#cicd-variable-security) include:
|
||||
|
||||
- Use [secrets storage](../../ci/pipelines/pipeline_security.md#secrets-storage) for any credentials.
|
||||
- CI/CD variable containing sensitive information should be [protected](../../ci/variables/index.md#protect-a-cicd-variable),
|
||||
[masked](../../ci/variables/index.md#mask-a-cicd-variable), and [hidden](../../ci/variables/index.md#hide-a-cicd-variable).
|
||||
|
||||
## Personal access tokens
|
||||
|
||||
You can create [personal access tokens](../../user/profile/personal_access_tokens.md)
|
||||
|
|
@ -32,6 +71,9 @@ You
|
|||
[receive an email](../../user/profile/personal_access_tokens.md#personal-access-token-expiry-emails)
|
||||
when your personal access tokens are expiring soon.
|
||||
|
||||
When considering a CI/CD job that requires tokens for permissions, avoid using personal access tokens, especially if stored as a CI/CD variable.
|
||||
CI/CD job tokens and project access tokens can often achieve the same result with much less risk.
|
||||
|
||||
## OAuth 2.0 tokens
|
||||
|
||||
GitLab can serve as an [OAuth 2.0 provider](../../api/oauth2.md) to
|
||||
|
|
@ -307,26 +349,3 @@ The following table shows the prefixes for each type of token.
|
|||
| GitLab session cookies | `_gitlab_session=` |
|
||||
| SCIM Tokens | `glsoat-` <br /> • ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/435096) in GitLab 16.8 behind a feature flag named `prefix_scim_tokens`. Disabled by default.) <br > • ([Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/435423) in GitLab 16.9. Feature flag `prefix_scim_tokens` removed.) |
|
||||
| Feature Flags Client token | `glffct-` |
|
||||
|
||||
## Security considerations
|
||||
|
||||
To keep your tokens secure:
|
||||
|
||||
- Treat access tokens like passwords and keep them secure.
|
||||
- When creating a scoped token, consider using the most limited scope possible to reduce the impact of accidentally leaking the token.
|
||||
- When creating a token, consider setting a token that expires when your task is complete. For example, if you need to perform a one-time import, set the token to expire after a few hours.
|
||||
- If you set up a demo environment to showcase a project you have been working on, and you record a video or write a blog post describing that project, make sure you don't accidentally leak a secret.
|
||||
After the demo is finished, revoke all the secrets created during the demo.
|
||||
- Adding access tokens to URLs is a security risk, especially when cloning or adding a remote, because Git writes URLs to its `.git/config` file in plaintext. URLs are
|
||||
also often logged by proxies and application servers, which leaks those credentials to system administrators. Instead, pass an access token to an API call with
|
||||
a header like [`Private-Token`](../../api/rest/authentication.md#personalprojectgroup-access-tokens).
|
||||
- You can store tokens using [Git credential storage](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage).
|
||||
- Review all active access tokens of all types on a regular basis and revoke any you don't need.
|
||||
|
||||
Do not:
|
||||
|
||||
- Store tokens in plaintext in your projects. If the token is an external secret for GitLab CI/CD,
|
||||
review how to [use external secrets in CI](../../ci/secrets/index.md) recommendations.
|
||||
- Include tokens when pasting code, console commands, or log outputs into an issue, MR description, or comment.
|
||||
- Log credentials in the console logs or artifacts. Consider [protecting](../../ci/variables/index.md#protect-a-cicd-variable)
|
||||
and [masking](../../ci/variables/index.md#mask-a-cicd-variable) your credentials.
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ While GitLab can be deployed on a single box for up to 500 users, when it is hor
|
|||
- GitLab Instance Scaled on AWS EC2 and PaaS. `[GitLab Built]`
|
||||
- [Using GitLab Environment Toolkit (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) - `[GitLab Solution]`
|
||||
|
||||
- [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/gitlab-AMG-datasource.html) for GitLab self-managed Prometheus metrics. `[AWS Built]`
|
||||
- [Amazon Managed Grafana](https://docs.aws.amazon.com/grafana/latest/userguide/gitlab-AMG-datasource.html) for GitLab Self-Managed Prometheus metrics. `[AWS Built]`
|
||||
|
||||
### GitLab Runner on AWS Compute
|
||||
|
||||
|
|
|
|||
|
|
@ -17,16 +17,16 @@ Choose which GitLab offering suits your needs:
|
|||
You don't need to install anything to use GitLab.com, you only need to
|
||||
[sign up](https://gitlab.com/users/sign_up) and start using GitLab straight away.
|
||||
- [GitLab Dedicated](gitlab_dedicated/index.md): A single-tenant SaaS service for highly regulated and large enterprises.
|
||||
- GitLab self-managed: Install, administer, and maintain your own GitLab instance.
|
||||
- GitLab Self-Managed: Install, administer, and maintain your own GitLab instance.
|
||||
|
||||
On a GitLab self-managed instance, a GitLab subscription provides the same set of
|
||||
On GitLab Self-Managed, a GitLab subscription provides the same set of
|
||||
features for all users.
|
||||
|
||||
On GitLab.com, you can apply a subscription to a top-level group
|
||||
namespace. You cannot apply a subscription to a personal namespace.
|
||||
|
||||
NOTE:
|
||||
Subscriptions cannot be transferred between GitLab.com and GitLab self-managed.
|
||||
Subscriptions cannot be transferred between GitLab.com and GitLab Self-Managed.
|
||||
A new subscription must be purchased and applied as needed.
|
||||
|
||||
## Choose a subscription tier
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ To change the GitLab.com account linked to your Customers Portal profile:
|
|||
If you purchased a subscription through an authorized reseller (including GCP and AWS marketplaces), you have access to the Customers Portal to:
|
||||
|
||||
- View your subscription.
|
||||
- Associate your subscription with the relevant group (GitLab SaaS) or download the license (GitLab self-managed).
|
||||
- Associate your subscription with the relevant group (GitLab.com) or download the license (GitLab Self-Managed).
|
||||
- Manage contact information.
|
||||
|
||||
Other changes and requests must be done through the reseller, including:
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ DETAILS:
|
|||
**Tier:** Premium, Ultimate
|
||||
**Offering:** GitLab.com, GitLab Self-Managed
|
||||
|
||||
When you purchase or use subscriptions for GitLab.com or GitLab self-managed, you might encounter the following issues.
|
||||
When you purchase or use subscriptions for GitLab.com or GitLab Self-Managed, you might encounter the following issues.
|
||||
|
||||
## Credit card declined
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ Ensure that you have the Owner role for that namespace, and review the [transfer
|
|||
|
||||
## Subscription data fails to synchronize
|
||||
|
||||
On GitLab self-managed, your subscription data might fail to synchronize.
|
||||
On GitLab Self-Managed, your subscription data might fail to synchronize.
|
||||
This issue can occur when network traffic between your GitLab instance and certain
|
||||
IP addresses is not allowed.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,6 @@ Choose and manage the subscription that's right for you and your organization.
|
|||
|
||||
| | | |
|
||||
|--|--|--|
|
||||
| [**GitLab plans**](choosing_subscription.md)<br>Options for GitLab plans. | [**GitLab.com subscription**](gitlab_com/index.md)<br>Seat usage, compute minutes, storage limits, renewal information. | [**GitLab self-managed subscription**](self_managed/index.md)<br>Billable users, renewal and upgrade information. |
|
||||
| [**GitLab plans**](choosing_subscription.md)<br>Options for GitLab plans. | [**GitLab.com subscription**](gitlab_com/index.md)<br>Seat usage, compute minutes, storage limits, renewal information. | [**GitLab Self-Managed subscription**](self_managed/index.md)<br>Billable users, renewal and upgrade information. |
|
||||
| [**GitLab Dedicated**](gitlab_dedicated/index.md)<br>Available features and benefits. | [**GitLab Duo add-ons**](subscription-add-ons.md)<br> Seat assignment, GitLab Duo Pro, Duo Enterprise. | [**Community programs**](community_programs.md)<br>Education, Open Source, Startups. |
|
||||
| [**The Customers Portal**](customers_portal.md)<br>Payment and company details. | [**Quarterly reconciliation and annual true-ups**](quarterly_reconciliation.md)<br>Billing examples. | [**Compute quota**](../ci/pipelines/compute_minutes.md)<br>Calculations, quotas, purchase information. |
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ The date you're notified about the overage is not the same as the date you are b
|
|||
and expected invoice amount is sent:
|
||||
|
||||
- On GitLab.com: On the reconciliation date, to group owners.
|
||||
- On GitLab self-managed: Six days after the reconciliation date, to administrators.
|
||||
- On GitLab Self-Managed: Six days after the reconciliation date, to administrators.
|
||||
|
||||
1. Seven days after the email notification, the subscription is updated to include the additional seats,
|
||||
and an invoice is generated for a prorated amount.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: Billable users, renewal and upgrade info.
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# GitLab self-managed subscription
|
||||
# GitLab Self-Managed subscription
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Premium, Ultimate
|
||||
|
|
@ -16,25 +16,25 @@ If you experience any issues, see the [troubleshooting page](../gitlab_com/gitla
|
|||
|
||||
## Obtain a self-managed subscription
|
||||
|
||||
To subscribe to GitLab for a GitLab self-managed installation:
|
||||
To subscribe to GitLab for a GitLab Self-Managed instance:
|
||||
|
||||
1. Go to the [Pricing page](https://about.gitlab.com/pricing/) and select a self-managed plan. You are redirected to the [Customers Portal](https://customers.gitlab.com/) to complete your purchase.
|
||||
1. After purchase, an activation code is sent to the email address associated with the Customers Portal account.
|
||||
You must [add this code to your GitLab instance](../../administration/license.md).
|
||||
|
||||
NOTE:
|
||||
If you're purchasing a subscription for an existing **Free** GitLab self-managed
|
||||
If you're purchasing a subscription for an existing **Free** GitLab Self-Managed
|
||||
instance, ensure you're purchasing enough seats to
|
||||
[cover your users](../../administration/admin_area.md#administering-users).
|
||||
|
||||
## How GitLab bills for users
|
||||
|
||||
A GitLab self-managed subscription uses a hybrid model. You pay for a subscription
|
||||
A GitLab Self-Managed subscription uses a hybrid model. You pay for a subscription
|
||||
according to the [maximum number](#maximum-users) of users enabled during the
|
||||
subscription period.
|
||||
|
||||
For instances that are not offline or on a closed network, the maximum number of
|
||||
simultaneous users in the GitLab self-managed installation is checked each quarter.
|
||||
simultaneous users in the GitLab Self-Managed instance is checked each quarter.
|
||||
|
||||
If an instance is unable to generate a quarterly usage report, the existing
|
||||
[true up model](#users-over-subscription) is used. Prorated charges are not
|
||||
|
|
|
|||
|
|
@ -266,7 +266,7 @@ Prerequisites:
|
|||
1. Select **Activate my trial**.
|
||||
1. [Assign seats](#assign-gitlab-duo-seats) to the users who need access.
|
||||
|
||||
### On GitLab self-managed and GitLab Dedicated
|
||||
### On GitLab Self-Managed and GitLab Dedicated
|
||||
|
||||
Prerequisites:
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ In this tutorial, we'll show you how to create, configure, instrument, and monit
|
|||
|
||||
To follow along this tutorial, you should have:
|
||||
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab self-managed
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab Self-Managed
|
||||
- A local installation of Python 3 and Django (You can install it with `python -m pip install Django`.)
|
||||
- Basic knowledge of Git and Python
|
||||
- Basic knowledge of the core concepts of [OpenTelemetry](https://opentelemetry.io/)
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ In this tutorial, you'll learn how to create, configure, instrument, and monitor
|
|||
|
||||
To follow along this tutorial, you must have:
|
||||
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab self-managed
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab Self-Managed
|
||||
- A local installation of [.NET](https://dotnet.microsoft.com/en-us/)
|
||||
- Basic knowledge of Git, .NET, and the core concepts of [OpenTelemetry](https://opentelemetry.io/)
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ In this tutorial, you'll learn how to create, configure, instrument, and monitor
|
|||
|
||||
To follow along this tutorial, you must have:
|
||||
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab self-managed
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab Self-Managed
|
||||
- A local installation of Ruby on Rails
|
||||
- Basic knowledge of Git, Java Spring, and the core concepts of [OpenTelemetry](https://opentelemetry.io/)
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ In this tutorial, you'll learn how to configure, instrument, and monitor a NodeJ
|
|||
|
||||
Take a moment and make sure you have the following:
|
||||
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab self-managed
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab Self-Managed
|
||||
- A local installation of NodeJS
|
||||
- Basic knowledge of Git, NodeJS, JavaScript, and the core concepts of [OpenTelemetry](https://opentelemetry.io/)
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ In this tutorial, you'll learn how to create, configure, instrument, and monitor
|
|||
|
||||
Take a moment and make sure you have the following:
|
||||
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab self-managed
|
||||
- A GitLab Ultimate subscription for GitLab.com or GitLab Self-Managed
|
||||
- A local installation of Ruby on Rails
|
||||
- Basic knowledge of Git, Ruby on Rails, and the core concepts of [OpenTelemetry](https://opentelemetry.io/)
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Read below for detailed information about the two types of migrations.
|
|||
## Database background migrations
|
||||
|
||||
> - Feature [flag](../user/feature_flags.md) `execute_batched_migrations_on_schedule` [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/329511) in GitLab 13.12.
|
||||
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](../development/database/batched_background_migrations.md#enable-or-disable-background-migrations).
|
||||
> - For GitLab Self-Managed, administrators can opt to [disable it](../development/database/batched_background_migrations.md#enable-or-disable-background-migrations).
|
||||
|
||||
Certain releases may require different migrations to be finished before you
|
||||
update to the newer version. Two kinds of migrations exist. They differ, and you
|
||||
|
|
|
|||
|
|
@ -528,7 +528,7 @@ and maintain them as needed.
|
|||
|
||||
As an alternative we recommend using the new OpenTofu CI/CD component on GitLab.com
|
||||
or the new OpenTofu CI/CD template on self-managed.
|
||||
CI/CD components are not yet available on GitLab self-managed,
|
||||
CI/CD components are not yet available on GitLab Self-Managed,
|
||||
but [Issue #415638](https://gitlab.com/gitlab-org/gitlab/-/issues/415638)
|
||||
proposes to add this feature. If CI/CD components become available on self-managed,
|
||||
the OpenTofu CI/CD template will be removed.
|
||||
|
|
@ -4419,7 +4419,7 @@ GitLab administrators can no longer perform actions on protected branches or tag
|
|||
|
||||
</div>
|
||||
|
||||
GitLab self-monitoring gives administrators of GitLab self-managed instances the tools to monitor the health of their instances. This feature is deprecated in GitLab 14.9, and is scheduled for removal in 16.0.
|
||||
GitLab self-monitoring gives instance administrators the tools to monitor the health of their instances. This feature is deprecated in GitLab 14.9, and is scheduled for removal in 16.0.
|
||||
|
||||
</div>
|
||||
|
||||
|
|
@ -4697,12 +4697,12 @@ However, since certificate-based integration with Kubernetes clusters is depreca
|
|||
Whether your existing project access tokens have expiry dates automatically applied depends on what GitLab offering you have, and when you upgraded to GitLab 16.0 or later:
|
||||
|
||||
- On GitLab.com, during the 16.0 milestone, existing project access tokens without an expiry date were automatically given an expiry date of 365 days later than the current date.
|
||||
- On GitLab self-managed, if you upgraded from GitLab 15.11 or earlier to GitLab 16.0 or later:
|
||||
- On GitLab Self-Managed, if you upgraded from GitLab 15.11 or earlier to GitLab 16.0 or later:
|
||||
- On or before July 23, 2024, existing project access tokens without an expiry date were automatically given an expiry date of 365 days later than the current date.
|
||||
This change is a breaking change.
|
||||
- On or after July 24, 2024, existing project access tokens without an expiry date did not have an expiry date set.
|
||||
|
||||
On GitLab self-managed, if you do a new install of one of the following GitLab versions, your existing project access tokens do not have expiry dates automatically applied:
|
||||
On GitLab Self-Managed, if you do a new install of one of the following GitLab versions, your existing project access tokens do not have expiry dates automatically applied:
|
||||
|
||||
- 16.0.9
|
||||
- 16.1.7
|
||||
|
|
@ -4733,7 +4733,7 @@ We recommend giving your access tokens an expiration date in line with your comp
|
|||
default is applied:
|
||||
|
||||
- On GitLab.com during the 16.0 milestone.
|
||||
- On GitLab self-managed instances when they are upgraded to 16.0.
|
||||
- On GitLab Self-Managed when they are upgraded to 16.0.
|
||||
|
||||
</div>
|
||||
|
||||
|
|
@ -5471,7 +5471,7 @@ For more information about the blockers to removal, see [this issue](https://git
|
|||
|
||||
For updates and details about this deprecation, follow [this epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8).
|
||||
|
||||
GitLab self-managed customers can still use the feature [with a feature flag](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).
|
||||
GitLab Self-Managed customers can still use the feature [with a feature flag](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes).
|
||||
|
||||
</div>
|
||||
|
||||
|
|
@ -7227,7 +7227,7 @@ This change is part of regular maintenance to keep our codebase clean.
|
|||
|
||||
</div>
|
||||
|
||||
In GitLab 14.4, GitLab released an integrated error tracking backend that replaces Sentry. This feature caused database performance issues. In GitLab 14.9, integrated error tracking is removed from GitLab.com, and turned off by default in GitLab self-managed. While we explore the future development of this feature, please consider switching to the Sentry backend by [changing your error tracking to Sentry in your project settings](https://docs.gitlab.com/ee/operations/error_tracking.html#sentry-error-tracking).
|
||||
In GitLab 14.4, GitLab released an integrated error tracking backend that replaces Sentry. This feature caused database performance issues. In GitLab 14.9, integrated error tracking is removed from GitLab.com, and turned off by default in GitLab Self-Managed. While we explore the future development of this feature, please consider switching to the Sentry backend by [changing your error tracking to Sentry in your project settings](https://docs.gitlab.com/ee/operations/error_tracking.html#sentry-error-tracking).
|
||||
|
||||
For additional background on this removal, please reference [Disable Integrated Error Tracking by Default](https://gitlab.com/groups/gitlab-org/-/epics/7580). If you have feedback please add a comment to [Feedback: Removal of Integrated Error Tracking](https://gitlab.com/gitlab-org/gitlab/-/issues/355493).
|
||||
|
||||
|
|
|
|||
|
|
@ -4,23 +4,21 @@ group: Distribution
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Universal update guide for patch versions for self-compiled installations
|
||||
# Update self-compiled installations with patch versions
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed
|
||||
|
||||
## Select Version to Install
|
||||
Update self-compiled installations with patch versions.
|
||||
|
||||
Make sure you view [this update guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/update/patch_versions.md) from the tag (version) of GitLab you would like to install.
|
||||
In most cases this should be the highest numbered production tag (without `rc` in it).
|
||||
You can select the tag in the version dropdown list in the upper-left corner of GitLab.
|
||||
Prerequisites:
|
||||
|
||||
### 0. Backup
|
||||
- A [back up](../administration/backup_restore/index.md) of your self-compiled installation.
|
||||
|
||||
Make a backup just in case things go south. Depending on the installation method, backup commands vary. See the [backing up and restoring GitLab](../administration/backup_restore/index.md) documentation.
|
||||
## Stop GitLab server
|
||||
|
||||
### 1. Stop server
|
||||
To stop the GitLab server:
|
||||
|
||||
```shell
|
||||
# For systems running systemd
|
||||
|
|
@ -30,22 +28,36 @@ sudo systemctl stop gitlab.target
|
|||
sudo service gitlab stop
|
||||
```
|
||||
|
||||
### 2. Get latest code for the stable branch
|
||||
## Get latest code for the stable branch
|
||||
|
||||
In the commands below, replace `LATEST_TAG` with the latest GitLab tag you want
|
||||
to update to, for example `v8.0.3`. Use `git tag -l 'v*.[0-9]' --sort='v:refname'`
|
||||
to see a list of all tags. Make sure to update patch versions only (check your
|
||||
current version with `cat VERSION`).
|
||||
In the following commands, replace `LATEST_TAG` with the GitLab tag to update to. For example, `v8.0.3`.
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
1. Check your current version:
|
||||
|
||||
sudo -u git -H git fetch --all
|
||||
sudo -u git -H git checkout -- Gemfile.lock db/structure.sql locale
|
||||
sudo -u git -H git checkout LATEST_TAG -b LATEST_TAG
|
||||
```
|
||||
```shell
|
||||
cat VERSION
|
||||
```
|
||||
|
||||
### 3. Install libraries, migrations, etc
|
||||
1. Get a list of all available tags:
|
||||
|
||||
```shell
|
||||
git tag -l 'v*.[0-9]' --sort='v:refname'
|
||||
```
|
||||
|
||||
1. Choose a patch version for your current major and minor version.
|
||||
1. Check out the code for the patch version to use:
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
|
||||
sudo -u git -H git fetch --all
|
||||
sudo -u git -H git checkout -- Gemfile.lock db/structure.sql locale
|
||||
sudo -u git -H git checkout LATEST_TAG -b LATEST_TAG
|
||||
```
|
||||
|
||||
## Install libraries and run migrations
|
||||
|
||||
To install libraries and run migrations, run the following commands:
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
|
|
@ -67,7 +79,9 @@ sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
|
|||
sudo -u git -H bundle exec rake yarn:install gitlab:assets:clean gitlab:assets:compile cache:clear RAILS_ENV=production NODE_ENV=production NODE_OPTIONS="--max_old_space_size=4096"
|
||||
```
|
||||
|
||||
### 4. Update GitLab Workhorse to the corresponding version
|
||||
## Update GitLab Workhorse to the new patch version
|
||||
|
||||
To update GitLab Workhorse to the new patch version:
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
|
|
@ -75,7 +89,9 @@ cd /home/git/gitlab
|
|||
sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production
|
||||
```
|
||||
|
||||
### 5. Update Gitaly to the corresponding version
|
||||
## Update Gitaly to the new patch version
|
||||
|
||||
To update Gitaly to the new patch version:
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
|
|
@ -83,7 +99,9 @@ cd /home/git/gitlab
|
|||
sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,/home/git/repositories]" RAILS_ENV=production
|
||||
```
|
||||
|
||||
### 6. Update GitLab Shell to the corresponding version
|
||||
## Update GitLab Shell to the new patch version
|
||||
|
||||
To update GitLab Shell to the new patch version:
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab-shell
|
||||
|
|
@ -93,7 +111,9 @@ sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_SHELL_VERSION) -b v$(</h
|
|||
sudo -u git -H make build
|
||||
```
|
||||
|
||||
### 7. Update GitLab Pages to the corresponding version (skip if not using pages)
|
||||
## Update GitLab Pages to the new patch version (if required)
|
||||
|
||||
If you're using GitLab Pages, update GitLab Pages to the new patch version:
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab-pages
|
||||
|
|
@ -103,15 +123,18 @@ sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_PAGES_VERSION)
|
|||
sudo -u git -H make
|
||||
```
|
||||
|
||||
### 8. Install/Update `gitlab-elasticsearch-indexer`
|
||||
## Install or update `gitlab-elasticsearch-indexer`
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Premium, Ultimate
|
||||
**Offering:** GitLab Self-Managed
|
||||
|
||||
Follow the [install instruction](../integration/advanced_search/elasticsearch.md#install-an-elasticsearch-or-aws-opensearch-cluster).
|
||||
To install or update `gitlab-elasticsearch-indexer`, follow the
|
||||
[installation instruction](../integration/advanced_search/elasticsearch.md#install-an-elasticsearch-or-aws-opensearch-cluster).
|
||||
|
||||
### 9. Start application
|
||||
## Start GitLab
|
||||
|
||||
To start GitLab, run the following commands:
|
||||
|
||||
```shell
|
||||
# For systems running systemd
|
||||
|
|
@ -123,9 +146,9 @@ sudo service gitlab start
|
|||
sudo service nginx restart
|
||||
```
|
||||
|
||||
### 10. Check application status
|
||||
## Check GitLab and its environment
|
||||
|
||||
Check if GitLab and its environment are configured correctly:
|
||||
To check if GitLab and its environment are configured correctly, run:
|
||||
|
||||
```shell
|
||||
cd /home/git/gitlab
|
||||
|
|
@ -141,7 +164,6 @@ sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
|
|||
|
||||
If all items are green, then congratulations upgrade complete!
|
||||
|
||||
### 11. Make sure background migrations are finished
|
||||
## Make sure background migrations are finished
|
||||
|
||||
[Check the status of background migrations](../update/background_migrations.md)
|
||||
and make sure they are finished.
|
||||
[Check the status of background migrations](../update/background_migrations.md) and make sure they are finished.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ DETAILS:
|
|||
|
||||
Creating an upgrade plan involves documenting:
|
||||
|
||||
- The steps to take to upgrade your GitLab self-managed instance.
|
||||
- The steps to take to upgrade your instance.
|
||||
- The steps to take if the upgrade doesn't go smoothly.
|
||||
|
||||
Your upgrade plan should include:
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ For more information about upgrading GitLab Helm Chart, see [the release notes f
|
|||
- [PostgreSQL 12 is not supported starting from GitLab 16](../../update/deprecations.md#postgresql-12-deprecated). Upgrade PostgreSQL to at least version 13.6 before upgrading to GitLab 16.0 or later.
|
||||
- If your GitLab instance upgraded first to 15.11.0, 15.11.1, or 15.11.2 the database schema is incorrect.
|
||||
Perform the [workaround](#undefined-column-error-upgrading-to-162-or-later) before upgrading to 16.x.
|
||||
- Starting with 16.0, GitLab self-managed installations now have two database connections by default, instead of one. This change doubles the number of PostgreSQL connections. It makes self-managed versions of GitLab behave similarly to GitLab.com, and is a step toward enabling a separate database for CI features for self-managed versions of GitLab. Before upgrading to 16.0, determine if you need to [increase max connections for PostgreSQL](https://docs.gitlab.com/omnibus/settings/database.html#configuring-multiple-database-connections).
|
||||
- Starting with 16.0, GitLab Self-Managed installations now have two database connections by default, instead of one. This change doubles the number of PostgreSQL connections. It makes self-managed versions of GitLab behave similarly to GitLab.com, and is a step toward enabling a separate database for CI features for self-managed versions of GitLab. Before upgrading to 16.0, determine if you need to [increase max connections for PostgreSQL](https://docs.gitlab.com/omnibus/settings/database.html#configuring-multiple-database-connections).
|
||||
- This change applies to installation methods with Linux packages (Omnibus), GitLab Helm chart, GitLab Operator, GitLab Docker images, and self-compiled installations.
|
||||
- [The second database connection can be disabled](#disable-the-second-database-connection).
|
||||
- Most installations can skip 16.0, 16.1, and 16.2, as the first required stop on the upgrade path is 16.3.
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ Continuous Vulnerability Scanning uses the Package Metadata Database, a service
|
|||
|
||||
On GitLab.com, the synchronization is managed by GitLab and is available to all projects.
|
||||
|
||||
On GitLab self-managed, you can [choose package registry metadata to synchronize](../../../administration/settings/security_and_compliance.md#choose-package-registry-metadata-to-sync) in the **Admin** area for the GitLab instance.
|
||||
On GitLab Self-Managed, you can [choose package registry metadata to synchronize](../../../administration/settings/security_and_compliance.md#choose-package-registry-metadata-to-sync) in the **Admin** area for the GitLab instance.
|
||||
|
||||
### Data sources
|
||||
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Prerequisites:
|
|||
- IaC scanning requires the AMD64 architecture. Microsoft Windows is not supported.
|
||||
- Minimum of 4 GB RAM to ensure consistent performance.
|
||||
- The `test` stage is required in the `.gitlab-ci.yml` file.
|
||||
- On GitLab self-managed you need GitLab Runner with the
|
||||
- On GitLab Self-Managed you need GitLab Runner with the
|
||||
[`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
|
||||
[`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
|
||||
- If you're using SaaS runners on GitLab.com, this is enabled by default.
|
||||
|
|
@ -190,7 +190,7 @@ DETAILS:
|
|||
**Offering:** GitLab Self-Managed
|
||||
|
||||
An offline environment has limited, restricted, or intermittent access to external resources through
|
||||
the internet. For GitLab Self-Managed instances in such an environment, IaC requires
|
||||
the internet. For instances in such an environment, IaC requires
|
||||
some configuration changes. The instructions in this section must be completed together with the
|
||||
instructions detailed in [offline environments](../offline_deployments/index.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -94,8 +94,8 @@ Policies enforced on an existing group or subgroup are automatically enforced in
|
|||
- The existing group or subgroup is already linked to the security policy project.
|
||||
|
||||
NOTE:
|
||||
GitLab SaaS users can enforce policies against their top-level group or across subgroups, but cannot
|
||||
enforce policies across GitLab SaaS top-level groups. GitLab self-managed users can enforce policies
|
||||
GitLab.com users can enforce policies against their top-level group or across subgroups, but cannot
|
||||
enforce policies across GitLab.com top-level groups. GitLab Self-Managed users can enforce policies
|
||||
across multiple top-level groups in their instance.
|
||||
|
||||
The following example illustrates two groups and their structure:
|
||||
|
|
@ -255,7 +255,7 @@ If you're not a group member, you may face limitations in adding or editing poli
|
|||
## Policy implementation
|
||||
|
||||
Implementation options for security policy projects differ slightly between GitLab.com, GitLab
|
||||
Dedicated, and GitLab self-managed. The main difference is that on GitLab.com it's only possible to
|
||||
Dedicated, and GitLab Self-Managed. The main difference is that on GitLab.com it's only possible to
|
||||
create subgroups. Ensuring separation of duties requires more granular permission configuration.
|
||||
|
||||
### Enforce policies globally in your GitLab.com namespace
|
||||
|
|
@ -304,7 +304,7 @@ The high-level workflow for enforcing policies globally across all subgroups and
|
|||
additional review or approval of policy changes, you can create an additional policy scoped only
|
||||
to your security policy project and enforce additional approvals.
|
||||
|
||||
### Enforce policies globally in GitLab Dedicated or your GitLab self-managed instance
|
||||
### Enforce policies globally in GitLab Dedicated or GitLab Self-Managed
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Ultimate
|
||||
|
|
|
|||
|
|
@ -510,7 +510,7 @@ DETAILS:
|
|||
**Tier:** Ultimate
|
||||
**Offering:** GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
On GitLab self-managed from 15.0 to 16.4, the most likely cause is that the project was exported from a group and imported into another, and had merge request approval policy rules. These rules are stored in a separate project to the one that was exported. As a result, the project contains policy rules that reference entities that don't exist in the imported project's group. The result is policy rules that are invalid, duplicated, or both.
|
||||
On GitLab Self-Managed from 15.0 to 16.4, the most likely cause is that the project was exported from a group and imported into another, and had merge request approval policy rules. These rules are stored in a separate project to the one that was exported. As a result, the project contains policy rules that reference entities that don't exist in the imported project's group. The result is policy rules that are invalid, duplicated, or both.
|
||||
|
||||
To remove all invalid merge request approval policy rules from a GitLab instance, an administrator can run the following script in the [Rails console](../../../administration/operations/rails_console.md).
|
||||
|
||||
|
|
@ -609,7 +609,7 @@ Support teams will investigate [logs](https://log.gprd.gitlab.net/) (`pubsub-sid
|
|||
}
|
||||
```
|
||||
|
||||
#### GitLab self-managed
|
||||
#### GitLab Self-Managed
|
||||
|
||||
Search for keywords such as the `project-path`, `api_fuzzing`, and `merge_request`. Example: `grep group-path/project-path`, and `grep merge_request`. If you know the correlation ID you can search by correlation ID. For example, if the value of `correlation_id` is 01HWN2NFABCEDFG, search for `01HWN2NFABCEDFG`.
|
||||
Search in the following files:
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ variables.
|
|||
|
||||
Like other GitLab SAST analyzers, the Advanced SAST analyzer requires a runner and a CI/CD pipeline; see [SAST requirements](index.md#requirements) for details.
|
||||
|
||||
On GitLab self-managed, you must also use a GitLab version that supports Advanced SAST:
|
||||
On GitLab Self-Managed, you must also use a GitLab version that supports Advanced SAST:
|
||||
|
||||
- You should use GitLab 17.4 or later if possible. GitLab 17.4 includes a new code-flow view, vulnerability deduplication, and further updates to the SAST CI/CD template.
|
||||
- The [SAST CI/CD templates](index.md#stable-vs-latest-sast-templates) were updated to include Advanced SAST in the following releases:
|
||||
|
|
@ -161,9 +161,9 @@ The code flow information is shown the **Code flow** tab and includes:
|
|||
### Code flow feature availability
|
||||
|
||||
The code flow view is integrated into each view where vulnerability details are shown.
|
||||
On GitLab self-managed, you can activate the view by [enabling the required feature flags](../../../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags) starting in the minimum version shown.
|
||||
On GitLab Self-Managed, you can activate the view by [enabling the required feature flags](../../../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags) starting in the minimum version shown.
|
||||
|
||||
| Location | Availability on GitLab.com | Availability on GitLab self-managed | Feature flags required |
|
||||
| Location | Availability on GitLab.com | Availability on GitLab Self-Managed | Feature flags required |
|
||||
|-------------------------------------------------------------------|-----------------------------------|-----------------------------------------------------------------------|---------------------------------------------------------------------|
|
||||
| [Vulnerability Report](../vulnerability_report/index.md) | Enabled by default in GitLab 17.3 | Enabled by default in GitLab 17.6. Available in GitLab 17.3 or later. | |
|
||||
| [Merge request widget](index.md#merge-request-widget) | Enabled by default in GitLab 17.6 | Enabled by default in GitLab 17.6. Available in GitLab 17.5 or later. | |
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ DETAILS:
|
|||
**Offering:** GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/368434) in GitLab 15.11.
|
||||
> - Detection of personal access tokens with a custom prefix was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/411146) in GitLab 16.1. GitLab self-managed only.
|
||||
> - Detection of personal access tokens with a custom prefix was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/411146) in GitLab 16.1. GitLab Self-Managed only.
|
||||
|
||||
When you create an issue, propose a merge request, or write a comment, you might accidentally post a
|
||||
secret. For example, you might paste in the details of an API request or an environment variable
|
||||
|
|
|
|||
|
|
@ -814,7 +814,7 @@ DETAILS:
|
|||
**Offering:** GitLab Self-Managed
|
||||
|
||||
An offline environment has limited, restricted, or intermittent access to external resources through
|
||||
the internet. For GitLab Self-Managed instances in such an environment, pipeline secret detection requires
|
||||
the internet. For instances in such an environment, pipeline secret detection requires
|
||||
some configuration changes. The instructions in this section must be completed together with the
|
||||
instructions detailed in [offline environments](../../offline_deployments/index.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -154,6 +154,17 @@ To apply the changes:
|
|||
gitlab-ctl restart gitlab-kas
|
||||
```
|
||||
|
||||
## Error: `Failed to register agent pod`
|
||||
|
||||
The agent pod logs might display the error message `Failed to register agent pod. Please make sure the agent version matches the server version`.
|
||||
|
||||
To resolve this issue, ensure that the agent version matches the GitLab version.
|
||||
|
||||
If the versions match and the error persists:
|
||||
|
||||
1. Make sure `gitlab-kas` is running with `gitlab-ctl status gitlab-kas`.
|
||||
1. Check the `gitlab-kas` [logs](../../../administration/logs/index.md#gitlab-agent-server) to make sure the agent is functioning properly.
|
||||
|
||||
## Failed to perform vulnerability scan on workload: jobs.batch already exists
|
||||
|
||||
```json
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ To comply with the SOC 2 standard, you must:
|
|||
[Prevent approvals by users who add commits](../../project/merge_requests/approvals/settings.md#prevent-approvals-by-users-who-add-commits).
|
||||
- At least one approval is required, see [Merge request approval rules](../../project/merge_requests/approvals/rules.md).
|
||||
|
||||
These settings are available for an entire GitLab Self-Managed instance. However, when these settings are updated at the instance level,
|
||||
These settings are available for an entire instance. However, when these settings are updated at the instance level,
|
||||
the adherence status for all the projects on the instance is not updated automatically. To update the adherence status
|
||||
for these projects, you must update the group-level or project-level setting. For more information on the instance-level settings, see:
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ To enable License scanning of CycloneDX files:
|
|||
- Using the Dependency Scanning template
|
||||
- Enable [Dependency Scanning](../../application_security/dependency_scanning/index.md#enabling-the-analyzer)
|
||||
and ensure that its prerequisites are met.
|
||||
- On GitLab self-managed only, you can [choose package registry metadata to synchronize](../../../administration/settings/security_and_compliance.md#choose-package-registry-metadata-to-sync) in the **Admin** area for the GitLab instance. For this data synchronization to work, you must allow outbound network traffic from your GitLab instance to the domain `storage.googleapis.com`. If you have limited or no network connectivity then refer to the documentation section [running in an offline environment](#running-in-an-offline-environment) for further guidance.
|
||||
- On GitLab Self-Managed, you can [choose package registry metadata to synchronize](../../../administration/settings/security_and_compliance.md#choose-package-registry-metadata-to-sync) in the **Admin** area for the GitLab instance. For this data synchronization to work, you must allow outbound network traffic from your GitLab instance to the domain `storage.googleapis.com`. If you have limited or no network connectivity then refer to the documentation section [running in an offline environment](#running-in-an-offline-environment) for further guidance.
|
||||
- Or use the [CI/CD component](../../../ci/components/index.md) for applicable package registries.
|
||||
|
||||
## Supported languages and package managers
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ DETAILS:
|
|||
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114524) in GitLab 15.10.
|
||||
> - Ability to create and remove a custom role with the UI [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/393235) in GitLab 16.4.
|
||||
> - Ability to use the UI to add a user to your group with a custom role, change a user's custom role, or remove a custom role from a group member [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/393239) in GitLab 16.7.
|
||||
> - Ability to create and remove an instance-wide custom role on GitLab self-managed [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141562) in GitLab 16.9.
|
||||
> - Ability to create and remove an instance-wide custom role on GitLab Self-Managed [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/141562) in GitLab 16.9.
|
||||
|
||||
Custom roles allow an organization to create user roles with the precise privileges and permissions required for that organization's needs.
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ In **Settings > Roles and permissions**, the list of all custom roles displays t
|
|||
- Base role that the custom role uses as a template.
|
||||
- Permissions.
|
||||
|
||||
### GitLab self-managed
|
||||
### GitLab Self-Managed
|
||||
|
||||
Prerequisites:
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ Prerequisites:
|
|||
1. Modify the role as needed.
|
||||
1. Select **Save role** to update the role.
|
||||
|
||||
### GitLab self-managed
|
||||
### GitLab Self-Managed
|
||||
|
||||
Prerequisites:
|
||||
|
||||
|
|
|
|||
|
|
@ -145,7 +145,7 @@ For larger teams, you should upgrade to the paid Premium or Ultimate tiers. Thes
|
|||
do not limit users and have more features to increase team productivity. For more
|
||||
information, see:
|
||||
|
||||
- [Upgrade your subscription tier on GitLab self-managed](../subscriptions/self_managed/index.md#upgrade-your-subscription-tier).
|
||||
- [Upgrade your subscription tier on GitLab Self-Managed](../subscriptions/self_managed/index.md#upgrade-your-subscription-tier).
|
||||
- [Upgrade your subscription tier on GitLab.com](../subscriptions/gitlab_com/index.md#upgrade-subscription-tier).
|
||||
|
||||
To try the paid tiers before deciding to upgrade, start a
|
||||
|
|
|
|||
|
|
@ -275,7 +275,7 @@ The [import sources](../project/import/index.md#supported-import-sources) that a
|
|||
which GitLab you use:
|
||||
|
||||
- GitLab.com: All available import sources are enabled by default.
|
||||
- GitLab self-managed: No import sources are enabled by default and must be
|
||||
- GitLab Self-Managed: No import sources are enabled by default and must be
|
||||
[enabled](../../administration/settings/import_and_export_settings.md#configure-allowed-import-sources).
|
||||
|
||||
## Import placeholder user limits
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Embed queries in Markdown code blocks.
|
|||
This feature is an [experiment](../../policy/development_stages_support.md).
|
||||
To test it:
|
||||
|
||||
- On GitLab self-managed, ask your administrator to enable the `glql_integration` feature flag on your instance.
|
||||
- On GitLab Self-Managed, ask your administrator to enable the `glql_integration` feature flag on your instance.
|
||||
- On GitLab.com, contact your account representative.
|
||||
|
||||
Share your feedback in [epic 14939](https://gitlab.com/groups/gitlab-org/-/epics/14939),
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ The selected time period applies to all charts and the table.
|
|||
## Contribution analytics with ClickHouse
|
||||
|
||||
On GitLab.com, contribution analytics run through the ClickHouse Cloud cluster.
|
||||
On GitLab self-managed, when you configure the ClickHouse integration, the ClickHouse `events` table is automatically populated from the PostgreSQL `events` table. This process might take some time for large installations. After the table is fully synchronized, new events become available in ClickHouse with a delay of about three minutes.
|
||||
On GitLab Self-Managed, when you configure the ClickHouse integration, the ClickHouse `events` table is automatically populated from the PostgreSQL `events` table. This process might take some time for large installations. After the table is fully synchronized, new events become available in ClickHouse with a delay of about three minutes.
|
||||
|
||||
For more information, see:
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ DETAILS:
|
|||
As a GitLab.com top-level group owner, you are responsible for the overall security of your groups and projects.
|
||||
To assist, GitLab provides an inventory of all the credentials that can be used to access your groups and projects.
|
||||
|
||||
This page describes how to manage the credentials inventory for GitLab.com. To manage credentials on GitLab self-managed, see [Credentials inventory for GitLab self-managed](../../administration/credentials_inventory.md).
|
||||
This page describes how to manage the credentials inventory for GitLab.com. To manage credentials on GitLab Self-Managed, see [Credentials inventory for GitLab Self-Managed](../../administration/credentials_inventory.md).
|
||||
|
||||
In the credentials inventory, you can view:
|
||||
|
||||
|
|
|
|||
|
|
@ -83,8 +83,8 @@ DETAILS:
|
|||
> - Removed from GitLab.com direct transfer migrations in GitLab 17.5 in favor of [the alternative](../../project/import/index.md#user-contribution-and-membership-mapping).
|
||||
|
||||
This method of user contribution and membership mapping is available for
|
||||
GitLab self-managed without enabled feature flags.
|
||||
For information on the other method available for GitLab self-managed
|
||||
GitLab Self-Managed without enabled feature flags.
|
||||
For information on the other method available for GitLab Self-Managed
|
||||
with enabled feature flags and for GitLab.com,
|
||||
see [user contribution and membership mapping](../../project/import/index.md#user-contribution-and-membership-mapping).
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue