Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Repo is not accessible. Please check your URL and repo settings.

Discussion in 'Unity Build Automation' started by drolak, Aug 8, 2016.

  1. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    Hi,
    I'm trying to setup cloud build with SVN and getting the error :
    Repo is not accessible. Please check your URL and repo settings.

    Though the repo IS accessible, the credentials are ok. I have no idea what's going on.

    I read that you run into problems when using self signed certificate, but that's not the case.

    the repo url is https://svn.tabascointeractive.com/ninja/trunk
     
  2. dannyd

    dannyd

    Unity Technologies

    Joined:
    Jun 3, 2014
    Posts:
    785
    My guess is that there is some special character (or space) in the password that we aren't escaping properly when trying to connect. Can you try using a password that only contains alpha-numerics as a test?
     
  3. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    Yep, that was it. We had @ sign in the password, changed to alphanumeric and the problem is resolved :)
     
  4. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    ... though we ran into another problem. It won't build with that error:

    SVN SSL error: SVN host's ServerName value does not match domain in certificate.

    Our svn is hosted on svn.tabascointeractive.com and we're using a wildcard certificate *.tabascointeractive.com. Does it mean wildcard certs are not supported?
     
  5. dannyd

    dannyd

    Unity Technologies

    Joined:
    Jun 3, 2014
    Posts:
    785
    The real problem is it looks like it's a self signed https certificate - which we generally don't support for SVN currently.
     
  6. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    cloudbuild_screenshot.png
    The certificate is definitively not self signed. It's trusted and issued by nazwa.pl. We have no issues with it except for unity cloud build ;-)
     
  7. dannyd

    dannyd

    Unity Technologies

    Joined:
    Jun 3, 2014
    Posts:
    785
    Ya I guess I misinterpreted the warning I got trying to check your svn info on command line: "The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually!"

    Based on the error during building I would assume that we just don't support a wildcard https certificate currently. I don't think this is something we've explicitly tested.
     
  8. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    Is this going get fixed in the foreseeable future?

    It's a proper way to use a certificate so it should be supported.
     
  9. dannyd

    dannyd

    Unity Technologies

    Joined:
    Jun 3, 2014
    Posts:
    785
    Doubtful that we will get to this any time soon. If this is a problem I would suggest switching to an https certificate that strictly matches the svn hosting domain.
     
  10. Gamba

    Gamba

    Joined:
    Feb 8, 2015
    Posts:
    29
    Wow, this thread is timely, I just ran into the same issue as the original topic. We had a @ in our password as well and I removed it but I'm still receiving the same error. Ours is a Perforce server hosted by Assembla
     
    Last edited: Aug 16, 2016
  11. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    This is pretty depressing. We've changed the certifcate to a non wildcard one, but it's still not working.

    Did anyone got it working with svn and https? Was this tested?

    It's pretty shocking as it's no longer beta but a commercial product.

    1: Running Prebuild steps
    2: In quiet period, build will start momentarily...
    3: Agent pid 1180
    4: All identities removed.
    5: Removing bvr
    6: Successfully uninstalled bvr-1.2.12
    7: done.
    8: bvr 1.2.16
    9: bvr-api 0.2.6
    10: prebuildstatus finished successfully.
    11: All identities removed.
    12: Checking out a fresh workspace because there's no workspace at /BUILD_PATH/tabasco-interactive.ninja.default-android
    13: Cleaning local Directory .
    14: Checking out https://svn.tabascointeractive.com/ninja/trunk/4_Implementacja/Unity/Ninja at revision '2016-09-12T06:16:07.764 -0500'
    15: ERROR: Failed to check out https://svn.tabascointeractive.com/ninja/trunk/4_Implementacja/Unity/Ninja
    16: svn: E175002: OPTIONS request failed on '/ninja/trunk/4_Implementacja/Unity/Ninja'
    17: Caused by: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    18: Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    19: Caused by: java.io.IOException: Failed to check out https://svn.tabascointeractive.com/ninja/trunk/4_Implementacja/Unity/Ninja
    20: svn: E175002: OPTIONS request failed on '/ninja/trunk/4_Implementacja/Unity/Ninja'
    21: Caused by: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    22: Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    23: postbuildstatus finished successfully.
    24: Finished: FAILURE
     
  12. Hugues

    Hugues

    Joined:
    Jun 29, 2016
    Posts:
    2
    Hi, it looks like I am in the same situation : wildcard certificate changed to a LetsEncrypt certificate to match the exact server URI and build still failing with an SSLHandshakeException.

    A quick check on ssllabs.com test page with svn.ooblada.com provides all the information on the certificate trust chain and the protocol restriction applied on our server. Does your build system require a specific cipher or protocol version?

    The repository configuration on your dashboard is a simple read only user + password and an URL pointing to the Unity poject folder. I can perform a checkout from our svn server with this user but the unity build system fails with the following logs:

    Running Prebuild steps
    In quiet period, build will start momentarily...
    Agent pid 1197
    All identities removed.
    Removing bvr
    Successfully uninstalled bvr-1.2.12
    done.
    bvr 1.2.16
    bvr-api 0.2.6
    prebuildstatus finished successfully.
    All identities removed.
    Checking out a fresh workspace because there's no workspace at /BUILD_PATH/ooblada-paris.poseidon.default-android
    Cleaning local Directory .
    Checking out https://svn.ooblada.com/CaptainJewel/trunk/CaptainJewel at revision '2016-09-14T07:00:34.017 -0500'
    ERROR: Failed to check out https://svn.ooblada.com/CaptainJewel/trunk/CaptainJewel
    svn: E175002: OPTIONS request failed on '/CaptainJewel/trunk/CaptainJewel'
    Caused by: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    Caused by: java.io.IOException: Failed to check out https://svn.ooblada.com/CaptainJewel/trunk/CaptainJewel
    svn: E175002: OPTIONS request failed on '/CaptainJewel/trunk/CaptainJewel'
    Caused by: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    postbuildstatus finished successfully.
    Finished: FAILURE
     
  13. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    Is this issue getting any attention?
     
  14. drolak

    drolak

    Joined:
    Jan 21, 2014
    Posts:
    49
    After reading Hugues post we also checked our site with ssllabs.com and saw that we didn't have tls 1.1 and 1.0 enabled. We enabled it and managed to get cloud build to do a checkout from our repo.

    So it seems that this resolved our problem.
     
  15. Hugues

    Hugues

    Joined:
    Jun 29, 2016
    Posts:
    2
    From the changes I made you need to allow TLSv1.1 (as well as TLSv1.1 ciphers) for the cloud build to access your server.

    Too bad it was not mentioned in the cloud build tutorials as nowadays anyone trying to harden the security of his server is likely to drop all protocols under TLSv1.2