b6116b1fc9
* Stop ignoring global Mercurial configuration for non-server commands There was previously a weird duality where a simple push to or pull from a repository hosted by SCM-Manager would load all of the system and user level config files, but they were ignored when importing a repository. I found this out when importing an LFS repo, and it eventually failed with a message that the LFS extension needs to be enabled, even though it was enabled globally. The global config should typically never be ignored, because some repositories are unreadable without certain extensions or configurations. The JavaHg API here mirrors the hg behavior for the `HGRCPATH` environment variable- not setting it (or null here) uses the default config resolution, and `""` (the default in JavaHg for some reason) disables default config resolution. The repository initialization code in JavaHg also uses `""`, and there's no way to alter that from the outside. But that appears to be harmless, so I'm ignoring that for now. Note that this may only have been a problem on non-Windows systems- setting an environment variable to empty on Windows *unsets* the variable, even in the `_wputenv()` API, which is what we want. After this, normal push/pull operations continue to use the global config. But now imports from the SCM-Manager UI, the hooks run during a push, and any other commands that are run through JavaHg will see a consistent configuration. LFS (and maybe largefiles- I haven't tested it) repository imports now work. (I wouldn't say "supported" yet because it doesn't pull the blobs. The largefiles extension has a command for doing this, but the LFS extension doesn't. The stopgap for this is to run `hg verify` to download the blobs, but that won't work here with the way subrepos aren't nested as expected. I can work on a command on the hg side to fill this gap.) One final thing to note here- as I was testing, I initially got authentication failures when trying to pull. It happened several times as I added more and more logging, then disappeared, and I wasn't able to trigger it again as I backed off the logging to get to this change alone. The auth info is written to the repository's hgrc file, so a change to whether or not the global configuration is processed is irrelevant. The next couple of commits will try to improve the related code. * Stop modifying and reusing the global JavaHg RepositoryConfiguration singleton I can't point to a specific error, but modifying a singleton and reusing it is a good way to get unexpected state. The extension adding won't collect additional state (it's add-if-not-present), but the underlying `java.util.HashMap` isn't threadsafe. Any differences in the environment map when this is called would alter that state of anything else that still held a configuration (and it also uses `HashMap`), and the pending changeset, encoding, and HgBin settings would be overwritten for everybody outright. There's only a default constructor for this class, so nothing to pass along in the constructor. I don't *think* this was the cause of the random auth failures mentioned in the previous commit, but it's easy to avoid these potential problems. * Avoid modifying the Mercurial repository config file to add config options Modifying the config file is complicated and error prone, but there hasn't been any other option aside from setting `HGRCPATH` to point to a standalone file. Starting with Mercurial 7.0 (scheduled for March 2025), there's now a global option to specify one or more additional config files on the command line, without disabling the normal system and user level config file processing.[1] Since I'm not sure what the minimum supported Mercurial is for this project, this includes an extension that backports the same option if it is not present in the version of Mercurial that is used, and does nothing if Mercurial natively supports it. I tested back to Mercurial 6.0, which should be more than sufficient- 6.1.4 (June 2022) was the last release to support Python 2 (which has been EOL since Jan 2020), and the Python 3 support before that release was considered experimental. It likely works in earlier versions, but there's a definite minimum of 4.9 (Feb 2019), due to the `exthelper` module import. Without the need to modify a possibly existing file and then restore it when done, a bunch of code falls away, and the tests that supported it. [1] https://repo.mercurial-scm.org/hg/rev/25b344f2aeef * Clean up --------- Co-authored-by: René Pfeuffer <rene.pfeuffer@cloudogu.com>
The easiest way to share and manage your Git, Mercurial and Subversion repositories.
- Very easy installation
- No need to hack configuration files, SCM-Manager is completely configurable from its Web-Interface
- No Apache and no database installation required
- Central user, group and permission management
- Out of the box support for Git, Mercurial and Subversion
- Full RESTFul Web Service API (JSON and XML)
- Rich User Interface
- Simple Plugin API
- Useful plugins available
- Licensed under AGPL-3.0-only
This branch (develop) is for the development of SCM-Manager. If you are interested in the development of version
1.x, please checkout the branch support/1.x.
News
All news regarding SCM-Manager will be published in our blog.
Support / Community
Contact the SCM-Manager community support
Documentation
You can find the complete documentation on our homepage.
Development
The build of SCM-Manager requires the following installed packages:
- Git
- JDK 11
- Mercurial (required for tests)
- Docker (required for the docker package)
The build of SCM-Manager requires Java 11.
Tasks
SCM-Manager uses Gradle for the build. The build itself is organized in tasks, the tasks can be executed with the gradle wrapper:
# on *nix
./gradlew taskname
# on windows
gradlew.bat taskname
This following tables describes some high level tasks, which should cover most of the daily work.
| Name | Description |
|---|---|
| run | Starts an SCM-Manager with enabled livereload for the ui |
| build | Executes all checks, tests and builds the smp inclusive javadoc and source jar |
| distribution | Builds all distribution packages of scm-packaging |
| check | Executes all registered checks and tests |
| test | Run all unit tests |
| integrationTest | Run all integration tests of scm-it |
| clean | Deletes the build directory |
The next table defines a few more tasks which are more relevant for CI servers.
| Name | Description |
|---|---|
| publish | Publishes all artifacts and packages (required properties, see section 'Properties for publishing') |
| sonarqube | Executes a SonarQube analysis |
| setVersion | Sets the version to a new version |
| setVersionToNextSnapshot | Sets the version to the next snapshot version |
There many more tasks, which are executed as part of the high level tasks, and it should rarely be necessary to call them individually. To see the full list of available tasks, execute the following command:
# on *nix
./gradlew tasks
# on windows
gradlew.bat tasks
Dependencies
Dependencies and their versions are configured in the gradle/dependencies.gradle.
Versions of dependencies can be specified as exact version or as a range of versions.
In order to keep the build consistent and reproducible, we use gradle dependency locking.
Whenever a dependency was added, changed or removed the lock files must be refreshed e.g.:
# on *nix
./gradlew resolveAndLockAll --write-locks
# on windows
gradlew.bat resolveAndLockAll --write-locks
Artifacts and reports
Artifacts and reports which are created from the tasks are stored in the build directory of each subproject.
Debugging
If you want to debug the run task of SCM-Manager.
You can provide the --debug-jvm option, which starts the SCM-Manager jvm in debug mode.
Then you can attach a debugger on port 5005.
The port can be changed by using the --debug-port e.g.: --debug-port=5006.
If you want to wait until a debugger is attached, before SCM-Manager starts you can use the --debug-wait option.
Distribution
SCM-Manager provides various modules to deploy SCM-Manager on differnt platforms (e.g. Docker, Helm, RPM, DEB, Windows).
Those modules are not build by default.
To build the distribution modules specify the enablePackaging property e.g.:
# on *nix
./gradlew -PenablePackaging distribution
# on windows
gradlew.bat -PenablePackaging distribution
The command above will refresh the lock files of all sub projects and all configurations.
Properties for publishing
The publishing process requires the following properties for authentication and signing.
Those properties should be stored in ~/.gradle/gradle.properties.
| Property | Description |
|---|---|
| packagesScmManagerUsername | Username for packages.scm-manager.org |
| packagesScmManagerPassword | Password for packages.scm-manager.org |
| dockerUsername | Username for Docker Hub |
| dockerPassword | Password or Api Token for Docker Hub |
| gitHubApiToken | Api Token for GitHub |
| npmEmail | Email of NPM account |
| npmToken | Access Token for NPM account |
| signing.keyId | Id of gpg secret key for signing |
| signing.password | Passphrase of gpg secret key |
| signing.secretKeyRingFile | Path to gpg secret key ring file |
Need help?
Looking for more guidance? Full documentation lives on our homepage or the dedicated pages for our plugins. Do you have further ideas or need support?
-
Community Support - Contact the SCM-Manager support team for questions about SCM-Manager, to report bugs or to request features through the official channels. Find more about this here.
-
Enterprise Support - Do you require support with the integration of SCM-Manager into your processes, with the customization of the tool or simply a service level agreement (SLA)? Contact our development partner Cloudogu! Their team is looking forward to discussing your individual requirements with you and will be more than happy to give you a quote. Request Enterprise Support.