Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
2f3007bc70
commit
03f56ec7f8
|
|
@ -71,7 +71,7 @@ export default {
|
|||
v-if="user.status.customized"
|
||||
ref="statusTooltipTarget"
|
||||
data-testid="user-menu-status"
|
||||
class="gl-display-flex gl-align-items-center gl-mt-2 gl-font-sm"
|
||||
class="gl-display-flex gl-align-items-baseline gl-mt-2 gl-font-sm"
|
||||
>
|
||||
<gl-emoji :data-name="user.status.emoji" class="gl-mr-1" />
|
||||
<span v-safe-html="user.status.message_html" class="gl-text-truncate"></span>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
import { mockGetProjectStorageStatisticsGraphQLResponse } from 'jest/usage_quotas/storage/mock_data';
|
||||
import createMockApollo from 'helpers/mock_apollo_helper';
|
||||
import getProjectStorageStatisticsQuery from '../queries/project_storage.query.graphql';
|
||||
import ProjectStorageApp from './project_storage_app.vue';
|
||||
|
||||
const meta = {
|
||||
title: 'usage_quotas/storage/project_storage_app',
|
||||
component: ProjectStorageApp,
|
||||
};
|
||||
|
||||
export default meta;
|
||||
|
||||
const createTemplate = (config = {}) => {
|
||||
let { provide, apolloProvider } = config;
|
||||
|
||||
if (provide == null) {
|
||||
provide = {};
|
||||
}
|
||||
|
||||
if (apolloProvider == null) {
|
||||
const requestHandlers = [
|
||||
[
|
||||
getProjectStorageStatisticsQuery,
|
||||
() => Promise.resolve(mockGetProjectStorageStatisticsGraphQLResponse),
|
||||
],
|
||||
];
|
||||
apolloProvider = createMockApollo(requestHandlers);
|
||||
}
|
||||
|
||||
return (args, { argTypes }) => ({
|
||||
components: { ProjectStorageApp },
|
||||
apolloProvider,
|
||||
provide: {
|
||||
projectPath: '/namespace/project',
|
||||
...provide,
|
||||
},
|
||||
props: Object.keys(argTypes),
|
||||
template: '<project-storage-app />',
|
||||
});
|
||||
};
|
||||
|
||||
export const Default = {
|
||||
render: createTemplate(),
|
||||
};
|
||||
|
||||
export const Loading = {
|
||||
render(...args) {
|
||||
const requestHandlers = [[getProjectStorageStatisticsQuery, () => new Promise(() => {})]];
|
||||
const apolloProvider = createMockApollo(requestHandlers);
|
||||
return createTemplate({
|
||||
apolloProvider,
|
||||
})(...args);
|
||||
},
|
||||
};
|
||||
|
||||
export const LoadingError = {
|
||||
render(...args) {
|
||||
const requestHandlers = [[getProjectStorageStatisticsQuery, () => Promise.reject()]];
|
||||
const apolloProvider = createMockApollo(requestHandlers);
|
||||
return createTemplate({
|
||||
apolloProvider,
|
||||
})(...args);
|
||||
},
|
||||
};
|
||||
|
|
@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/336070
|
|||
milestone: '13.8'
|
||||
type: development
|
||||
group: group::code review
|
||||
default_enabled: false
|
||||
default_enabled: true
|
||||
|
|
|
|||
|
|
@ -269,7 +269,7 @@ Today only Users, Projects, Namespaces and container images are considered routa
|
|||
Initially, Organization routes will be [unscoped](../../../development/routing.md).
|
||||
Organizations will follow the path `https://gitlab.com/-/organizations/org-name/` as one of the design goals is that the addition of Organizations should not change existing Group and Project paths.
|
||||
|
||||
## Impact of the Organization on Other Features
|
||||
## Impact of the Organization on Other Domains
|
||||
|
||||
We want a minimal amount of infrequently written tables in the shared database.
|
||||
If we have high write volume or large amounts of data in the shared database then this can become a single bottleneck for scaling and we lose the horizontal scalability objective of Cells.
|
||||
|
|
@ -289,11 +289,16 @@ Fulfillment is supportive of an entity above top-level groups. Their perspective
|
|||
- Ideally, a self-managed instance has a single Organization by default, which should be enough for most customers.
|
||||
- Fulfillment prefers only one additional entity.
|
||||
|
||||
### Open-source Contributions in Organizations
|
||||
|
||||
Several aspects of the current open-source workflow will be impacted by the introduction of Organizations.
|
||||
We are conducting deeper research around this specific problem in [issue 420804](https://gitlab.com/gitlab-org/gitlab/-/issues/420804).
|
||||
|
||||
## Iteration Plan
|
||||
|
||||
The following iteration plan outlines how we intend to arrive at the Organization MVC. We are following the guidelines for [Experiment, Beta, and Generally Available features](../../../policy/experiment-beta-support.md).
|
||||
|
||||
### Iteration 1: Organization Prototype (FY24Q3)
|
||||
### Iteration 1: Organization Prototype (FY24Q4)
|
||||
|
||||
In iteration 1, we introduce the concept of an Organization as a way to group top-level Groups together. Support for Organizations does not require any [Cells](../cells/index.md) work, but having them will make all subsequent iterations of Cells simpler. The goal of iteration 1 will be to generate a prototype that can be used by GitLab teams to test basic functionality within an Organization. The prototype contains the following functionality:
|
||||
|
||||
|
|
@ -308,7 +313,7 @@ In iteration 1, we introduce the concept of an Organization as a way to group to
|
|||
- Users can navigate between the different Organizations they are part of.
|
||||
- Any User within or outside of an Organization can be invited to Groups and Projects contained by the Organization.
|
||||
|
||||
### Iteration 2: Organization MVC Experiment (FY24Q4)
|
||||
### Iteration 2: Organization MVC Experiment (FY25Q1)
|
||||
|
||||
In iteration 2, an Organization MVC Experiment will be released. We will test the functionality with a select set of customers and improve the MVC based on these learnings. The MVC Experiment contains the following functionality:
|
||||
|
||||
|
|
@ -317,7 +322,7 @@ In iteration 2, an Organization MVC Experiment will be released. We will test th
|
|||
- Organization Owners can access the Activity page for the Organization.
|
||||
- Forking across Organizations will be defined.
|
||||
|
||||
### Iteration 3: Organization MVC Beta (FY24Q4)
|
||||
### Iteration 3: Organization MVC Beta (FY25Q1)
|
||||
|
||||
In iteration 3, the Organization MVC Beta will be released. Users will be able to transfer existing top-level Groups into an Organization.
|
||||
|
||||
|
|
@ -328,7 +333,7 @@ In iteration 3, the Organization MVC Beta will be released. Users will be able t
|
|||
- Top-level Groups can be transferred into an Organization.
|
||||
- The Organization URL path can be changed.
|
||||
|
||||
### Iteration 4: Organization MVC GA (FY25Q1)
|
||||
### Iteration 4: Organization MVC GA (FY25Q2)
|
||||
|
||||
In iteration 4, the Organization MVC will be rolled out.
|
||||
|
||||
|
|
@ -374,6 +379,24 @@ A force-option will only be considered if the we do not achieve the load distrib
|
|||
|
||||
An alternative approach to building Organizations is to convert top-level Groups into Organizations. The main advantage of this approach is that features could be built on top of the Namespace framework and therewith leverage functionality that is already available at the Group level. We would avoid building the same feature multiple times. However, Organizations have been identified as a critical driver of Cells. Due to the urgency of delivering Cells, we decided to opt for the quickest and most straightforward solution to deliver an Organization, which is the lightweight design described above. More details on comparing the two Organization proposals can be found [here](https://gitlab.com/gitlab-org/tenant-scale-group/group-tasks/-/issues/56).
|
||||
|
||||
## Frequently Asked Questions
|
||||
|
||||
### Do we expect large SaaS customers to be licensed at the Organization level, for example to have the ability to include multiple top-level Groups under on license?
|
||||
|
||||
Yes, this has been discussed with Fulfillment and is part of the post MVC roadmap for Organizations.
|
||||
See also [Alignment between Organization and Fulfillment](#alignment-between-organization-and-fulfillment).
|
||||
|
||||
### Do we expect to be able to configure alternate GitLab domain names for Organizations (such as `customer.gitlab.com`)?
|
||||
|
||||
There is no plan at this point to allow configuration of alternate GitLab domain names.
|
||||
We have previously heard that sub-domains bring administrative challenges.
|
||||
GitLab Dedicated will be a much better fit for that at this moment.
|
||||
|
||||
### Do we expect Organizations to have visibility settings (public/private) of their own? Will visibility remain a property of top-level Groups?
|
||||
|
||||
Organizations are public for now but will have their own independent visibility settings.
|
||||
See also [When can Users see an Organization?](#when-can-users-see-an-organization).
|
||||
|
||||
## Decision Log
|
||||
|
||||
- 2023-05-10: [Billing is not part of the Organization MVC](https://gitlab.com/gitlab-org/gitlab/-/issues/406614#note_1384055365)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,43 @@
|
|||
---
|
||||
stage: Verify
|
||||
group: Pipeline Authoring
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# CI/CD Catalog **(PREMIUM ALL EXPERIMENT)**
|
||||
|
||||
The CI/CD Catalog is a list of [components repositories](index.md#components-repository),
|
||||
each containing resources that you can add to your CI/CD pipelines.
|
||||
|
||||
## Mark the project as a catalog resource
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/407249) in GitLab 16.1.
|
||||
|
||||
After components are added to a components repository, they can immediately be [used](index.md#use-a-component-in-a-cicd-configuration) to build pipelines in other projects.
|
||||
|
||||
However, this repository is not discoverable. You must mark this project as a catalog resource to allow it to be visible in the CI Catalog
|
||||
so other users can discover it.
|
||||
|
||||
To mark a project as a catalog resource:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. On the left sidebar, select **Settings > General**.
|
||||
1. Expand **Visibility, project features, permissions**.
|
||||
1. Scroll down to **CI/CD Catalog resource** and select the toggle to mark the project as a catalog resource.
|
||||
|
||||
On the left sidebar, select **Search or go to** and find your project.
|
||||
|
||||
NOTE:
|
||||
This action is not reversible.
|
||||
|
||||
## Convert a CI template to component
|
||||
|
||||
Any existing CI template, that you share with other projects via `include:` syntax, can be converted to a CI component.
|
||||
|
||||
1. Decide whether you want the component to be part of an existing [components repository](index.md#components-repository),
|
||||
if you want to logically group components together. Create and setup a [components repository](index.md#components-repository) otherwise.
|
||||
1. Create a YAML file in the components repository according to the expected [directory structure](index.md#directory-structure).
|
||||
1. Copy the content of the template YAML file into the new component YAML file.
|
||||
1. Refactor the component YAML to follow the [best practices](index.md#best-practices) for components.
|
||||
1. Leverage the `.gitlab-ci.yml` in the components repository to [test changes to the component](index.md#test-a-component).
|
||||
1. Tag and [release the component](index.md#release-a-component).
|
||||
|
|
@ -2,14 +2,13 @@
|
|||
stage: Verify
|
||||
group: Pipeline Authoring
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
type: reference
|
||||
---
|
||||
|
||||
# CI/CD Components **(EXPERIMENT)**
|
||||
# CI/CD Components **(FREE ALL EXPERIMENT)**
|
||||
|
||||
> - Introduced as an [experimental feature](../../policy/experiment-beta-support.md) in GitLab 16.0, [with a flag](../../administration/feature_flags.md) named `ci_namespace_catalog_experimental`. Disabled by default.
|
||||
> - [Enabled on GitLab.com and self-managed](https://gitlab.com/groups/gitlab-org/-/epics/9897) in GitLab 16.2.
|
||||
> - [Feature flag `ci_namespace_catalog_experimental` removed.](https://gitlab.com/gitlab-org/gitlab/-/issues/394772) in GitLab 16.3.
|
||||
> - [Feature flag `ci_namespace_catalog_experimental` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/394772) in GitLab 16.3.
|
||||
|
||||
This feature is an experimental feature and [an epic exists](https://gitlab.com/groups/gitlab-org/-/epics/9897)
|
||||
to track future work. Tell us about your use case by leaving comments in the epic.
|
||||
|
|
@ -392,39 +391,3 @@ which is the standard for communicating bugfixes, minor and major or breaking ch
|
|||
We recommend adopting at least the `MAJOR.MINOR` format.
|
||||
|
||||
For example: `2.1`, `1.0.0`, `1.0.0-alpha`, `2.1.3`, `3.0.0-rc.1`.
|
||||
|
||||
## CI/CD Catalog **(PREMIUM ALL)**
|
||||
|
||||
The CI/CD Catalog is a list of [components repositories](#components-repository),
|
||||
each containing resources that you can add to your CI/CD pipelines.
|
||||
|
||||
### Mark the project as a catalog resource
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/407249) in GitLab 16.1.
|
||||
|
||||
After components are added to a components repository, they can immediately be [used](#use-a-component-in-a-cicd-configuration) to build pipelines in other projects.
|
||||
|
||||
However, this repository is not discoverable. You must mark this project as a catalog resource to allow it to be visible in the CI Catalog
|
||||
so other users can discover it.
|
||||
|
||||
To mark a project as a catalog resource:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. On the left sidebar, select **Settings > General**.
|
||||
1. Expand **Visibility, project features, permissions**.
|
||||
1. Scroll down to **CI/CD Catalog resource** and select the toggle to mark the project as a catalog resource.
|
||||
|
||||
NOTE:
|
||||
This action is not reversible.
|
||||
|
||||
## Convert a CI template to component
|
||||
|
||||
Any existing CI template, that you share with other projects via `include:` syntax, can be converted to a CI component.
|
||||
|
||||
1. Decide whether you want the component to be part of an existing [components repository](#components-repository),
|
||||
if you want to logically group components together. Create and setup a [components repository](#components-repository) otherwise.
|
||||
1. Create a YAML file in the components repository according to the expected [directory structure](#directory-structure).
|
||||
1. Copy the content of the template YAML file into the new component YAML file.
|
||||
1. Refactor the component YAML to follow the [best practices](#best-practices) for components.
|
||||
1. Leverage the `.gitlab-ci.yml` in the components repository to [test changes to the component](#test-a-component).
|
||||
1. Tag and [release the component](#release-a-component).
|
||||
|
|
|
|||
|
|
@ -52605,9 +52605,6 @@ msgstr ""
|
|||
msgid "Vulnerability|The unmodified response is the original response that had no mutations done to the request"
|
||||
msgstr ""
|
||||
|
||||
msgid "Vulnerability|There was an unexpected error. %{linkStart}Please try again%{linkEnd}."
|
||||
msgstr ""
|
||||
|
||||
msgid "Vulnerability|This is a beta feature that uses AI to explain the vulnerability and provide recommendations. Use this feature with caution as we continue to iterate. Please provide your feedback and ideas in %{linkStart}this issue%{linkEnd}."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
// Some modules read window.gon on initialization thus we need to define this object before anything else
|
||||
import './gon';
|
||||
import Vue from 'vue';
|
||||
import VueApollo from 'vue-apollo';
|
||||
import translateMixin from '~/vue_shared/translate';
|
||||
import { initializeGitLabAPIAccess } from './addons/gitlab_api_access/preview';
|
||||
|
||||
|
|
@ -13,6 +14,7 @@ const stylesheetsRequireCtx = require.context(
|
|||
initializeGitLabAPIAccess();
|
||||
|
||||
translateMixin(Vue);
|
||||
Vue.use(VueApollo);
|
||||
|
||||
stylesheetsRequireCtx('./application.scss');
|
||||
stylesheetsRequireCtx('./application_utilities.scss');
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ import (
|
|||
"github.com/stretchr/testify/require"
|
||||
"gitlab.com/gitlab-org/gitaly/v16/proto/go/gitalypb"
|
||||
"gitlab.com/gitlab-org/gitaly/v16/streamio"
|
||||
"google.golang.org/grpc/codes"
|
||||
"google.golang.org/grpc/status"
|
||||
|
||||
"gitlab.com/gitlab-org/gitlab/workhorse/internal/api"
|
||||
"gitlab.com/gitlab-org/gitlab/workhorse/internal/gitaly"
|
||||
|
|
@ -76,27 +78,24 @@ func realGitalyOkBody(t *testing.T, gitalyAddress string) *api.Response {
|
|||
}
|
||||
|
||||
func ensureGitalyRepository(t *testing.T, apiResponse *api.Response) error {
|
||||
ctx, namespace, err := gitaly.NewNamespaceClient(
|
||||
context.Background(),
|
||||
apiResponse.GitalyServer,
|
||||
)
|
||||
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
ctx, repository, err := gitaly.NewRepositoryClient(ctx, apiResponse.GitalyServer)
|
||||
ctx, repository, err := gitaly.NewRepositoryClient(context.Background(), apiResponse.GitalyServer)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
// Remove the repository if it already exists, for consistency
|
||||
rmNsReq := &gitalypb.RemoveNamespaceRequest{
|
||||
StorageName: apiResponse.Repository.StorageName,
|
||||
Name: apiResponse.Repository.RelativePath,
|
||||
}
|
||||
_, err = namespace.RemoveNamespace(ctx, rmNsReq)
|
||||
if err != nil {
|
||||
return err
|
||||
if _, err := repository.RepositoryServiceClient.RemoveRepository(ctx, &gitalypb.RemoveRepositoryRequest{
|
||||
Repository: &gitalypb.Repository{
|
||||
StorageName: apiResponse.Repository.StorageName,
|
||||
RelativePath: apiResponse.Repository.RelativePath,
|
||||
},
|
||||
}); err != nil {
|
||||
status, ok := status.FromError(err)
|
||||
if !ok || !(status.Code() == codes.NotFound && status.Message() == "repository does not exist") {
|
||||
return fmt.Errorf("remove repository: %w", err)
|
||||
}
|
||||
|
||||
// Repository didn't exist.
|
||||
}
|
||||
|
||||
stream, err := repository.CreateRepositoryFromBundle(ctx)
|
||||
|
|
|
|||
|
|
@ -114,16 +114,6 @@ func NewRepositoryClient(ctx context.Context, server api.GitalyServer) (context.
|
|||
return withOutgoingMetadata(ctx, server), &RepositoryClient{grpcClient}, nil
|
||||
}
|
||||
|
||||
// NewNamespaceClient is only used by the Gitaly integration tests at present
|
||||
func NewNamespaceClient(ctx context.Context, server api.GitalyServer) (context.Context, *NamespaceClient, error) {
|
||||
conn, err := getOrCreateConnection(server)
|
||||
if err != nil {
|
||||
return nil, nil, err
|
||||
}
|
||||
grpcClient := gitalypb.NewNamespaceServiceClient(conn)
|
||||
return withOutgoingMetadata(ctx, server), &NamespaceClient{grpcClient}, nil
|
||||
}
|
||||
|
||||
func NewDiffClient(ctx context.Context, server api.GitalyServer) (context.Context, *DiffClient, error) {
|
||||
conn, err := getOrCreateConnection(server)
|
||||
if err != nil {
|
||||
|
|
|
|||
|
|
@ -46,15 +46,6 @@ func TestNewRepositoryClient(t *testing.T) {
|
|||
testOutgoingMetadata(t, ctx)
|
||||
}
|
||||
|
||||
func TestNewNamespaceClient(t *testing.T) {
|
||||
ctx, _, err := NewNamespaceClient(
|
||||
context.Background(),
|
||||
serverFixture(),
|
||||
)
|
||||
require.NoError(t, err)
|
||||
testOutgoingMetadata(t, ctx)
|
||||
}
|
||||
|
||||
func TestNewDiffClient(t *testing.T) {
|
||||
ctx, _, err := NewDiffClient(
|
||||
context.Background(),
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
package gitaly
|
||||
|
||||
import "gitlab.com/gitlab-org/gitaly/v16/proto/go/gitalypb"
|
||||
|
||||
// NamespaceClient encapsulates NamespaceService calls
|
||||
type NamespaceClient struct {
|
||||
gitalypb.NamespaceServiceClient
|
||||
}
|
||||
Loading…
Reference in New Issue