Hi,
I followed this guide and was successfully able to publish an extension. However, I have a question around the installed task updating itself after I've published an update to the extension.
Please follow along:
placeholder description.actual description. The manage extension pages tells me its already shared with my organisation.placeholder descriptionI read about bundling multiple versions but I'm really after pushing minor updates / bug fixes to the current major version and was hoping it would auto-update it for the organisations that have installed.
Hope this makes sense? Looking forward.
Thanks,
@ClydeDz
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Hi @ClydeDz, Please accept my apology for our delayed response. We're glad you were able to successfully publish your extension! I've assigned this issue to a PM and writer, so one of them should be in touch soon with an answer to your question. Hope you're having a great day.
Hi @ClydeDz, Please accept my apology for our delayed response. We're glad you were able to successfully publish your extension! I've assigned this issue to a PM and writer, so one of them should be in touch soon with an answer to your question. Hope you're having a great day.
I got the same problem, could you please kindly, provide the solution publicly.
many thanks
Hi , is this actually a bug ? I faced the same issue as well. Had to de-install and re-install the extension from the marketplace for the new version to be taken in account in my pipeline. Thanks.
Hi, I am facing the same issue. I can see in the Organization Settings that the extension has been updated, but when I try to use it in the pipeline, I cannot find the way to use the new version.
Thanks
We are also facing this issue. Adding / removing tasks from an extension does seem to be reflected when publishing the extension (provided the extension version was also upped). besides the fields description (which OP wrote about) also name and friendlyname field changes and adding / removing task inputs appear not to be reflected when updating them and publishing them as part of an extension.
i Initially thought this to be a caching issue on my local browser, but even clearing the cache or asking another user to check the task seem to give the same result.
Hi, I was able to fix the issue updating the task version in task.json file before creating a new extension version.
When you run the command tfx extension create --manifest-globs vss-extension.json --rev-version it just updates the version number in the vss-extension.json file, but it doesn't change it in the task.json. So what I did is first update the task.json version with the new one and then run the command.
I hope this helps you too.
Thank you for the update, @ClydeDz, and for sharing your fix. I'll follow up with the PM to determine an update to the article. I hope this works for others, as well. If you do have further issues, please contact Support. Thank you!
@ClydeDz 's solution did not work for me. Is there another way to fix this?
Hi @jordynniara, I'm sorry it didn't work for you. Please contact Support. Thanks and best of luck to you.
Why is this issue closed? @ClydeDz never actually gave a solution like @chcomley is saying. The only thing was what I consider a workaround provided by @brianfleibenzon (_which works_) although it's a pain to always bump this task.json patch version manually in order to see our changes to the task reflected when developing a task. I'm not saying it should update automatically when the task is actually public, but when it's private and under-development it's time consuming to iterate quickly on the task.
It is really confusing that the Azure Extension portal in my organisation is actually showing that the extension was updated, but pipeline using the task are stuck to previous version until the task.json version is changed OR I uninstall and reinstall the task everytime.
Hello all, I suppose I figured the workaround sufficed when it was closed back in August, not sure. I've reopened this issue and have an engineer looking into it as we "speak." Thanks for speaking up, @eric-labelle. @jordynniara, curious whether you contacted Support and what may have come from it?
Thanks @brianfleibenzon for posting the solution that you need to update the version number in task.json as well on the tfx command line. Clearly having to specify the version in two places is confusing and should not be necessary. I will check to see why we have this requirement. @ClydeDz does that work for you?
Following up on this - @ClydeDz, are you interested in @edglas1's findings? Please do let us know. @edglas1, how do you believe we could clarify this within the article? Thanks.
The command tfx extension create --manifest-globs vss-extension.json --rev-version is updating the patch version of the AzDo extension (can have several tasks), but not the patch version of the custom task/tasks (task.json). I think, that the new version of the custom task is not fetched by the AzDO organization, because it doesn't find a new version and the --rev-version switch can not specify which task has been changed. So, the behaviour is probably by design.
I have a simple script, which sets the patch version to the build number. With that, I make sure, that the version of the task.json changes after each code change.
@eric-labelle: I am avoiding the waiting time by uploading the task directly into AzDO organization (only while developing). For that, I am using the tfx command tfx build tasks upload --overwrite --task-path "myPathToTheTask" --service-url "https://myOrg.visualstudio.com/DefaultCollection" --auth-type pat -t "xxx". And the custom task is even faster available if you first deletes the task (be careful. This deletes versioning and a short downtime is present). Then you can directly run automated integration tests. If everything is fine, I am deploying the task to the publisher.
@andreasschild Can you please let us know the status of this? Has this issue been properly taken care of? Thanks!
Thank you @andreasschild for this command, first time I've heard of it.
It would worth mentioning on the guide as it is A LOT more convenient to develop and test new tasks or next task iteration. One thing that I don't get though.. assuming my V0 has 2 input parameters, I then upload a V1.0.0 with 3 inputParameters, the Pipeline classic editor displays the dropdown to choose between V0 and V1, but either version now has the 3 input parameters. I would have expected V0 having 2 parameters, and V1 having 3 parameters. Do you know why is that?
The only way I can think to bypass this is to upload V1 with another GUID to keep them separate until Published to marketplace as a multi-version task.
Make sure to mention in the guide the pat requires only "Agent Pool" permission as it is probably one of the last I guessed while trying this command. Or simply link to https://github.com/microsoft/tfs-cli/blob/master/docs/buildtasks.md. I wish I had seen this months ago!
Hi,
I am also facing the same issue. For me, i had already updated the task versions as well to match with extension version, but still the users have to uninstall and install the new version.
Also, if they have existing pipelines, they will have to again add the tasks because now they have changed from @1 to @2. Should these things not happen automatically?