Hola usuario de nuestro sitio web, tenemos la respuesta a lo que necesitas, desplázate y la obtendrás a continuación.
Solución:
En la carpeta Subversion del usuario (%APPDATA%Subversion para ventanas, ~/.subversion para Linux/Mac OS x) agregar
http-auth-types=Basic
a la sección global del servers Archivo. Tenga en cuenta que el caso es diferente entre Basic y basic.
Para mí, VisualSVN informa la siguiente lista de opciones de autenticación que admite:
Negotiate
NTLM
Basic realm="VisualSVN Server"
Cuando el complemento Jenkins Subversion usa http-auth-types para ordenar esta lista, hace una comparación entre mayúsculas y minúsculas. Entonces Basic es diferente de basic y el del servidor Basic opción permanece en la parte inferior de la lista. Negotiate se usa en su lugar y aparentemente el complemento SVN no puede lidiar con eso.
Consulte https://issues.jenkins-ci.org/browse/JENKINS-26158
Parece que el último comentario contiene una solución.
Aunque lo pruebo con Jenkins 1.617 + Subversion plugin 2.5 + VisualSVN Server 3.2.2 y todo funciona correctamente.
Tuve el mismo problema, pero fue difícil descubrir la razón de esto. Jenkins (v2.107) solo dijo:
org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: Negotiate authentication failed: 'No valid credentials provided'
...
Verifiqué dos veces todas las credenciales y todo estaba correcto. Además, el svn independiente funciona muy bien, por ejemplo:
svn info --username xxx --password xxx --no-auth-cache --non-interactive --trust-server-cert https://server.xxx.corp/svn/REPO
Entonces, ¿cómo encontrar un error/problema?
Pista: Jenkins usa SVNKit.
Así podemos descargar SVNKit (https://svnkit.com/) y uso jsvn herramienta de esta distribución:
svnkit-1.9.3/bin/jsvn info --username xxx --password xxx --no-auth-cache --non-interactive --trust-server-cert https://server.xxx.corp/svn/REPO
Inicialmente obtengo un error similar:
svn: E170001: Negotiate authentication failed: 'No valid credentials provided'
Pero dentro del directorio svnkit-1.9.3/conf es logging.properties.disabled Archivo. cuando eliminé .disabled sufijo entonces jsvn poner todos los registros en svnkit-1.9.3/bin/svnkit.0.
Esto muestra todos los problemas. Para mí:
HTTP/1.1 407 Proxy Authentication Required (...)
Genial, no fue un problema con la credencial para SVN sino con la credencial para Company Proxy. En su caso, el problema puede ser diferente, pero este método puede ayudar a encontrar el origen del problema.
Información adicional:
Jenkins proporciona configuraciones al servidor proxy. Pero SVN usa una configuración externa completamente diferente de:
C:UsersAppDataRoamingSubversionservers
Para configurar el proxy, debo proporcionar al archivo anterior:
http-proxy-host = super.proxy.company.com
http-proxy-port = 80
http-proxy-username = defaultusername or DOMAINdefaultusername
http-proxy-password = defaultpassword
Pero esto tampoco funciona tan bien como esperaba: algunas herramientas (maven, svn…) tienen problemas para conectarse a Internet a través de algunos servidores Proxy. La alternativa es proporcionar un proxy local usando CNTLM herramienta (http://cntlm.sourceforge.net/). Cntlm está completamente configurado con la URL del proxy de la empresa, el puerto y el inicio de sesión y la contraseña de mi cuenta de dominio (hash, no texto sin formato). SVN usa directamente solo el proxy local Cntlm (sin necesidad de proporcionar ningún nombre de usuario ni contraseña).
http-proxy-host = mylocal.host.url.at.domain.com
http-proxy-port = 8089
# with neither username nor password
Esquema:
SVN <---(anonymous)--> CNTLM Proxy <---(login, password)---> Company Proxy <----> Internet
SVNKit <---(anonymous)----^
any other tools (Jenkins, maven, ...) can also use CNTLM
Esto funciona muy bien para mí.
Si guardas alguna indecisión o capacidad de regenerar nuestro enunciado puedes añadir una aclaración y con mucho gusto lo estudiaremos.