Materials API v1 not working with global svn post-commit hook

Issue Type

• Bug Report
• Documentation Report

Summary

We have been using the unversioned material API in combination with a global svn post-commit hook for a long time successfully. With the update to 19.9.0 the unversioned material API has been removed in favor of v1.

I was not able to get our hook running again, since the API is now requiring the exact same repository_url as defined in the cruise-config.xml. In our roundabout 100 pipelines we are not always checking out the root of the repository, but mainly subfolders. How is this supposed to work now? Or is this a bug?

The documentation is lacking information and I think it’s also wrong, as it is talking about the git repository url in the svn section:

repository_url | String | The git repository url as defined in cruise-config.xml or a Config Repo.

Or maybe it’s a misunderstanding?

Basic environment details

• Go Version: 19.9.0
• JAVA Version: 12.0.1
• OS: Linux 4.15.0-64-generic

Steps to Reproduce

Imagine a material svnserver/repo_1/projects/project_1/trunk has been defined in the config xml. The old hook was working fine, as it simply was using the UUID of the repo and did not reference any URL directly:

The old post-commit hook looked like this:

UUID=`svnlook uuid $1`
GOCD_TRIGGER_URL='https://ourServerUrl:8154/go/api/material/notify/svn'
GOCD_USER=ourUser
GOCD_PASSWORD=ourPassword
curl $GOCD_TRIGGER_URL -k \
    -u "$GOCD_USER:$GOCD_PASSWORD" \
    -X POST 
    -d "uuid=$UUID" \
    -H 'Confirm: true'

The new server call only works when using the exact same URL of the Material.

curl https://ourServerUrl:8154/go/api/admin/materials/svn/notify -k -u "ourUser:ourPassword" -H 'Accept: application/vnd.go.cd.v1+json' -H 'Content-Type: application/json' -X POST -d '{"repository_url": "https://ourSvnServer/svn/repo_1/projects/project_1/trunk"}'

It won’t work with https://ourSvnServer/svn/repo_1 solely.

Any help, hint or even workaround is appreciated. Is this works as designed or a bug? Thanks in advance.

Expected Results

Passing the repository URL should be enough, just as before.

Actual Results

Need to provide the exact same URL as used in the config xml, but actually I don’t see how I should determine this exact URL just from a checkin to SVN.

[Keksparade]

Thanks for the advice. Unfortunately it was not that easy as we have multiple URLs mapped to the same UUID (worst case), but we implemented a similar, but more expensive workaround now: For the commit we’re building an according URL of all changed files. Unfortunately, we do not know which is the correct URL to be fired (as defined in the config.xml) so we are doing API calls for all possible URLs. Increases the network load, but at least the correct URLs are fired too.

[rajiesh]

Verified on 19.10.0 (10328-5cb62ca14461d56576551e0bbec2978c909ea9b2)