mirror of
https://github.com/scm-manager/scm-manager.git
synced 2025-11-15 09:46:16 +01:00
Add documentation for migration
This commit is contained in:
René Pfeuffer
@@ -4,11 +4,11 @@ subtitle: Various configuration options for the SCM-Server
|
||||
displayToc: true
|
||||
---
|
||||
|
||||
SCM-Manager can be configured in several ways. We recommend using `config.yml` to have most of the settings in
|
||||
SCM-Manager v3 can be configured in several ways. We recommend using `config.yml` to have most of the settings in
|
||||
one place. However, if required, each option in this configuration can also be set via environment variables.
|
||||
See the relevant topics below for more information.
|
||||
|
||||
## Change log level
|
||||
## Logging
|
||||
|
||||
The log level can be configured in the `config.yml`.
|
||||
You can change the root log level to change the log level globally for all loggers.
|
||||
@@ -18,7 +18,7 @@ We provide two types of log appender.
|
||||
everything to your (bash/shell) console.
|
||||
Depending on which platform your scm-server is running, we already configured the recommended logging settings.
|
||||
|
||||
#### Example
|
||||
**Example**
|
||||
|
||||
```yaml
|
||||
log:
|
||||
@@ -53,7 +53,7 @@ You have to enable your logback configuration by setting the file path with the
|
||||
property `logback.configurationFile`, like `-Dlogback.configurationFile=logging.xml`.
|
||||
If the logback configuration is enabled, the log configuration of the `config.yml` will be ignored.
|
||||
|
||||
#### Example
|
||||
**Example**
|
||||
|
||||
```xml
|
||||
|
||||
@@ -105,12 +105,12 @@ If the logback configuration is enabled, the log configuration of the `config.ym
|
||||
</configuration>
|
||||
```
|
||||
|
||||
## Change host, port and context path
|
||||
## Webserver Configuration
|
||||
|
||||
The listener host and port of your SCM-Server can directly be edited in the top level of your `config.yml`.
|
||||
If you want your server without a context path (use `root path`), you can change this option to be `/`.
|
||||
|
||||
#### Example
|
||||
**Example**
|
||||
|
||||
```yaml
|
||||
# This is the host adresse, `0.0.0.0` means it listens on every interface
|
||||
@@ -187,7 +187,7 @@ protect your keystore.
|
||||
|
||||
Adjust your `config.yml` to apply your prepared keystore with configured certificate.
|
||||
|
||||
#### Example
|
||||
**Example**
|
||||
|
||||
```yaml
|
||||
https:
|
||||
@@ -215,7 +215,7 @@ on unix-based packages).
|
||||
For technical reasons the tempDir is located at the top level of your config.yml. All other path-based config options
|
||||
are located under `webapp`.
|
||||
|
||||
#### Example
|
||||
**Example**
|
||||
|
||||
```yaml
|
||||
tempDir: /tmp
|
||||
@@ -239,7 +239,7 @@ These HTTP headers are being appended to the requests which are redirected by yo
|
||||
this option set, your SCM-Server may run into connection issues. This option is disabled by default, because without a
|
||||
reverse proxy it could cause security issues.
|
||||
|
||||
#### Example
|
||||
**Example**
|
||||
|
||||
```yaml
|
||||
forwardHeadersEnabled: true
|
||||
|
||||
@@ -1,21 +1,21 @@
|
||||
---
|
||||
title: Migrate from v1 to v2
|
||||
title: Migrate from v1 to v3
|
||||
subtitle: How to use the Migration-Wizard
|
||||
---
|
||||
|
||||
# Preparation
|
||||
|
||||
To upgrade an SCM-Manager from version 1 to version 2, some changes have to be made according the home directory of the SCM-Manager. So before you start, **make sure that you have an up to date backup of your SCM home folder!**
|
||||
It is possible to upgrade SCM-Manager from version directly to version 3. To do so, some changes have to be made according the home directory of the SCM-Manager. So before you start, **make sure that you have an up to date backup of your SCM home folder!**
|
||||
|
||||
Before the migration process can be started, the last running version of SCM-Manager had to be (at least) 1.60. Data of older versions cannot be migrated automatically. If this is the case, you can stop version 1 and start a version 2 SCM-Manager (make sure that you have configured the same SCM home folder).
|
||||
Before the migration process can be started, the last running version of SCM-Manager had to be (at least) 1.60. Data of older versions cannot be migrated automatically. If this is the case, you can stop version 1 and start a version 3 SCM-Manager (make sure that you have configured the same SCM home folder).
|
||||
|
||||
# Repository migration
|
||||
|
||||
When SCM-Manager starts for the first time, you have to choose how to migrate your existing repositories. The background of this is the following:
|
||||
|
||||
While in version 1 of SCM-Manager the repositories were stored in a directory according to their type (`git`, `hg` or `svn`) and their name, in version 2 the directory is independent of the type and name. Therefore a repository is no longer named with an arbitrary number of name parts devided by slashes (`/`), but it has a namespace and a name (both of which must not contain slashes). The namespace should be used to group your repositories (for example you can use this to distinguish between the types of repositories like *git* and *hg* like version 1 or to assign them to different projects or users).
|
||||
While in version 1 of SCM-Manager the repositories were stored in a directory according to their type (`git`, `hg` or `svn`) and their name, from version 2 on the directory is independent of the type and name. Therefore, a repository is no longer named with an arbitrary number of name parts devided by slashes (`/`), but it has a namespace and a name (both of which must not contain slashes). The namespace should be used to group your repositories (for example you can use this to distinguish between the types of repositories like *git* and *hg* like version 1 or to assign them to different projects or users).
|
||||
|
||||
To specify the new names (and namespaces), the SCM-Manager version 2 starts a migration wizard when it is first started with a home directory of a version 1 SCM-Manager. You can see an according message in the log:
|
||||
To specify the new names (and namespaces), the SCM-Manager version 3 starts a migration wizard when it is first started with a home directory of a version 1 SCM-Manager. You can see an according message in the log:
|
||||
|
||||
```
|
||||
2019-12-05 14:01:35.109 [main] [ ] INFO sonia.scm.update.MigrationWizardModule - ==========================================================
|
||||
|
||||
18
docs/en/migrate-scm-manager-from-v2/index.md
Normal file
18
docs/en/migrate-scm-manager-from-v2/index.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: Migrate from v2 to v3
|
||||
subtitle: Changes in the configuration
|
||||
---
|
||||
|
||||
# Configuration changes
|
||||
|
||||
The configuration of SCM-Manager version 3 has changed. While in version 2 the configuration was split into different
|
||||
files, environment variables and Java properties, the configuration is now stored in a single file `config.yml` in the
|
||||
`conf` directory of the SCM installation folder. The file is in [YAML](https://yaml.org/). Our goal was to make the
|
||||
configuration more readable and easier to understand.
|
||||
|
||||
If needed, all these settings now can be overwritten by environment variables. This makes it easier to configure
|
||||
SCM-Manager in a Docker container or Kubernetes.
|
||||
|
||||
So if you have set up your SCM-Manager v2 with a custom configuration using different ports, SSL, specific logging and
|
||||
so on, you have to migrate your configuration to the new format. Please see
|
||||
the [configuration documentation](../administration/scm-server) for more information.
|
||||
@@ -3,6 +3,7 @@
|
||||
- /installation/
|
||||
- /first-startup/
|
||||
- /migrate-scm-manager-from-v1/
|
||||
- /migrate-scm-manager-from-v2/
|
||||
- /import/
|
||||
- /faq/
|
||||
- /known-issues/
|
||||
|
||||
@@ -32,7 +32,7 @@ if $(dpkg --compare-versions "$current_version" lt "3.0.0"); then
|
||||
You are upgrading to a new major version which could break your current server
|
||||
configuration. Find more information about the migration here:
|
||||
|
||||
<link>
|
||||
https://scm-manager.org/docs/latest/en/migrate-scm-manager-from-v2/
|
||||
|
||||
Press any key to continue
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ if [ $((current_version)) -lt $(("3")) ]; then
|
||||
You are upgrading to a new major version which could break your current server
|
||||
configuration. Find more information about the migration here:
|
||||
|
||||
<link>
|
||||
https://scm-manager.org/docs/latest/en/migrate-scm-manager-from-v2/
|
||||
|
||||
Press Enter to continue
|
||||
|
||||
|
||||
@@ -45,14 +45,13 @@ public class ServerConfigParser {
|
||||
|
||||
ServerConfigYaml parse(URL configFile) {
|
||||
if (configFile == null) {
|
||||
//TODO add link
|
||||
throw new ServerConfigurationException("""
|
||||
Could not find config.yml.
|
||||
|
||||
If you have upgraded from an older SCM-Manager version, you have to migrate your server-config.xml
|
||||
to the new format using the official instructions:
|
||||
|
||||
<link>
|
||||
https://scm-manager.org/docs/latest/en/migrate-scm-manager-from-v2/
|
||||
""");
|
||||
}
|
||||
try (InputStream is = configFile.openStream()) {
|
||||
|
||||
Reference in New Issue
Block a user