The remote server returned an error: (404) Not Found.

[mamdouht]

Hi, I am trying to use "Version Number Counter" Extension in release pipeline but i am getting this error message in the Log:

Invoking rest method 'Get' for the url: https://vsrm.dev.azure.com/OrgName/ProjName/_apis/build/builds/20?api-version=4.1.

##[error]The remote server returned an error: (404) Not Found.

[maikvandergaag]

Hi,

Whats happens if you are logged in try to open the url in the browser.

Possible problems can be:

• The configuration of the account that is used to get the builds

[mamdouht]

Hi,

Thanks for the quick reply.

If i open the link from the browser i get the same error, 404.

could you please clarify "The configuration of the account that is used to get the builds"?

Do you mean the PAT used in "Azure DevOps Personal Access Token" parameter? This has full access.
I am using the extension inside release pipeline, which is getting the artifact from another build pipeline.

[mamdouht]

@maikvandergaag Kindly any ideas?

[maikvandergaag]

If the browser has the same problem, you have something misconfigured. What are the configured values of the extensions.

[mamdouht]

under release pipeline this is how i have it configured:

and the PAT has full access

Under Organization Settings/Extensions there is only disable and uninstall.

is there somewhere else?

[maikvandergaag]

Hi mamdouth,

Could you share your organization and project name, maybe it is something in how the url is configured.

Why the url is returning a not found. Maybe also the configuration what is shows in your url bar when navigating to the build page.

[mamdouht]

sure,
here is the link from the log:
https://nstudioz.vsrm.visualstudio.com/Sawah/_apis/build/builds/32?api-version=4.1.

its getting the the correct name for project and the organization.

you may noticed that its using the legacy link different from what i sent above
(this was from my attempts hoping that the New link or Legacy link has any effect)
both ended with the same result.

Here is my latest log:

[maikvandergaag]

I'm seeing some strange behavior within the extension. We are using it at a client of ours and it works there as expected.

The problem is with the uri. I have tested this uri: https://dev.azure.com/nstudioz/Sawah/_apis/build/builds/32?api-version=4.1 and this seems to work as I get a 404. The Uri it self is build within the extension from an environment variable, it looks like that is still gets the old URL value. How do you have your organization configured?

[mamdouht]

The URI: " https://dev.azure.com/nstudioz/Sawah/_apis/build/builds/32?api-version=4.1 "
worked for me.

i reverted to the old URI as shown below (previous post was with this option checked)
this link work (removed "vsrm" from it.
https://nstudioz.visualstudio.com/Sawah/_apis/build/builds/32?api-version=4.1.

I have tried the extension with both options
(new [https://dev.azure.com/nstudioz/....] and Legacy [https://nstudioz.visualstudio.com])

[maikvandergaag]

Are you using a hosted build agent?

[mamdouht]

Sorry i missed your reply,
Yes i am using Hosted Build agent

[DannySe]

Having the exact same issue here. Link works from browser if vsrm is removed from it. Is there some configuration missing in connection with the release management?

[maikvandergaag]

Know it can become interesting :). Could you both tell me which agents you are using for the release or build.

The url is retrieved from the environment variables of the agent

[DannySe]

I am using Hosted VS2017 agent

[maikvandergaag]

I'm also using the hosted vs2017 agent with no problems. How is your environment configured url wise?

[DannySe]

So the url that the extension is trying to use is

https://vsrm.dev.azure.com/{organization}/{project}/_apis/build/builds/222?api-version=4.1.

This one does not work in the browser. After some research it seems however that the "/build/builds/" part should be replaced by "release/deployments" for a release API. So the following link works for me in the browser:

https://vsrm.dev.azure.com/{organization}/{project}/_apis/release/deployments?api-version=4.1

Is this something your script gets from the agent configuration or is it always going the build/builds path, even if the vsrm-prefix is being added to the base-url?

[maikvandergaag]

The path comes from the agent configuration. I have it running at three customers at this moment without any problems.

I'm looking on how to get an equal situation for this but haven't been able to encounter this situation.

Could you tell me which url you are using and how old the environment is.

[DannySe]

The environment is relatively new, it has been set up a couple of months ago. The url that the extension tries to use is the one I gave above (just with {organisation} and {project} replaced with the actual data). Here it is:

https://vsrm.dev.azure.com/{organization}/{project}/_apis/build/builds/222?api-version=4.1.

I think the difference might be that you are running it in a build pipeline and we do it in a release pipeline. In the source code it looks like you are always using the "build/builds" path and are only talking to the Build-API. The moment the task is added to a release pipeline it does not work anymore, since the agent environment variable "SYSTEM_TEAMFOUNDATIONSERVERURI" in a release job is set to return a Release Base-URL (same thing, but with a vsrm prefix). So the GET-Request can only work if you are using the Build Base-URL.

The variable is a read-only, so we can not set it to anything else. According to the documentation, you can use System.TeamFoundationCollectionUri instead, if you want to be talking to the Build-API from the Release Pipeline.

[maikvandergaag]

Hi guys, totally true!

Extension was build for build pipelines, I did not remove the support for the release pipeline. I will update the extension to only work on build pipelines. And mark this as a feature request.

[maikvandergaag]

Sorry for the late response due to some personal stuff I haven't been able to proccess this hope to be able to do this in august