diff --git a/docs/en/administration/scm-server.md b/docs/en/administration/scm-server.md index 86819d6ec2..38f275370e 100644 --- a/docs/en/administration/scm-server.md +++ b/docs/en/administration/scm-server.md @@ -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 ``` -## 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 diff --git a/docs/en/migrate-scm-manager-from-v1/index.md b/docs/en/migrate-scm-manager-from-v1/index.md index 378daa1f2a..d9aea6418a 100644 --- a/docs/en/migrate-scm-manager-from-v1/index.md +++ b/docs/en/migrate-scm-manager-from-v1/index.md @@ -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 - ========================================================== diff --git a/docs/en/migrate-scm-manager-from-v2/index.md b/docs/en/migrate-scm-manager-from-v2/index.md new file mode 100644 index 0000000000..4dc983b809 --- /dev/null +++ b/docs/en/migrate-scm-manager-from-v2/index.md @@ -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. diff --git a/docs/en/navigation.yml b/docs/en/navigation.yml index 7152f930a7..0fb1231705 100644 --- a/docs/en/navigation.yml +++ b/docs/en/navigation.yml @@ -3,6 +3,7 @@ - /installation/ - /first-startup/ - /migrate-scm-manager-from-v1/ + - /migrate-scm-manager-from-v2/ - /import/ - /faq/ - /known-issues/ diff --git a/scm-packaging/deb/src/main/scripts/preinst b/scm-packaging/deb/src/main/scripts/preinst index 2ccd51844f..5e81195783 100644 --- a/scm-packaging/deb/src/main/scripts/preinst +++ b/scm-packaging/deb/src/main/scripts/preinst @@ -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: - +https://scm-manager.org/docs/latest/en/migrate-scm-manager-from-v2/ Press any key to continue diff --git a/scm-packaging/rpm/src/main/scripts/before-installation.sh b/scm-packaging/rpm/src/main/scripts/before-installation.sh index dacc8d0c17..690567ca70 100644 --- a/scm-packaging/rpm/src/main/scripts/before-installation.sh +++ b/scm-packaging/rpm/src/main/scripts/before-installation.sh @@ -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: - +https://scm-manager.org/docs/latest/en/migrate-scm-manager-from-v2/ Press Enter to continue diff --git a/scm-server/src/main/java/sonia/scm/server/ServerConfigParser.java b/scm-server/src/main/java/sonia/scm/server/ServerConfigParser.java index 8eadb7f653..05d119ac39 100644 --- a/scm-server/src/main/java/sonia/scm/server/ServerConfigParser.java +++ b/scm-server/src/main/java/sonia/scm/server/ServerConfigParser.java @@ -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: - + https://scm-manager.org/docs/latest/en/migrate-scm-manager-from-v2/ """); } try (InputStream is = configFile.openStream()) {