I'm using a parameterized build with

• List Subversion tags (and more)
  • Name SVN_TAG
  • Repository URL: https://svn.server.domain/a/
  • Default value: trunk

• Source Code Management
  • Subversion
  • Modules
  • Repository URL
  • https://svn.server.domain/a/$SVN_TAG

Usually jenkins polls scm (subversion) for changes.
If poll detects a change on trunk, then jenkins will update it's working copy from subversion repository trunk and executes a build - fine.

When I choose

• Build Now
• SVN_TAG: 1.1
• Build

Jenkins checks out https://svn.server.domain/a/tags/1.1 and executes a build - still fine.

Subsequent scm polls of jenkins are directed to this tag, which is usually not changed.

Jenkins does not poll for changes of trunk, until a user requests a manual build of trunk.

This ist not desired in our environment.

Proposed behaviour of jenkins:

• after user has executed a manual build of tag 1.1 (in general: with setting some parameters for the parameterized build)
• jenkins resets these parameters to the default values
• subsequent scm polls use default values for all parameters, expecially SVN_TAG in the use case described above.