Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
f1f255857d
commit
d588fa9e6e
|
|
@ -853,11 +853,9 @@
|
|||
when: never
|
||||
- <<: *if-fork-merge-request
|
||||
when: never
|
||||
- <<: *if-automated-merge-request
|
||||
changes: *code-backstage-patterns
|
||||
- <<: *if-default-refs
|
||||
- <<: *if-merge-request
|
||||
changes: *core-frontend-patterns
|
||||
- <<: *if-default-refs
|
||||
- <<: *if-merge-request
|
||||
changes: *code-backstage-patterns
|
||||
|
||||
.frontend:rules:eslint-as-if-foss:
|
||||
|
|
|
|||
2
Gemfile
2
Gemfile
|
|
@ -17,7 +17,7 @@ gem 'view_component', '~> 2.61'
|
|||
gem 'default_value_for', '~> 3.4.0'
|
||||
|
||||
# Supported DBs
|
||||
gem 'pg', '~> 1.3.0'
|
||||
gem 'pg', '~> 1.4.0'
|
||||
|
||||
gem 'rugged', '~> 1.2'
|
||||
gem 'grape-path-helpers', '~> 1.7.0'
|
||||
|
|
|
|||
|
|
@ -973,7 +973,7 @@ GEM
|
|||
tty-color (~> 0.5)
|
||||
peek (1.1.0)
|
||||
railties (>= 4.0.0)
|
||||
pg (1.3.5)
|
||||
pg (1.4.1)
|
||||
pg_query (2.1.3)
|
||||
google-protobuf (>= 3.19.2)
|
||||
plist (3.6.0)
|
||||
|
|
@ -1662,7 +1662,7 @@ DEPENDENCIES
|
|||
parallel (~> 1.19)
|
||||
parslet (~> 1.8)
|
||||
peek (~> 1.1)
|
||||
pg (~> 1.3.0)
|
||||
pg (~> 1.4.0)
|
||||
pg_query (~> 2.1.0)
|
||||
png_quantizator (~> 0.2.1)
|
||||
premailer-rails (~> 1.10.3)
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ import { GlAlert, GlSkeletonLoader, GlIntersectionObserver, GlLoadingIcon } from
|
|||
import { __ } from '~/locale';
|
||||
import createFlash from '~/flash';
|
||||
import JobsFilteredSearch from '../filtered_search/jobs_filtered_search.vue';
|
||||
import eventHub from './event_hub';
|
||||
import GetJobs from './graphql/queries/get_jobs.query.graphql';
|
||||
import JobsTable from './jobs_table.vue';
|
||||
import JobsTableEmptyState from './jobs_table_empty_state.vue';
|
||||
|
|
@ -108,16 +107,7 @@ export default {
|
|||
}
|
||||
},
|
||||
},
|
||||
mounted() {
|
||||
eventHub.$on('jobActionPerformed', this.handleJobAction);
|
||||
},
|
||||
beforeDestroy() {
|
||||
eventHub.$off('jobActionPerformed', this.handleJobAction);
|
||||
},
|
||||
methods: {
|
||||
handleJobAction() {
|
||||
this.$apollo.queries.jobs.refetch({ statuses: this.scope });
|
||||
},
|
||||
fetchJobsByStatus(scope) {
|
||||
this.infiniteScrollingTriggered = false;
|
||||
|
||||
|
|
@ -169,6 +159,7 @@ export default {
|
|||
v-if="shouldShowAlert"
|
||||
class="gl-mt-2"
|
||||
variant="danger"
|
||||
data-testid="jobs-table-error-alert"
|
||||
dismissible
|
||||
@dismiss="isAlertDismissed = true"
|
||||
>
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
- name: "Vulnerability Report sort by State" # (required) The name of the feature to be deprecated
|
||||
announcement_milestone: "15.0" # (required) The milestone when this feature was first announced as deprecated.
|
||||
announcement_date: "2022-05-22" # (required) The date of the milestone release when this feature was first announced as deprecated. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
|
||||
removal_milestone: "15.2" # (required) The milestone when this feature is planned to be removed
|
||||
removal_date: "2022-07-22" # (required) The date of the milestone release when this feature is planned to be removed. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
|
||||
removal_milestone: "15.3" # (required) The milestone when this feature is planned to be removed
|
||||
removal_date: "2022-08-22" # (required) The date of the milestone release when this feature is planned to be removed. This should almost always be the 22nd of a month (YYYY-MM-22), unless you did an out of band blog post.
|
||||
breaking_change: false # (required) If this deprecation is a breaking change, set this value to true
|
||||
reporter: matt_wilson # (required) GitLab username of the person reporting the deprecation
|
||||
stage: Secure # (required) String value of the stage that the feature was created in. e.g., Growth
|
||||
|
|
@ -10,8 +10,7 @@
|
|||
body: | # (required) Do not modify this line, instead modify the lines below.
|
||||
The ability to sort the Vulnerability Report by the `State` column was disabled and put behind a feature flag in GitLab 14.10 due to a refactor
|
||||
of the underlying data model. The feature flag has remained off by default as further refactoring will be required to ensure sorting
|
||||
by this value remains performant. Due to very low usage of the `State` column for sorting, the feature flag will instead be removed in
|
||||
GitLab 15.2 to simplify the codebase and prevent any unwanted performance degradation.
|
||||
by this value remains performant. Due to very low usage of the `State` column for sorting, the feature flag will instead be removed to simplify the codebase and prevent any unwanted performance degradation.
|
||||
# The following items are not published on the docs page, but may be used in the future.
|
||||
tiers: 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]
|
||||
documentation_url: # (optional) This is a link to the current documentation page
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ class CreateVulnerabilityReadsForAnExistingVulnerabilityRecord < Gitlab::Databas
|
|||
|
||||
def up
|
||||
execute(<<~SQL)
|
||||
CREATE FUNCTION #{FUNCTION_NAME}() RETURNS trigger
|
||||
CREATE OR REPLACE FUNCTION #{FUNCTION_NAME}() RETURNS trigger
|
||||
LANGUAGE plpgsql
|
||||
AS $$
|
||||
DECLARE
|
||||
|
|
@ -38,6 +38,10 @@ class CreateVulnerabilityReadsForAnExistingVulnerabilityRecord < Gitlab::Databas
|
|||
$$;
|
||||
SQL
|
||||
|
||||
execute(<<~SQL)
|
||||
DROP TRIGGER IF EXISTS #{TRIGGER_NAME} ON vulnerabilities;
|
||||
SQL
|
||||
|
||||
execute(<<~SQL)
|
||||
CREATE TRIGGER #{TRIGGER_NAME}
|
||||
AFTER UPDATE ON vulnerabilities
|
||||
|
|
|
|||
|
|
@ -47,6 +47,6 @@ you're ready to enable the Mailgun integration:
|
|||
1. On the left sidebar, go to **Settings > General** and expand the **Mailgun** section.
|
||||
1. Select the **Enable Mailgun** check box.
|
||||
1. Enter the Mailgun HTTP webhook signing key as described in
|
||||
[the Mailgun documentation](https://documentation.mailgun.com/en/latest/user_manual.html#webhooks) and
|
||||
[the Mailgun documentation](https://documentation.mailgun.com/en/latest/user_manual.html#webhooks-1) and
|
||||
shown in the [API security](https://app.mailgun.com/app/account/security/api_keys) section for your Mailgun account.
|
||||
1. Select **Save changes**.
|
||||
|
|
|
|||
|
|
@ -16,14 +16,14 @@ In Redis lingo, `primary` is called `master`. In this document, `primary` is use
|
|||
instead of `master`, except the settings where `master` is required.
|
||||
|
||||
Using [Redis](https://redis.io/) in scalable environment is possible using a **Primary** x **Replica**
|
||||
topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
|
||||
topology with a [Redis Sentinel](https://redis.io/docs/manual/sentinel/) service to watch and automatically
|
||||
start the failover procedure.
|
||||
|
||||
Redis requires authentication if used with Sentinel. See
|
||||
[Redis Security](https://redis.io/topics/security) documentation for more
|
||||
[Redis Security](https://redis.io/docs/manual/security/) documentation for more
|
||||
information. We recommend using a combination of a Redis password and tight
|
||||
firewall rules to secure your Redis service.
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/topics/sentinel) documentation
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation
|
||||
before configuring Redis with GitLab to fully understand the topology and
|
||||
architecture.
|
||||
|
||||
|
|
@ -67,7 +67,7 @@ When a **Primary** fails to respond, it's the application's responsibility
|
|||
for a new **Primary**).
|
||||
|
||||
To get a better understanding on how to correctly set up Sentinel, please read
|
||||
the [Redis Sentinel documentation](https://redis.io/topics/sentinel) first, as
|
||||
the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation first, as
|
||||
failing to configure it correctly can lead to data loss or can bring your
|
||||
whole cluster down, invalidating the failover effort.
|
||||
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ starting with `sentinel` prefix.
|
|||
Assuming that the Redis Sentinel is installed on the same instance as Redis
|
||||
primary with IP `10.0.0.1` (some settings might overlap with the primary):
|
||||
|
||||
1. [Install Redis Sentinel](https://redis.io/topics/sentinel).
|
||||
1. [Install Redis Sentinel](https://redis.io/docs/manual/sentinel/).
|
||||
1. Edit `/etc/redis/sentinel.conf`:
|
||||
|
||||
```conf
|
||||
|
|
|
|||
|
|
@ -167,4 +167,4 @@ production:
|
|||
port: 26379 # point to sentinel, not to redis port
|
||||
```
|
||||
|
||||
When in doubt, read the [Redis Sentinel documentation](https://redis.io/topics/sentinel).
|
||||
When in doubt, read the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation.
|
||||
|
|
|
|||
|
|
@ -800,14 +800,14 @@ The following IPs will be used as an example:
|
|||
## Configure Redis
|
||||
|
||||
Using [Redis](https://redis.io/) in scalable environment is possible using a **Primary** x **Replica**
|
||||
topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
|
||||
topology with a [Redis Sentinel](https://redis.io/docs/manual/sentinel/) service to watch and automatically
|
||||
start the failover procedure.
|
||||
|
||||
Redis requires authentication if used with Sentinel. See
|
||||
[Redis Security](https://redis.io/topics/security) documentation for more
|
||||
[Redis Security](https://redis.io/docs/manual/security/) documentation for more
|
||||
information. We recommend using a combination of a Redis password and tight
|
||||
firewall rules to secure your Redis service.
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/topics/sentinel) documentation
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation
|
||||
before configuring Redis with GitLab to fully understand the topology and
|
||||
architecture.
|
||||
|
||||
|
|
|
|||
|
|
@ -803,14 +803,14 @@ The following IPs will be used as an example:
|
|||
## Configure Redis
|
||||
|
||||
Using [Redis](https://redis.io/) in scalable environment is possible using a **Primary** x **Replica**
|
||||
topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
|
||||
topology with a [Redis Sentinel](https://redis.io/docs/manual/sentinel/) service to watch and automatically
|
||||
start the failover procedure.
|
||||
|
||||
Redis requires authentication if used with Sentinel. See
|
||||
[Redis Security](https://redis.io/topics/security) documentation for more
|
||||
[Redis Security](https://redis.io/docs/manual/security/) documentation for more
|
||||
information. We recommend using a combination of a Redis password and tight
|
||||
firewall rules to secure your Redis service.
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/topics/sentinel) documentation
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation
|
||||
before configuring Redis with GitLab to fully understand the topology and
|
||||
architecture.
|
||||
|
||||
|
|
|
|||
|
|
@ -425,14 +425,14 @@ all nodes.
|
|||
## Configure Redis
|
||||
|
||||
Using [Redis](https://redis.io/) in scalable environment is possible using a **Primary** x **Replica**
|
||||
topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
|
||||
topology with a [Redis Sentinel](https://redis.io/docs/manual/sentinel/) service to watch and automatically
|
||||
start the failover procedure.
|
||||
|
||||
Redis requires authentication if used with Sentinel. See
|
||||
[Redis Security](https://redis.io/topics/security) documentation for more
|
||||
[Redis Security](https://redis.io/docs/manual/security/) documentation for more
|
||||
information. We recommend using a combination of a Redis password and tight
|
||||
firewall rules to secure your Redis service.
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/topics/sentinel) documentation
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation
|
||||
before configuring Redis with GitLab to fully understand the topology and
|
||||
architecture.
|
||||
|
||||
|
|
|
|||
|
|
@ -810,14 +810,14 @@ The following IPs will be used as an example:
|
|||
## Configure Redis
|
||||
|
||||
Using [Redis](https://redis.io/) in scalable environment is possible using a **Primary** x **Replica**
|
||||
topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
|
||||
topology with a [Redis Sentinel](https://redis.io/docs/manual/sentinel/) service to watch and automatically
|
||||
start the failover procedure.
|
||||
|
||||
Redis requires authentication if used with Sentinel. See
|
||||
[Redis Security](https://redis.io/topics/security) documentation for more
|
||||
[Redis Security](https://redis.io/docs/manual/security/) documentation for more
|
||||
information. We recommend using a combination of a Redis password and tight
|
||||
firewall rules to secure your Redis service.
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/topics/sentinel) documentation
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation
|
||||
before configuring Redis with GitLab to fully understand the topology and
|
||||
architecture.
|
||||
|
||||
|
|
|
|||
|
|
@ -423,14 +423,14 @@ all nodes.
|
|||
## Configure Redis
|
||||
|
||||
Using [Redis](https://redis.io/) in scalable environment is possible using a **Primary** x **Replica**
|
||||
topology with a [Redis Sentinel](https://redis.io/topics/sentinel) service to watch and automatically
|
||||
topology with a [Redis Sentinel](https://redis.io/docs/manual/sentinel/) service to watch and automatically
|
||||
start the failover procedure.
|
||||
|
||||
Redis requires authentication if used with Sentinel. See
|
||||
[Redis Security](https://redis.io/topics/security) documentation for more
|
||||
[Redis Security](https://redis.io/docs/manual/security/) documentation for more
|
||||
information. We recommend using a combination of a Redis password and tight
|
||||
firewall rules to secure your Redis service.
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/topics/sentinel) documentation
|
||||
You are highly encouraged to read the [Redis Sentinel](https://redis.io/docs/manual/sentinel/) documentation
|
||||
before configuring Redis with GitLab to fully understand the topology and
|
||||
architecture.
|
||||
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ The following table details the cost to run the different reference architecture
|
|||
<td></td>
|
||||
<td><a href="https://calculator.aws/#/estimate?id=b51f178f4403b69a63f6eb33ea425f82de3bf249">Calculated cost</a></td>
|
||||
<td></td>
|
||||
<td><a href="https://azure.com/e/1adf30bef7e34ceba9efa97c4470417b">Calculated cost</a></td>
|
||||
<td><a href="https://azure.com/e/1adf30bef7e34ceba9efa97c4470417b/">Calculated cost</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">2k</th>
|
||||
|
|
@ -248,7 +248,7 @@ The following table details the cost to run the different reference architecture
|
|||
<td></td>
|
||||
<td><a href="https://calculator.aws/#/estimate?id=dce36b5cb6ab25211f74e47233d77f58fefb54e2">Calculated cost</a></td>
|
||||
<td></td>
|
||||
<td><a href="https://azure.com/e/72764902f3854f798407fb03c3de4b6f">Calculated cost</a></td>
|
||||
<td><a href="https://azure.com/e/72764902f3854f798407fb03c3de4b6f/">Calculated cost</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">3k</th>
|
||||
|
|
@ -256,7 +256,7 @@ The following table details the cost to run the different reference architecture
|
|||
<td></td>
|
||||
<td><a href="https://calculator.aws/#/estimate?id=b1c5b4e32e990eaeb035a148255132bd28988760">Calculated cost</a></td>
|
||||
<td></td>
|
||||
<td><a href="https://azure.com/e/0dbfc575051943b9970e5d8ace03680d">Calculated cost</a></td>
|
||||
<td><a href="https://azure.com/e/0dbfc575051943b9970e5d8ace03680d/">Calculated cost</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">5k</th>
|
||||
|
|
@ -264,7 +264,7 @@ The following table details the cost to run the different reference architecture
|
|||
<td></td>
|
||||
<td><a href="https://calculator.aws/#/estimate?id=2bf1af883096e6f4c6efddb4f3c35febead7fec2">Calculated cost</a></td>
|
||||
<td></td>
|
||||
<td><a href="https://azure.com/e/8f618711ffec4b039f1581871ca6a7c9">Calculated cost</a></td>
|
||||
<td><a href="https://azure.com/e/8f618711ffec4b039f1581871ca6a7c9/">Calculated cost</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">10k</th>
|
||||
|
|
@ -272,7 +272,7 @@ The following table details the cost to run the different reference architecture
|
|||
<td></td>
|
||||
<td><a href="https://calculator.aws/#/estimate?id=1d374df13c0f2088d332ab0134f5b1d0f717259e">Calculated cost</a></td>
|
||||
<td></td>
|
||||
<td><a href="https://azure.com/e/de3da8286dda4d4db1362932bc75410b">Calculated cost</a></td>
|
||||
<td><a href="https://azure.com/e/de3da8286dda4d4db1362932bc75410b/">Calculated cost</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">25k</th>
|
||||
|
|
@ -280,7 +280,7 @@ The following table details the cost to run the different reference architecture
|
|||
<td></td>
|
||||
<td><a href="https://calculator.aws/#/estimate?id=46fe6a6e9256d9b7779fae59fbbfa7e836942b7d">Calculated cost</a></td>
|
||||
<td></td>
|
||||
<td><a href="https://azure.com/e/69724ebd82914a60857da6a3ace05a64">Calculate cost</a></td>
|
||||
<td><a href="https://azure.com/e/69724ebd82914a60857da6a3ace05a64/">Calculate cost</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th scope="row">50k</th>
|
||||
|
|
@ -288,7 +288,7 @@ The following table details the cost to run the different reference architecture
|
|||
<td></td>
|
||||
<td><a href="https://calculator.aws/#/estimate?id=e15926b1a3c7139e4faf390a3875ff807d2ab91c">Calculated cost</a></td>
|
||||
<td></td>
|
||||
<td><a href="https://azure.com/e/3f973040ebc14023933d35f576c89846">Calculated cost</a></td>
|
||||
<td><a href="https://azure.com/e/3f973040ebc14023933d35f576c89846/">Calculated cost</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ having an issue with GitLab, you may want to check your [support options](https:
|
|||
first, before attempting to use this information.
|
||||
|
||||
WARNING:
|
||||
It is [beyond the scope of GitLab Support to assist in systems administration](https://about.gitlab.com/support/statement-of-support.html#training). GitLab administrators are expected to know these commands for their distribution
|
||||
It is [beyond the scope of GitLab Support to assist in systems administration](https://about.gitlab.com/support/statement-of-support/#training). GitLab administrators are expected to know these commands for their distribution
|
||||
of choice. If you are a GitLab Support Engineer, consider this a cross-reference to
|
||||
translate `yum` -> `apt-get` and the like.
|
||||
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@ epic.
|
|||
|
||||
The initial iteration will provide a framework to house features under `Namespaces`. Stage groups will eventually need to migrate their own features and functionality over to `Namespaces`. This may impact these features in unexpected ways. Therefore, to minimize UX debt and maintain product consistency, stage groups will have to consider a number of factors when migrating their features over to `Namespaces`:
|
||||
|
||||
1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [merge requests](https://design.gitlab.com/objects/merge-request)).
|
||||
1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [merge requests](https://design.gitlab.com/objects/merge-request/)).
|
||||
1. **Merge conflicts**: What inconsistencies are there across project, group, and administrator levels? How might these be addressed? For an example of how we rationalized this for labels, please see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338820).
|
||||
1. **Inheritance & information flow**: How is information inherited across our container hierarchy currently? How might this be impacted if complying with the new [inheritance behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/343316) framework?
|
||||
1. **Settings**: Where can settings for this feature be found currently? How will these be impacted by `Namespaces`?
|
||||
|
|
|
|||
|
|
@ -167,7 +167,7 @@ The [epic for `~group::database`](https://gitlab.com/groups/gitlab-org/-/epics/6
|
|||
|
||||
<!-- vale gitlab.Spelling = NO -->
|
||||
|
||||
Identifying solutions for offending tables is driven by the [GitLab Database Team](https://about.gitlab.com/handbook/engineering/development/enablement/database/) and respective stage groups.
|
||||
Identifying solutions for offending tables is driven by the [GitLab Database Team](https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/database/) and respective stage groups.
|
||||
|
||||
| Role | Who
|
||||
|------------------------------|-------------------------|
|
||||
|
|
|
|||
|
|
@ -127,7 +127,7 @@ An alternative approach we have discussed and abandoned is to "scrub" and anonym
|
|||
|
||||
<!-- vale gitlab.Spelling = NO -->
|
||||
|
||||
This effort is owned and driven by the [GitLab Database Team](https://about.gitlab.com/handbook/engineering/development/enablement/database/) with support from the [GitLab.com Reliability Datastores](https://about.gitlab.com/handbook/engineering/infrastructure/team/reliability/) team.
|
||||
This effort is owned and driven by the [GitLab Database Team](https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/database/) with support from the [GitLab.com Reliability Datastores](https://about.gitlab.com/handbook/engineering/infrastructure/team/reliability/) team.
|
||||
|
||||
| Role | Who
|
||||
|------------------------------|-------------------------|
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ inside the Workload Identity Pool created in the previous step, using the follow
|
|||
| `google.subject` | `assertion.sub` |
|
||||
| `attribute.X` | `assertion.X` |
|
||||
|
||||
You can also [build complex attributes](https://cloud.google.com/iam/help/workload-identity/attribute-mapping)
|
||||
You can also [build complex attributes](https://cloud.google.com/iam/docs/workload-identity-federation#mapping)
|
||||
using Common Expression Language (CEL).
|
||||
|
||||
You must map every attribute that you want to use for permission granting. For example, if you want to map permissions in the next step based on the user's email address, you must map `attribute.user_email` to `assertion.user_email`.
|
||||
|
|
|
|||
|
|
@ -133,7 +133,7 @@ To use Docker-in-Docker with TLS enabled:
|
|||
|
||||
- This command registers a new runner to use the `docker:20.10.16` image.
|
||||
To start the build and service containers, it uses the `privileged` mode.
|
||||
If you want to use [Docker-in-Docker](https://www.docker.com/blog/docker-can-now-run-within-docker/),
|
||||
If you want to use Docker-in-Docker,
|
||||
you must always use `privileged = true` in your Docker containers.
|
||||
- This command mounts `/certs/client` for the service and build
|
||||
container, which is needed for the Docker client to use the
|
||||
|
|
|
|||
|
|
@ -180,13 +180,13 @@ $ vault write auth/jwt/role/myproject-production - <<EOF
|
|||
EOF
|
||||
```
|
||||
|
||||
This example uses [bound_claims](https://www.vaultproject.io/api/auth/jwt#bound_claims) to specify that only a JWT with matching values for the specified claims is allowed to authenticate.
|
||||
This example uses [bound_claims](https://www.vaultproject.io/api-docs/auth/jwt#bound_claims) to specify that only a JWT with matching values for the specified claims is allowed to authenticate.
|
||||
|
||||
Combined with [protected branches](../../../user/project/protected_branches.md), you can restrict who is able to authenticate and read the secrets.
|
||||
|
||||
[`token_explicit_max_ttl`](https://www.vaultproject.io/api/auth/jwt#token_explicit_max_ttl) specifies that the token issued by Vault, upon successful authentication, has a hard lifetime limit of 60 seconds.
|
||||
[`token_explicit_max_ttl`](https://www.vaultproject.io/api-docs/auth/jwt#token_explicit_max_ttl) specifies that the token issued by Vault, upon successful authentication, has a hard lifetime limit of 60 seconds.
|
||||
|
||||
[`user_claim`](https://www.vaultproject.io/api/auth/jwt#user_claim) specifies the name for the Identity alias created by Vault upon a successful login.
|
||||
[`user_claim`](https://www.vaultproject.io/api-docs/auth/jwt#user_claim) specifies the name for the Identity alias created by Vault upon a successful login.
|
||||
|
||||
[`bound_claims_type`](https://www.vaultproject.io/api-docs/auth/jwt#bound_claims_type) configures the interpretation of the `bound_claims` values. If set to `glob`, the values are interpreted as globs, with `*` matching any number of characters.
|
||||
|
||||
|
|
@ -212,7 +212,7 @@ Role example to support the templated policy above, mapping the claim field `pro
|
|||
}
|
||||
```
|
||||
|
||||
For the full list of options, see Vault's [Create Role documentation](https://www.vaultproject.io/api/auth/jwt#create-role).
|
||||
For the full list of options, see Vault's [Create Role documentation](https://www.vaultproject.io/api-docs/auth/jwt#create-role).
|
||||
|
||||
WARNING:
|
||||
Always restrict your roles to project or namespace by using one of the provided claims (for example, `project_id` or `namespace_id`). Otherwise any JWT generated by this instance may be allowed to authenticate using this role.
|
||||
|
|
@ -225,9 +225,9 @@ $ vault write auth/jwt/config \
|
|||
bound_issuer="gitlab.example.com"
|
||||
```
|
||||
|
||||
[bound_issuer](https://www.vaultproject.io/api/auth/jwt#inlinecode-bound_issuer) specifies that only a JWT with the issuer (that is, the `iss` claim) set to `gitlab.example.com` can use this method to authenticate, and that the JWKS endpoint (`https://gitlab.example.com/-/jwks`) should be used to validate the token.
|
||||
[bound_issuer](https://www.vaultproject.io/api-docs/auth/jwt#bound_issuer) specifies that only a JWT with the issuer (that is, the `iss` claim) set to `gitlab.example.com` can use this method to authenticate, and that the JWKS endpoint (`https://gitlab.example.com/-/jwks`) should be used to validate the token.
|
||||
|
||||
For the full list of available configuration options, see Vault's [API documentation](https://www.vaultproject.io/api/auth/jwt#configure).
|
||||
For the full list of available configuration options, see Vault's [API documentation](https://www.vaultproject.io/api-docs/auth/jwt#configure).
|
||||
|
||||
The following job, when run for the default branch, is able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
|
||||
|
||||
|
|
@ -241,7 +241,7 @@ read_secrets:
|
|||
# Vault's address can be provided here or as CI/CD variable
|
||||
- export VAULT_ADDR=http://vault.example.com:8200
|
||||
# Authenticate and get token. Token expiry time and other properties can be configured
|
||||
# when configuring JWT Auth - https://www.vaultproject.io/api/auth/jwt#parameters-1
|
||||
# when configuring JWT Auth - https://www.vaultproject.io/api-docs/auth/jwt#parameters-1
|
||||
- export VAULT_TOKEN="$(vault write -field=token auth/jwt/login role=myproject-staging jwt=$CI_JOB_JWT)"
|
||||
# Now use the VAULT_TOKEN to read the secret and store it in an environment variable
|
||||
- export PASSWORD="$(vault kv get -field=password secret/myproject/staging/db)"
|
||||
|
|
@ -269,7 +269,7 @@ read_secrets:
|
|||
# Vault's address can be provided here or as CI/CD variable
|
||||
- export VAULT_ADDR=http://vault.example.com:8200
|
||||
# Authenticate and get token. Token expiry time and other properties can be configured
|
||||
# when configuring JWT Auth - https://www.vaultproject.io/api/auth/jwt#parameters-1
|
||||
# when configuring JWT Auth - https://www.vaultproject.io/api-docs/auth/jwt#parameters-1
|
||||
- export VAULT_TOKEN="$(vault write -field=token auth/jwt/login role=myproject-production jwt=$CI_JOB_JWT)"
|
||||
# Now use the VAULT_TOKEN to read the secret and store it in environment variable
|
||||
- export PASSWORD="$(vault kv get -field=password secret/myproject/production/db)"
|
||||
|
|
@ -288,7 +288,7 @@ and GitLab features. For example, restrict the token by:
|
|||
for specific groups using `group_claim`.
|
||||
- Hard coding values for Vault bound claims based on the `user_login` and `user_email`
|
||||
of specific users.
|
||||
- Setting Vault time limits for TTL of the token as specified in [`token_explicit_max_ttl`](https://www.vaultproject.io/api/auth/jwt#token_explicit_max_ttl),
|
||||
- Setting Vault time limits for TTL of the token as specified in [`token_explicit_max_ttl`](https://www.vaultproject.io/api-docs/auth/jwt#token_explicit_max_ttl),
|
||||
where the token expires after authentication.
|
||||
- Scoping the JWT to [GitLab projected branches](../../../user/project/protected_branches.md)
|
||||
that are restricted to a subset of project users.
|
||||
|
|
|
|||
|
|
@ -265,7 +265,7 @@ test_async:
|
|||
|
||||
## Contexts and variables
|
||||
|
||||
CircleCI provides [Contexts](https://circleci.com/docs/2.0/contexts/) to securely pass environment variables across project pipelines. In GitLab, a [Group](../../user/group/index.md) can be created to assemble related projects together. At the group level, [CI/CD variables](../variables/index.md#add-a-cicd-variable-to-a-group) can be stored outside the individual projects, and securely passed into pipelines across multiple projects.
|
||||
CircleCI provides [Contexts](https://circleci.com/docs/contexts) to securely pass environment variables across project pipelines. In GitLab, a [Group](../../user/group/index.md) can be created to assemble related projects together. At the group level, [CI/CD variables](../variables/index.md#add-a-cicd-variable-to-a-group) can be stored outside the individual projects, and securely passed into pipelines across multiple projects.
|
||||
|
||||
## Orbs
|
||||
|
||||
|
|
|
|||
|
|
@ -726,7 +726,7 @@ GitLab Runner can generate and produce attestation metadata for all build artifa
|
|||
|
||||
### Attestation format
|
||||
|
||||
The attestation metadata is generated in the [in-toto attestation format](https://github.com/in-toto/attestation) for spec version [v0.1](https://in-toto.io/Statement/v0.1). The following fields are populated by default:
|
||||
The attestation metadata is generated in the [in-toto attestation format](https://github.com/in-toto/attestation) for spec version [v0.1](https://github.com/in-toto/attestation/tree/v0.1.0/spec). The following fields are populated by default:
|
||||
|
||||
| Field | Value |
|
||||
| ------ | ------ |
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ To configure your Vault server:
|
|||
- `VAULT_SERVER_URL` - The URL of your Vault server, such as `https://vault.example.com:8200`.
|
||||
Required.
|
||||
- `VAULT_AUTH_ROLE` - Optional. The role to use when attempting to authenticate.
|
||||
If no role is specified, Vault uses the [default role](https://www.vaultproject.io/api/auth/jwt#default_role)
|
||||
If no role is specified, Vault uses the [default role](https://www.vaultproject.io/api-docs/auth/jwt#default_role)
|
||||
specified when the authentication method was configured.
|
||||
- `VAULT_AUTH_PATH` - Optional. The path where the authentication method is mounted, default is `jwt`.
|
||||
- `VAULT_NAMESPACE` - Optional. The [Vault Enterprise namespace](https://www.vaultproject.io/docs/enterprise/namespaces) to use for reading secrets and authentication.
|
||||
|
|
@ -183,7 +183,7 @@ For a full list of `CI_JOB_JWT` claims, read the
|
|||
|
||||
You can also specify some attributes for the resulting Vault tokens, such as time-to-live,
|
||||
IP address range, and number of uses. The full list of options is available in
|
||||
[Vault's documentation on creating roles](https://www.vaultproject.io/api/auth/jwt#create-role)
|
||||
[Vault's documentation on creating roles](https://www.vaultproject.io/api-docs/auth/jwt#create-role)
|
||||
for the JSON web token method.
|
||||
|
||||
## Using a self-signed Vault server
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ Depending on the CI infrastructure,
|
|||
the CI may have to fetch the Docker image every time the job runs.
|
||||
For the scanning job to run fast and avoid wasting bandwidth, Docker images should be as small as
|
||||
possible. You should aim for 50MB or smaller. If that isn't possible, try to keep it below 1.46 GB,
|
||||
which is the size of a CD-ROM.
|
||||
which is the size of a DVD-ROM.
|
||||
|
||||
If the scanner requires a fully functional Linux environment,
|
||||
it is recommended to use a [Debian](https://www.debian.org/intro/about) "slim" distribution or [Alpine Linux](https://www.alpinelinux.org/).
|
||||
|
|
|
|||
|
|
@ -214,16 +214,15 @@ Upgrading to PostgreSQL 13 is not yet supported for GitLab instances with Geo en
|
|||
|
||||
</div>
|
||||
|
||||
<div class="deprecation removal-152">
|
||||
<div class="deprecation removal-153">
|
||||
|
||||
### Vulnerability Report sort by State
|
||||
|
||||
Planned removal: GitLab <span class="removal-milestone">15.2</span> (2022-07-22)
|
||||
Planned removal: GitLab <span class="removal-milestone">15.3</span> (2022-08-22)
|
||||
|
||||
The ability to sort the Vulnerability Report by the `State` column was disabled and put behind a feature flag in GitLab 14.10 due to a refactor
|
||||
of the underlying data model. The feature flag has remained off by default as further refactoring will be required to ensure sorting
|
||||
by this value remains performant. Due to very low usage of the `State` column for sorting, the feature flag will instead be removed in
|
||||
GitLab 15.2 to simplify the codebase and prevent any unwanted performance degradation.
|
||||
by this value remains performant. Due to very low usage of the `State` column for sorting, the feature flag will instead be removed to simplify the codebase and prevent any unwanted performance degradation.
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ module API
|
|||
Gitlab::GrapeLogging::Loggers::ClientEnvLogger.new,
|
||||
Gitlab::GrapeLogging::Loggers::RouteLogger.new,
|
||||
Gitlab::GrapeLogging::Loggers::UserLogger.new,
|
||||
Gitlab::GrapeLogging::Loggers::TokenLogger.new,
|
||||
Gitlab::GrapeLogging::Loggers::ExceptionLogger.new,
|
||||
Gitlab::GrapeLogging::Loggers::QueueDurationLogger.new,
|
||||
Gitlab::GrapeLogging::Loggers::PerfLogger.new,
|
||||
|
|
|
|||
|
|
@ -48,7 +48,9 @@ module API
|
|||
include Gitlab::Auth::AuthFinders
|
||||
|
||||
def access_token
|
||||
super || find_personal_access_token_from_http_basic_auth
|
||||
strong_memoize(:api_guard_access_token) do
|
||||
super || find_personal_access_token_from_http_basic_auth
|
||||
end
|
||||
end
|
||||
|
||||
def find_current_user!
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ module API
|
|||
GITLAB_SHARED_SECRET_HEADER = "Gitlab-Shared-Secret"
|
||||
SUDO_PARAM = :sudo
|
||||
API_USER_ENV = 'gitlab.api.user'
|
||||
API_TOKEN_ENV = 'gitlab.api.token'
|
||||
API_EXCEPTION_ENV = 'gitlab.api.exception'
|
||||
API_RESPONSE_STATUS_CODE = 'gitlab.api.response_status_code'
|
||||
|
||||
|
|
@ -74,6 +75,8 @@ module API
|
|||
|
||||
save_current_user_in_env(@current_user) if @current_user
|
||||
|
||||
save_current_token_in_env
|
||||
|
||||
if @current_user
|
||||
::ApplicationRecord
|
||||
.sticking
|
||||
|
|
@ -88,6 +91,13 @@ module API
|
|||
env[API_USER_ENV] = { user_id: user.id, username: user.username }
|
||||
end
|
||||
|
||||
def save_current_token_in_env
|
||||
token = access_token
|
||||
env[API_TOKEN_ENV] = { token_id: token.id, token_type: token.class } if token
|
||||
|
||||
rescue Gitlab::Auth::UnauthorizedError
|
||||
end
|
||||
|
||||
def sudo?
|
||||
initial_current_user != current_user
|
||||
end
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Gitlab
|
||||
module GrapeLogging
|
||||
module Loggers
|
||||
class TokenLogger < ::GrapeLogging::Loggers::Base
|
||||
def parameters(request, _)
|
||||
params = request.env[::API::Helpers::API_TOKEN_ENV]
|
||||
|
||||
return {} unless params
|
||||
|
||||
params.slice(:token_type, :token_id)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -207,18 +207,20 @@ RSpec.describe "Group Runners" do
|
|||
|
||||
context 'when a runner has a tag' do
|
||||
before do
|
||||
runner.update!(tag_list: ['tag'])
|
||||
runner.update!(tag_list: ['tag1'])
|
||||
end
|
||||
|
||||
it 'user edits runner not to run untagged jobs' do
|
||||
visit edit_group_runner_path(group, runner)
|
||||
|
||||
page.find_field('runner[tag_list]').set('tag, tag2')
|
||||
page.find_field('runner[tag_list]').set('tag1, tag2')
|
||||
|
||||
uncheck 'runner_run_untagged'
|
||||
click_button _('Save changes')
|
||||
|
||||
expect(page).to have_content "#{s_('Runners|Tags')} tag tag2"
|
||||
# Tags can be in any order
|
||||
expect(page).to have_content /#{s_('Runners|Tags')}.*tag1/
|
||||
expect(page).to have_content /#{s_('Runners|Tags')}.*tag2/
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -74,6 +74,7 @@ RSpec.describe 'User browses jobs' do
|
|||
wait_for_requests
|
||||
|
||||
expect(page).to have_selector('.ci-canceled')
|
||||
expect(page).not_to have_selector('[data-testid="jobs-table-error-alert"]')
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -229,7 +229,7 @@ RSpec.describe Gitlab::GitAccess do
|
|||
end
|
||||
|
||||
context 'key is expired' do
|
||||
let(:actor) { create(:rsa_key_2048, :expired) }
|
||||
let(:actor) { create(:deploy_key, :expired) }
|
||||
|
||||
it 'does not allow expired keys', :aggregate_failures do
|
||||
expect { pull_access_check }.to raise_forbidden('Your SSH key has expired.')
|
||||
|
|
@ -263,7 +263,7 @@ RSpec.describe Gitlab::GitAccess do
|
|||
end
|
||||
|
||||
it_behaves_like '#check with a key that is not valid' do
|
||||
let(:actor) { build(:rsa_key_2048, user: user) }
|
||||
let(:actor) { build(:deploy_key, user: user) }
|
||||
end
|
||||
|
||||
it_behaves_like '#check with a key that is not valid' do
|
||||
|
|
|
|||
|
|
@ -0,0 +1,34 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
RSpec.describe Gitlab::GrapeLogging::Loggers::TokenLogger do
|
||||
subject { described_class.new }
|
||||
|
||||
describe ".parameters" do
|
||||
let(:token_id) { 1 }
|
||||
let(:token_type) { "PersonalAccessToken" }
|
||||
|
||||
describe 'when no token information is available' do
|
||||
let(:mock_request) { instance_double(ActionDispatch::Request, 'env', env: {}) }
|
||||
|
||||
it 'returns an empty hash' do
|
||||
expect(subject.parameters(mock_request, nil)).to eq({})
|
||||
end
|
||||
end
|
||||
|
||||
describe 'when token information is available' do
|
||||
let(:mock_request) do
|
||||
instance_double(ActionDispatch::Request, 'env',
|
||||
env: {
|
||||
'gitlab.api.token' => { 'token_id': token_id, 'token_type': token_type }
|
||||
}
|
||||
)
|
||||
end
|
||||
|
||||
it 'adds the token information to log parameters' do
|
||||
expect(subject.parameters(mock_request, nil)).to eq( { 'token_id': 1, 'token_type': "PersonalAccessToken" })
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -5,6 +5,7 @@ module DnsHelpers
|
|||
stub_all_dns!
|
||||
stub_invalid_dns!
|
||||
permit_local_dns!
|
||||
permit_postgresql!
|
||||
end
|
||||
|
||||
def permit_dns!
|
||||
|
|
@ -25,14 +26,30 @@ module DnsHelpers
|
|||
def permit_local_dns!
|
||||
local_addresses = %r{
|
||||
\A
|
||||
::1? | # IPV6
|
||||
(127|10)\.0\.0\.\d{1,3} | # 127.0.0.x or 10.0.0.x local network
|
||||
(192\.168|172\.16)\.\d{1,3}\.\d{1,3} | # 192.168.x.x or 172.16.x.x local network
|
||||
0\.0\.0\.0 | # loopback
|
||||
::1? | # IPV6
|
||||
(127|10)\.0\.0\.\d{1,3} | # 127.0.0.x or 10.0.0.x local network
|
||||
192\.168\.\d{1,3}\.\d{1,3} | # 192.168.x.x local network
|
||||
172\.(1[6-9]|2[0-9]|3[0-1])\.\d{1,3}\.\d{1,3} | # 172.16.x.x - 172.31.x.x local network
|
||||
0\.0\.0\.0 | # loopback
|
||||
localhost
|
||||
\z
|
||||
}xi
|
||||
allow(Addrinfo).to receive(:getaddrinfo).with(local_addresses, anything, nil, :STREAM).and_call_original
|
||||
allow(Addrinfo).to receive(:getaddrinfo).with(local_addresses, anything, nil, :STREAM, anything, anything, any_args).and_call_original
|
||||
end
|
||||
|
||||
# pg v1.4.0, unlike v1.3.5, uses AddrInfo.getaddrinfo to resolve IPv4 and IPv6 addresses:
|
||||
# https://github.com/ged/ruby-pg/pull/459
|
||||
def permit_postgresql!
|
||||
db_hosts.each do |host|
|
||||
next if host.start_with?('/') # Exclude UNIX sockets
|
||||
|
||||
# https://github.com/ged/ruby-pg/blob/252512608a814de16bbad55911f9bbcef0e73cb9/lib/pg/connection.rb#L720
|
||||
allow(Addrinfo).to receive(:getaddrinfo).with(host, anything, nil, :STREAM).and_call_original
|
||||
end
|
||||
end
|
||||
|
||||
def db_hosts
|
||||
ActiveRecord::Base.configurations.configs_for(env_name: Rails.env).map(&:host).compact.uniq
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue