# Shared library: determine SVN revision **URL:** \ **Category:** Using Jenkins\ **Tags:** question, pipeline\ **Created:** [October 1, 2025, 3:55pm UTC](https://community.jenkins.io/t/shared-library-determine-svn-revision/35670 "2025-10-01T15:55:48Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Zastai](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/zastai/32/45_2.png) [@Zastai](https://community.jenkins.io/u/Zastai)\ **Post date:** [October 1, 2025, 3:55pm UTC](https://community.jenkins.io/t/shared-library-determine-svn-revision/35670/1 "2025-10-01T15:55:48Z")
Context: - a build job is a declarative pipeline, almost always part of a multibranch pipeline job - a Subversion checkout will have been performed either implicitly, or, if there are multiple parallel builds involved, via `checkout scm: scm` (with `poll` and `changelog` set to `true` for one of them, and `false` for the rest) I now need to obtain the Subversion revision number corresponding to that checkout (for the main source, not any externals) from a shared pipeline function (currently just a groovy file in `vars`). My existing approach is to run `svnversion`. Drawback there is that this requires running a `sh` or `bat` step (depending on OS) with `returnStdout: true`; that feels like unnecessary extra overhead, and also causes these steps to be registered and visible in the pipeline info, and I would prefer to keep the internals of my function, well, internal. So, first question: is there an exposed API that enables running a process on the current node and file path and capturing its output without having to go through a `sh` or `bat` step? Alternatively, I could also try to get the revision directly from the SCM object. Looking at SubversionSCM, there are 2 promising APIs: 1. `getRevisionFile()` gives me a `File` object (pointing to a path like `/var/lib/jenkins/jobs/…/branches/trunk/builds/17/revision.txt`) 2. `getLocations()` gets me a list of locations, and it looks like `scm.getLocations()[0].getRevision(null).getNumber()` gets me what I want (obviously the real code would have size and null checks), but I’m not sure how guaranteed that information is, and whether it’s always the first one that has the info I need. Which of these is the safest / most supported approach? Are there others? Note that the Subversion plugin claims to set environment variables: > The Subversion SCM plugin exports the svn revisions and URLs of the build’s subversion modules as environment variables. These are $SVN\_REVISION\_n and $SVN\_URL\_n, where n is the 1-based index of the module in the configuration. > > For backwards compatibility if there’s only a single module, its values are also exported as $SVN\_REVISION and $SVN\_URL. which would be a lot more convenient to use. However, when I try ```auto script { println env.SVN_REVISION println env.SVN_REVISION_1 println env.SVN_REVISION_0 } ``` after the `checkout` step, they all print `null` (and without the `env.` they error out entirely). ---
**Author:** ![poddingue](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/poddingue/32/985_2.png) [@poddingue](https://community.jenkins.io/u/poddingue)\ **Post date:** [October 1, 2025, 4:28pm UTC](https://community.jenkins.io/t/shared-library-determine-svn-revision/35670/2 "2025-10-01T16:28:35Z")
Welcome back, @Zastai! 👋 You might find that the most straightforward and supported option in a Jenkins Pipeline is to rely on the environment variables provided by the Subversion plugin, typically [`SVN_REVISION`](https://github.com/jenkinsci/subversion-plugin/blob/e8cf25770ee352ecf238ed2923ac92b75f0566f1/src/main/resources/hudson/scm/SubversionSCM/buildEnv.groovy#L5). These are usually available when the Subversion checkout is done using the built-in `checkout` step. However, in multibranch pipelines, where the SCM checkout is handled differently, these variables may not always be set. Here are a few alternative approaches you could consider: - **Parsing the revision file:** While technically possible, using `getRevisionFile()` isn’t usually recommended in Pipelines because it can require broader script permissions and direct access to build internals. - **Using the SCM object:** Some users experiment with calls like [`scm.getLocations()[0].getRevision(null).getNumber()`](https://github.com/jenkinsci/subversion-plugin/blob/e8cf25770ee352ecf238ed2923ac92b75f0566f1/src/main/java/hudson/scm/SubversionSCM.java#L507), but this isn’t part of the documented or guaranteed API and might behave differently across plugin versions. - **Running `svnversion` via `sh` or `bat`:** This tends to be the most consistent approach across platforms. The downside is that it exposes internal details in the pipeline log, but in many cases, it’s a reasonable tradeoff for reliability. **In summary:** You might want to start by checking if the environment variables are being set automatically; that’s the cleanest and most future-proof option. If they aren’t available, running `svnversion` from a shell step is probably your safest fallback. Accessing Subversion internals directly from the SCM object or revision file tends to be less stable and isn’t generally recommended for production use. **Examples:** ```auto // Linux example using sh def svnRevision = sh(script: 'svnversion .', returnStdout: true).trim() // Using environment variable if it exists def svnRevision = env.SVN_REVISION ?: env.SVN_REVISION_1 ``` If the environment variable isn’t there, it might help to fall back to the shell-based command. There’s no officially supported Pipeline API for capturing this information without using `sh` or `bat`, but these methods should cover most use cases. ---
**Author:** ![MarkEWaite](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/markewaite/32/20_2.png) [@MarkEWaite](https://community.jenkins.io/u/MarkEWaite)\ **Post date:** [October 1, 2025, 6:05pm UTC](https://community.jenkins.io/t/shared-library-determine-svn-revision/35670/3 "2025-10-01T18:05:13Z")
You might also save the return value of `checkout scm`. It returns name / value pairs that may already include the information that you are seeking. ---
**Author:** ![Zastai](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/zastai/32/45_2.png) [@Zastai](https://community.jenkins.io/u/Zastai)\ **Post date:** [October 2, 2025, 10:50am UTC](https://community.jenkins.io/t/shared-library-determine-svn-revision/35670/4 "2025-10-02T10:50:49Z")
I think I’ll try that, thanks; while it means that I can’t work with the implicit checkout, that’s not a terrible thing. I could even take relevant scm object as a parameter and do the `checkout` myself, keeping the calling pipeline simple.