Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
7fe1490a58
commit
8308674afc
|
|
@ -9,7 +9,8 @@ module RestClient
|
|||
begin
|
||||
ip, hostname_override = Gitlab::UrlBlocker.validate!(uri, allow_local_network: allow_settings_local_requests?,
|
||||
allow_localhost: allow_settings_local_requests?,
|
||||
dns_rebind_protection: dns_rebind_protection?)
|
||||
dns_rebind_protection: dns_rebind_protection?,
|
||||
schemes: %w[http https])
|
||||
|
||||
self.hostname_override = hostname_override
|
||||
rescue Gitlab::UrlBlocker::BlockedUrlError => e
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
breaking_change: true # If this deprecation is a breaking change, set this value to true
|
||||
reporter: sarahwaldner # GitLab username of the person reporting the deprecation
|
||||
body: | # Do not modify this line, instead modify the lines below.
|
||||
The feature flag `PUSH_RULES_SUPERSEDE_CODE_OWNERS` is being removed in GitLab 15.0. Upon its removal, push rules will supersede CODEOWNERS. The CODEOWNERS feature will no longer be available for access control.
|
||||
The feature flag `PUSH_RULES_SUPERSEDE_CODE_OWNERS` is being removed in GitLab 15.0. Upon its removal, push rules will supersede Code Owners. Even if Code Owner approval is required, a push rule that explicitly allows a specific user to push code supersedes the Code Owners setting.
|
||||
# The following items are not published on the docs page, but may be used in the future.
|
||||
stage: create # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
|
||||
tiers: # (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]
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
breaking_change: true # If this deprecation is a breaking change, set this value to true
|
||||
reporter: tlinz # GitLab username of the person reporting the deprecation
|
||||
body: | # Do not modify this line, instead modify the lines below.
|
||||
The `push_rules_supersede_code_owners` feature flag has been removed in GitLab 15.0. From now on, push rules will supersede the `CODEOWNERS` file. The code owners feature is no longer available for access control.
|
||||
The `push_rules_supersede_code_owners` feature flag has been removed in GitLab 15.0. From now on, push rules will supersede the `CODEOWNERS` file. Even if Code Owner approval is required, a push rule that explicitly allows a specific user to push code supersedes the Code Owners setting.
|
||||
# The following items are not published on the docs page, but may be used in the future.
|
||||
stage: create # (optional - may be required in the future) String value of the stage that the feature was created in. e.g., Growth
|
||||
tiers: # (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]
|
||||
|
|
|
|||
|
|
@ -25,8 +25,7 @@ Starting with version 9.2, the Omnibus GitLab package ships a
|
|||
`dependency_licenses.json` file containing version and license information of
|
||||
all bundled software, including software libraries, Ruby gems that the rails
|
||||
application uses, and JavaScript libraries that is required for the frontend
|
||||
components. This file, being in JSON format, is easily machine parseable and
|
||||
can be used for automated checks or validations. The file may be found at
|
||||
components. Because it's in JSON format, GitLab can parse this file easily and use it for automated checks or validations. The file may be found at
|
||||
`/opt/gitlab/dependency_licenses.json`.
|
||||
|
||||
Starting with version 11.3, we have also made the license information available
|
||||
|
|
|
|||
|
|
@ -616,6 +616,7 @@ Install the gems (if you want to use Kerberos for user authentication, omit
|
|||
```shell
|
||||
sudo -u git -H bundle config set --local deployment 'true'
|
||||
sudo -u git -H bundle config set --local without 'development test mysql aws kerberos'
|
||||
sudo -u git -H bundle config path /home/git/gitlab/vendor/bundle
|
||||
sudo -u git -H bundle install
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -989,7 +989,7 @@ WARNING:
|
|||
This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
|
||||
Review the details carefully before upgrading.
|
||||
|
||||
The feature flag `PUSH_RULES_SUPERSEDE_CODE_OWNERS` is being removed in GitLab 15.0. Upon its removal, push rules will supersede CODEOWNERS. The CODEOWNERS feature will no longer be available for access control.
|
||||
The feature flag `PUSH_RULES_SUPERSEDE_CODE_OWNERS` is being removed in GitLab 15.0. Upon its removal, push rules will supersede Code Owners. Even if Code Owner approval is required, a push rule that explicitly allows a specific user to push code supersedes the Code Owners setting.
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -1270,7 +1270,6 @@ This issue is resolved in GitLab 15.3.3, so customers with the following configu
|
|||
|
||||
## Miscellaneous
|
||||
|
||||
- [Restoring from backup after a failed upgrade](restore_after_failure.md)
|
||||
- [Upgrading PostgreSQL Using Slony](upgrading_postgresql_using_slony.md), for
|
||||
upgrading a PostgreSQL database with minimal downtime.
|
||||
- [Managing PostgreSQL extensions](../install/postgresql_extensions.md)
|
||||
|
|
|
|||
|
|
@ -750,7 +750,7 @@ WARNING:
|
|||
This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
|
||||
Review the details carefully before upgrading.
|
||||
|
||||
The `push_rules_supersede_code_owners` feature flag has been removed in GitLab 15.0. From now on, push rules will supersede the `CODEOWNERS` file. The code owners feature is no longer available for access control.
|
||||
The `push_rules_supersede_code_owners` feature flag has been removed in GitLab 15.0. From now on, push rules will supersede the `CODEOWNERS` file. Even if Code Owner approval is required, a push rule that explicitly allows a specific user to push code supersedes the Code Owners setting.
|
||||
|
||||
### `type` and `types` keyword from CI/CD configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -2,64 +2,11 @@
|
|||
stage: Systems
|
||||
group: Distribution
|
||||
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
|
||||
remove_date: '2023-02-28'
|
||||
redirect_to: '../raketasks/backup_restore.md'
|
||||
---
|
||||
|
||||
# Restoring from backup after a failed upgrade **(FREE SELF)**
|
||||
# Restoring from backup after a failed upgrade (removed) **(FREE SELF)**
|
||||
|
||||
Upgrades are usually smooth and restoring from backup is a rare occurrence.
|
||||
However, it's important to know how to recover when problems do arise.
|
||||
|
||||
## Roll back to an earlier version and restore a backup
|
||||
|
||||
In some cases after a failed upgrade, the fastest solution is to roll back to
|
||||
the previous version you were using. We recommend this path because the failed
|
||||
upgrade might have made database changes that cannot be readily reverted.
|
||||
|
||||
First, roll back the code or package. For source installations this involves
|
||||
checking out the older version (branch or tag). For Omnibus installations this
|
||||
means installing the older
|
||||
[`.deb` or `.rpm` package](https://packages.gitlab.com/gitlab). Then, restore from a
|
||||
backup.
|
||||
Follow the instructions in the
|
||||
[Backup and Restore](../raketasks/backup_restore.md#restore-gitlab)
|
||||
documentation.
|
||||
|
||||
## Potential problems on the next upgrade
|
||||
|
||||
When a rollback is necessary it can produce problems on subsequent upgrade
|
||||
attempts. This is because some tables may have been added during the failed
|
||||
upgrade. If these tables are still present after you restore from the
|
||||
older backup it can lead to migration failures on future upgrades.
|
||||
|
||||
We drop all tables prior to importing the backup to prevent this problem.
|
||||
|
||||
Example error:
|
||||
|
||||
```plaintext
|
||||
== 20151103134857 CreateLfsObjects: migrating =================================
|
||||
-- create_table(:lfs_objects)
|
||||
rake aborted!
|
||||
StandardError: An error has occurred, this and all later migrations canceled:
|
||||
|
||||
PG::DuplicateTable: ERROR: relation "lfs_objects" already exists
|
||||
```
|
||||
|
||||
Copy the version from the error. In this case the version number is
|
||||
`20151103134857`.
|
||||
|
||||
WARNING:
|
||||
Use the following steps only if you are certain you must do them.
|
||||
|
||||
1. Pass the version to a database Rake task to manually mark the migration as
|
||||
complete.
|
||||
|
||||
```shell
|
||||
# Source install
|
||||
sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857] RAILS_ENV=production
|
||||
|
||||
# Omnibus install
|
||||
sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
|
||||
```
|
||||
|
||||
1. After the migration is successfully marked, run the Rake `db:migrate` task again.
|
||||
1. Repeat this process until all failed migrations are complete.
|
||||
This content was removed in GitLab 15.7.
|
||||
Use the [backup and restore](../raketasks/backup_restore.md) documentation instead.
|
||||
|
|
|
|||
|
|
@ -150,7 +150,7 @@ version and manually ensuring that the batched migrations complete successfully.
|
|||
|
||||
#### Roll back and follow the required upgrade path
|
||||
|
||||
1. [Rollback and restore the previously installed version](../../../update/restore_after_failure.md#roll-back-to-an-earlier-version-and-restore-a-backup)
|
||||
1. [Rollback and restore the previously installed version](../../../raketasks/backup_restore.md)
|
||||
1. Update to either 14.0.5 or 14.1 **before** updating to 14.2+
|
||||
1. [Check the status](#check-the-status-of-background-migrations) of the batched background migrations and
|
||||
make sure they are all marked as finished before attempting to upgrade again. If any remain marked as active,
|
||||
|
|
|
|||
|
|
@ -34,6 +34,10 @@ project and the security policy project, this is not recommended. Keeping the se
|
|||
project separate from the development project allows for complete separation of duties between
|
||||
security/compliance teams and development teams.
|
||||
|
||||
You should not link a security policy project to a development project and to the group
|
||||
or sub-group the development project belongs to at the same time. Linking this way will result in
|
||||
approval rules from the Scan Result Policy not being applied to merge requests in the development project.
|
||||
|
||||
All security policies are stored in the `.gitlab/security-policies/policy.yml` YAML file inside the
|
||||
linked security policy project. The format for this YAML is specific to the type of policy that is
|
||||
stored there. Examples and schema information are available for the following policy types:
|
||||
|
|
|
|||
|
|
@ -192,6 +192,8 @@ When an npm package is not found in the Package Registry, the request is forward
|
|||
|
||||
Administrators can disable this behavior in the [Continuous Integration settings](../../admin_area/settings/continuous_integration.md).
|
||||
|
||||
Group owners can disable this behavior in the group Packages and Registries settings.
|
||||
|
||||
### Install npm packages from other organizations
|
||||
|
||||
You can route package requests to organizations and users outside of GitLab.
|
||||
|
|
|
|||
|
|
@ -412,6 +412,7 @@ The following table lists group permissions available for each role:
|
|||
| Pull [packages](packages/index.md) | | ✓ | ✓ | ✓ | ✓ |
|
||||
| Delete [packages](packages/index.md) | | | | ✓ | ✓ |
|
||||
| Create/edit/delete [Maven and generic package duplicate settings](packages/generic_packages/index.md#do-not-allow-duplicate-generic-packages) | | | | ✓ | ✓ |
|
||||
| Enable/disable package request forwarding | | | | ✓ | ✓ |
|
||||
| Pull a Container Registry image | ✓ (6) | ✓ | ✓ | ✓ | ✓ |
|
||||
| Remove a Container Registry image | | | ✓ | ✓ | ✓ |
|
||||
| View [Group DevOps Adoption](group/devops_adoption/index.md) | | ✓ | ✓ | ✓ | ✓ |
|
||||
|
|
|
|||
|
|
@ -6,9 +6,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Create a Pages deployment for your static site **(FREE)**
|
||||
|
||||
To generate a GitLab Pages website, you can fill out forms that
|
||||
automatically generate a `.gitlab-ci.yml` file and open a
|
||||
merge request with your changes. When you commit the merge request,
|
||||
If you already have a GitLab project that contains your static site or framework,
|
||||
you can generate a GitLab Pages website from it.
|
||||
|
||||
When you provide basic information in the UI, a `.gitlab-ci.yml` file is created
|
||||
and a merge request opened. When you commit the merge request,
|
||||
a pipeline deploys your Pages website.
|
||||
|
||||
## Prerequisites
|
||||
|
|
|
|||
|
|
@ -152,4 +152,11 @@ RSpec.shared_examples 'a request using Gitlab::UrlBlocker' do
|
|||
expect(request_stub).to have_been_requested
|
||||
end
|
||||
end
|
||||
|
||||
context 'when a non HTTP/HTTPS URL is provided' do
|
||||
it 'raises an error' do
|
||||
expect { make_request('ssh://example.com') }
|
||||
.to raise_error(ArgumentError)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue