"Url field is blank, please supply one. (url)" when changing/adding/reenabling hook

Issue #43 resolved
c v created an issue

On bitbucket server 5.2.2 (on Linux), I seem unable to modify this hook, getting "Configuration error! Url field is blank, please supply one. (url)" immediately after saving. Even resaving an previously existing hook fails with that error. Disabling an existing hook works, but when I try to enable, I get the same error. I was able to create a new hook once in a test repository, but other attempts at creation failed, including after deleting and recreating the repository.

Tcpdump doesn't show any traffic going to the remote server from bitbucket.

Comments (22)

  1. Jan Thiel

    Same here. Plugin stoped working out of nothing. You can enter totaly valid data into the form and submit it. After clicking "Save" an empty(!) AJAX Call goes out to the server:

    Request URL:https://XXXXXX/settings/hooks/de.aeffle.stash.plugin.stash-http-get-post-receive-hook%3Ahttp-get-post-receive-hook/enabled
    Request Method:PUT
    Status Code:400 
    

    But the call is empty. It doesn't submit any data.

    Strange thing: Debugging the JS showed that there is some data submitted within the "data" keys of the AJAX JS call hierachy...

    Within the Bitbucket Access Logs:

    xx.xx.xx.xx,127.0.0.1 | https | o@XXXXXXXXX| XX@xxxx.abcd | 2017-08-21 23:59:45,421 | "PUT /rest/api/latest/projects/MIP/repos/immoportal-gravityforms-openimmoxml/settings/hooks/de.aeffle.stash.plugin.stash-http-get-post-receive-hook%3Ahttp-get-post-receive-hook/enabled HTTP/1.0" | "https://XXXX/settings/hooks" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36" | 400 | 2 | 102 | - | 10 | xxxxxx |
    

    And nothing at all within the Logs...

    Left me with no clue?!

    Would be glad to see any ony having any idea how to fix this :-/

    Uh, yea, some side Infos:

    Running on Latest Bitbucket Server. We recently migrated from 4.something to 5.2.1. After the migration we just re-enabled all the Hooks but did not face any issues. It is running on Unix behind a reverse nginx proxy.

    //Edit: And I would suggest to elevate this as "Blocker" as the Hooks aren't usable anymore. The existing ones do work, but that's it. No edit, create or such.

    Thx

    Jan

  2. Alexander Renteln

    So, the problem is, that the static js file is not being injected in the settings.hooks context... with the js in place everything works fine...

    So the following stopped working - due to some changes from Atlassian...

        <web-resource key="stash-http-get-post-receive-hook-resources"
                      name="HTTP Request Post-Receive Hook Default Web Resources">
            <context>stash-http-get-post-receive-hook</context>
            <context>bitbucket.page.repository.settings.hooks</context>
            <dependency>com.atlassian.auiplugin:ajs</dependency>
            <resource type="download" name="stash-http-get-post-receive-hook.css"
                      location="/css/stash-http-get-post-receive-hook.css"/>
            <resource type="download" name="stash-http-get-post-receive-hook.js"
                      location="/js/stash-http-get-post-receive-hook.js"/>
            <resource type="download" name="images/" location="/images"/>
        </web-resource>
    

    I'll fix it right away.

  3. Alexander Renteln

    By the way, I'm thinking about changing the configuration all together... I'm not very happy with the current settings/configuration screen... and also i want to support project level configs :-)

    anyways, at least this bug is fixed now

  4. Jan Thiel

    @aeffle I sadly still encounter the issue. Have upgraded the Add-On to 4.3.5 and also upgraded Bitbucket Server to 5.2.3 to rule out anything here.

    Any ideas?

    Thanks, Jan

  5. Sven Schliesing

    Having the same problem after upgrading to 5.3.0. If there's anything that I can help you with just let me know.

  6. Alexander Renteln

    it's totally crazy: if you do the same url a second time, it actually works :-/

    After opening the configuration, the first click on save will trigger a HTTP PUT call to "...hook/enabled" with an empty request payload. The second time save is clicked, the same HTTP call is triggered - this time with payload...

    So it's probably some JS bug...

  7. Jan Thiel

    I already tried this a lots of times. We have two configurations per repository and I wasn't able to get anything saved at all after the bitbucket upgrade to 5.3. Even worse existing Configs get deleted after saving.

    Maybe something to report to Atlassian?

  8. Alexander Renteln

    yeah, maybe asking some Atlassians might be a good idea. I'lll do some more tests and if I don't get it fixed, I'll just introduce an extra menu-point in the settings and a servlet which renders the same config... just as a quick fix.

    I'm using the soy/closure templates maybe a little bit too excessive ... I include templates inside the main config template plus I have some extra javascript - which also pulls some more soys... :-)

    Anyway, sorry, that I didn't take time to fix it earlier...

    To have a quick fix, you can always to the HTTP PUT request manually to the webhook, if that helps...

  9. Sven Schliesing

    Quickfix for me was to manually edit the configuration in the database. Not nice, but better than nothing.

    Keep up the good work! I would gladly support you if I knew any Javascript. ;)

    PS: Maybe you could adjust the compatiblity settings in the market place listing accordingly? So others will be warned if they check the addon compatibility before they upgrade.

  10. Alexander Renteln

    @all: I just released a version which should fix the bugs...

    fingers crossed :-)

    let me know how it goes :-)

  11. Log in to comment