No task definition found

[gimoteco]

I installed this extension and setup my build process to use a s3 upload task, when i try to run it's displayed this message to me:

No task definition found matching id 3a219265-181c-4ed2-9a51-75a7f308f0d5 and version 1.0.22. You must register the task definition before uploading the package.

I tried to reinstall several times, nothing happened. I'm using AzureDevOps

My release log https://gist.github.com/gimoteco/f97ee9fe6ba4d44a72c41d0fe6ec415e

[stevejroberts]

Task ids haven't changed so I don't immediately see why an install should cause issues, unless you had one of our pre-release versions (pre 1.0 anyway) installed.

Current version is 1.1.6 - can you try uninstalling, then reinstall and a fresh build definition to see what happens?

[PhantomMachine]

I'm using Azure DevOps as well and am running into the same issue. I've tried tasks in both a build & release pipeline but still hit this issue. I've verified that I am installing 1.1.6, and have tried the suggestion of reinstalling and trying a fresh build definition. Still, the error persists.

[ebekker]

Same issue, this is with a fairly new DevOps account, and installed the latest AWS Tools. I even uninstalled and re-installed, looks to be 1.1.7 now. Here is the exact message:

No task definition found matching id 3a219265-181c-4ed2-9a51-75a7f308f0d5 and version 1.0.22. You must register the task definition before uploading the package.

[ebekker]

FYI, I posted the issue to the DevOps community forums and MSFT has indicated the issue is with the extension(s).

[ebekker]

Some more info, hopefully helps narrow the problem. The issue I'm having above is with a new DevOps account, roughly 2-3 weeks old. I tried to test out the S3 extension with another DevOps account, that's been around for > 1 year, and the extension worked perfectly.

One thing I noticed between the two instances during initial task setup in the Release pipeline, in the newer (broken) org, when selecting the region for the task, the drop-down has no entries (so I manually typed in us-east-1). But when I configure the task in the older (working) org, the drop-down contains the "friendly" display names of the regions, so I selected N. Virginia (equivalent of us-east-1).

Seems whatever is broken is broken pretty early in the task setup process, not just at runtime on the agent.

[stevejroberts]

Confirmed the task id is still present in the codebase for this task in v1.1.7 and as noted, I don't know of any change to our task ids since the v1.0 release (as that would be a breaking change). I'm a little confused by the error message you showed above, after you uninstalled and then installed 1.1.7 -

No task definition found matching id 3a219265-181c-4ed2-9a51-75a7f308f0d5 and version 1.0.22.

I don't understand why it still shows v1.0.22 here - I'd have expected v1.1.7. In conjunction with the region dropdown's friendly names missing (these were added in v1.1.0 a couple months back) it doesn't look to me as though in the failing account it really installed 1.1.7. When you uninstalled, what process did you follow?

Also, when you spoke to Microsoft did they indicate if there was any logging available during the install process that might give some clues (I've never found any myself, but am always in hope).

[stevejroberts]

One other thing I just noticed when attempting to repro on a new DevOps organization is that in the task list when constructing a build pipeline our task icons are now no longer showing up. May or may not be related but I'm beginning to wonder if there haven't been some changes in the DevOps environment since Microsoft's rebranding that we've not been aware of. I hope not, as we still need to support TFS 2017 users too.

[ebekker]

So regarding the version number, if you look at the task.json file, you see that the version of the task is indeed 1.0.22:

    "version": {
        "Major": "1",
        "Minor": "0",
        "Patch": "22"
    }

I assume that tasks (and perhaps other components) of an extension package are individually versioned, and the 1.1.7 is the version of the comprehensive extension package.

[ebekker]

I've tried the extension out on several DevOps instances now, a few of them were preexisting and a few that I just created (literally in the last 24 hours). Across those, I've played around with differences across different dimensions (e.g. different ways of "getting to" the Marketplace extension, whether they're AD based authentication or not, toggling various features in the org settings).

The only difference I can see that determines whether the extension works or not is whether it was created in the last couple of weeks (after the DevOps rebranding), in which case it's broke, or whether it preceeded the rebranding, in which case it works.

I also noticed the task icons are missing sometimes and was going to point that out, but then I found that didn't necessarily correspond with a broken org or not, i.e. I have one org where the extension works, but the icons are still missing. It may be a caching issue in this case, but I didn't dive into it.

[ebekker]

Regarding Microsoft's input -- you can see the post for yourself, it's in the public forums. As you can see, they essentially resolved it as not their problem, and closed the post. I can't even post follow up comments at this point, having to post additional notes as "proposed solutions" which makes it very awkward, and I suspect no one from their team will even see the follow up posts.

[stevejroberts]

We stamp all our tasks with the same version as the overall package version, so you should have seen 1.1.7 in the task file too (I just confirmed this is indeed the case still with the vsix I downloaded from the marketplace to cross-check the expected icons were present).

I'm following up with an internal Microsoft contact to see what I can find out.

[ebekker]

The code doesn't lie (unless this isn't the code that's published to the markeplace). In fact even the overal extension manifest (vss-extension.json says it's 1.0.22.

The only thing that reads 1.1.7 is this _versioninfo.json file.

[stevejroberts]

The code is the same as what's on the marketplace. The extension and task manifest files get updated with the final version from the _versioninfo.json file during our marketplace release build. We don't commit those changes back to the source. We used to update the overall package version and task files in the source we committed prior to the build but this got tedious after a while and got in the way of the commit history showing the actual changes.

Is the version you have installed not from the marketplace?

[stewart-southwell]

I just want to mention that I am also having the same issue with a new instance using the extension from the marketplace.

I am going to try with my older instance to see if it works.

[stevejroberts]

@stewart-southwell thanks for letting us know, and please let us know how you get on with your older instance (which I assume has some older version of the tools installed?).

On the missing icons issue, turning on network tracing in the browser shows the icon request is going to a url based on version 1.0.22 - even though the installed task manifest file is stamped with version 1.1.7. For me this affects both new and existing accounts. We (me and Microsoft) are still investigating and will update the issue further when we have more news.

[ebekker]

@steveataws -- I did install the extension from the Marketplace every time.

So it seems the static version number that's in the base source files is actually leaking into the Marketplace files, so I'm guessing that the manifest files are no longer getting updated in your release build.

Alternatively, if you're still seeing the right version in some scenarios coming out of the Marketplace, could there be 2 alternate streams of the extension depending on the target platform it is being installed to (e.g. on-prem VSTS/DevOps vs the cloud-based DevOps)?

[ebekker]

So the missing icons issue is consistent with the other behavior. Microsoft has re-opened the thread in the community forum after a few other people have chimed in to confirm they're seeing the same behavior.

[stevejroberts]

1.0.22 appears nowhere in the files contained in the vsix file on the marketplace (at least the version I just downloaded and scanned) so it's a mystery why this is getting included in resource paths. That version was the last before the August '18 update that took us to v1.1.0, a few weeks before the Azure DevOps rebranding took place.

It's possible we need to add some extra target to indicate compatibility with the latest DevOps server which, if not present, causes it to fall back to an older pre-rebrand version but I don't see what yet. The current target, Microsoft.VisualStudio.Services, should indicate compatibility with both according to what I'm reading here.

If the system is forming urls to the task, just as for icons, and for whatever reason locking to 1.0.22 that would go some way to explain why the S3 task isn't found on accounts where the tools have not been installed previously.

[ebekker]

Just to be clear, it doesn't look to be isolated to just the S3Upload task, at least one other person has commented in the forum post, they're having issues with BeanstalkDeployApplication and I also tried with a couple other tasks, S3Download and the AWSCLI task. They all fail with the same message, just different GUIDs referenced in the error message corresponding to the appropriate task manifest ID.

[stevejroberts]

Yep, I'd seen that.

[stevejroberts]

Ok, I think I've isolated the issue to the version in the manifests getting captured somewhere in the build process. The first build stage, ahead of testing, keeps the version in the manifest file. Post testing we then take the vsix and stamp the new version throughout the files and digitally sign it prior to upload. So even though the released vsix doesn't contain the older version label something somewhere is aware of it that then proceeds to louse things up.

I'm going to put a new build onto test overnight and if successful we'll get this released to the marketplace asap.

[ktice12]

Any update on this?

[stevejroberts]

1.1.8 was quite literally just released to the marketplace. You might need to uninstall, then install to get it to be picked up immediately (that's what I had to do in my Azure DevOps test environment).

I'll leave the issue open until tomorrow in case any further issues are found.

[ktice12]

@steveataws did you run into this error when trying to reinstall by chance?

The task definition with id '081ccf10-2f14-48dd-9bd0-892b8975d24f', name 'AWSCLI' and version '1.1.8' already exists.

[PhantomMachine]

I just tried 1.1.8 with the S3Upload and was glad to see that it worked.

[stevejroberts]

@ktice12 we saw that on a couple of our organizations, we think because we'd installed builds from different publisher ids (same task ids). Our guess some caching was being done. It looks like publisher id is not taken into account when determining the unique id. You shouldn't have had 1.1.8 installed though (we obviously did) so I'm not sure exactly why you see that message.

Our solution was to blow away the test organizations and start afresh to verify new-install and upgrade (from 1.1.7) installs but I guess this won't work for you. I'm not sure how to force the environment to forget about an uninstall completely, unlike TFS there doesn't seem to be an extra process to clean out the local marketplace. When you uninstalled, did the listing go away completely from your extensions list? We had a couple of orgs where we had to do the uninstall multiple times too before it really took effect.

[ktice12]

@steveataws it's very weird. I am showing no extensions installed under "Manage Extensions", BUT all the AWS features are showing in my release pipelines (and I'm assuming its the latest version as well because I can actually see the icons now). I'm wonder if I somehow timed up the uninstall with the update and the unistall never actually happened (even though it isn't showing in my extensions). I guess I will just run with it and see what happens but it looks to work fine even though it says I don't have the extension installed.

[Alvatron1]

@ktice12 we are seeing the same "already exists" error on 2 separate organizations

[ebekker]

I can confirm the fix is now working in my setup. One thing to note, I had previously removed the old version of the extension (1.1.7) from my instance about one day back, so if the "already exists" error is cache-related, it was pby already cleared before I installed the 1.1.8 version.

[ebekker]

Also, I had a few other test orgs that I had setup during the testing of the scenarios, some old (pre-rebranding to DevOps) and some new. And I can say that for all of them, the update to 1.1.8 "just worked" and I went in there and was able to configure pipeline tasks with the updated AWS extension and they were all successful across all orgs.

[Alvatron1]

I've also reported the problem with Microsoft. I'm hoping that they can do something on the backend like @steveataws mentioned earlier by cleaning out the local Markitplace. We did have a remedy in TFS, ADOPS, not so much.

[gimoteco]

Now it`s working perfectly, thank you for helping

[stevejroberts]

I'm not seeing any new issues directly related to the tools in the period since we released 1.1.8 so am going to close this issue as resolved.