Extend rev-version to also update task.json build patch numbers

[jessehouwing]

Right now --rev-version will patch the extension version, but leaves Build task versions alone. It would be lovely if --rev-version would also rev the build task versions.

[T-Hugs]

I wonder if there is an elegant way to do this. Right now TFX doesn't know about build tasks. Maybe add an optional parameter to --rev-version which specifies a file and a JSON path to the version to get revved?

Something like... tfx extension create --rev-version tasks.json:version somethingelse.json:settings.version

Essentially that would rev the version specified in the manifest, as well as tasks.json's "version" property and somethingelse.json's "settings.version" property.

[jessehouwing]

The build tasks unfortunately have a structure to store the version instead of a simple string.

But yes, something generic would work as well. Though it feels a bit strange that tfx doesn't understand the stuff it packages. While I get it, most consumers and task developers don't really follow why tfx doesn't get this simple json structure.

On Tue, 20 Mar 2018, 20:31 Trevor Gau, notifications@github.com wrote:

I wonder if there is an elegant way to do this. Right now TFX doesn't know about build tasks. Maybe add an optional parameter to --rev-version which specifies a file and a JSON path to the version to get revved?

Something like... tfx extension create --rev-version tasks.json:version somethingelse.json:settings.version

Essentially that would rev the version specified in the manifest, as well as tasks.json's "version" property and somethingelse.json's "settings.version" property.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Microsoft/tfs-cli/issues/262#issuecomment-374727842, or mute the thread https://github.com/notifications/unsubscribe-auth/AD-uS2t_j8sI3IdwtHdstWt1_eL7dWEgks5tgVkhgaJpZM4StuCJ .

[calebcartwright]

FWIW - I'd love to have this capability too. On a somewhat related note..

We always ended up having to write custom code in each task repo since tfx didn't have task bumping capabilities and we couldn't find any existing modules that easily supported bumping the task version object out of the box.

We decided to write a custom gulp plugin to provide support for bumping our VSTS tasks, in case that's useful for anyone that wants to bump their VSTS tasks as part of their gulp workflows.

[calebcartwright]

And we've now also published a CLI/Lib - https://www.npmjs.com/package/vsts-bump that can be used for bumping the patch, minor, or major version of VSTS tasks. Not sure if could be utilized by tfx, but we're running the bump cli and then tfx i.e. vsts-bump tasks/**/task.json && tfx [command] which has been working pretty well for us.

[jessehouwing]

Ci/cd tasks for vsts extensions provides support for this as well. I've recently added multi-version task support on top of syncing version numbers.

[calebcartwright]

Nice @jessehouwing! I use the CI/CD tools extension for my own extensions and it works wonderfully.

There were 2 scenarios/use cases where I wished tfx could bump task versions too though (and why we ultimately developed the aforementioned libs):

• The "inner" development loop process: I typically upload all of my custom tasks directly to VSTS as I'm developing to test/validate (even if I ultimately publish them as an extension on the marketplace)
• Private Tasks: at work we have a variety of custom tasks that we don't package as an extension and publish the marketplace, we just use tfx to upload the new versions to our accounts

[praneetloke]

@calebcartwright probably unrelated to this issue, but do you publish your extension straight out of CI? Or, do you do it manually?

Also, I wanted to show support for fixing this issue. The version in the task.json when not bumped along with the version number in the vss-extension.json, it is very confusing, which version of the task the Az DevOps Agent is running. The version number displayed in the agent is actually from task.json, so it can be quite confusing if one hasn't taken care to bump both versions at the same time the updated extension is published.

[jessehouwing]

It's why the Azure devops extension tasks actually overwrite both the task and the extension versions from the CI.

On Tue, 30 Apr 2019, 22:25 Praneet Loke, notifications@github.com wrote:

@calebcartwright https://github.com/calebcartwright probably unrelated, but do you publish your extension straight out of CI? Or, do you do it manually?

Also, I wanted to show support for fixing this issue. The version in the task.json when not bumped along with the version number in the vss-extension.json, it is very confusing, which version of the task the Az DevOps Agent is running. The version number displayed in the agent is actually from task.json, so it can be quite confusing if one hasn't taken care to bump both versions at the same time the updated extension is published.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/tfs-cli/issues/262#issuecomment-488102049, or mute the thread https://github.com/notifications/unsubscribe-auth/AA724S75GJVYJFEFY223RZTPTCTNFANCNFSM4EVW4CEQ .

[praneetloke]

@jessehouwing I am sorry, but I don't follow what you said.

[calebcartwright]

@calebcartwright probably unrelated to this issue, but do you publish your extension straight out of CI? Or, do you do it manually?

@praneetloke - For public extensions that we publish to the marketplace, we use a Release pipeline in Azure DevOps to do the final publishing piece (like our ShellCheck extension for example: https://github.com/swellaby/azdo-shellcheck/blob/master/.github/CONTRIBUTING.md#deployment)

In any repository we have that contains AZP tasks, we always add tfx-cli and vsts-bump as dev dependencies with various npm scripts to leverage those tools. We find this model works best for us as it supports the development process (in particular being able to upload individual tasks as part of the dev loop for validation), and it also gives you a consistent experience to version and package the extension.

Our CI job will leverage those same npm scripts (utilizing tfx-cli and vsts-bump) to bump the various versions and create the .vsix package. Our release pipeline then utilizes the Azure DevOps Extension Tasks extension @jessehouwing referenced to help facilitate a variety of tests against the .vsix, and then finally to publish the .vsix package to the marketplace

[praneetloke]

@calebcartwright thanks for the link to the DevOps Extension Tasks extension! The name is a little confusing, but I get it now.

[jessehouwing]

I've debated so many names... And this was the best I came up with.

On Wed, 1 May 2019, 03:39 Praneet Loke, notifications@github.com wrote:

@calebcartwright https://github.com/calebcartwright thanks for the link to the DevOps Extension Tasks extension! The name is a little confusing, but I get it now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/tfs-cli/issues/262#issuecomment-488171957, or mute the thread https://github.com/notifications/unsubscribe-auth/AA724S6UUSFTY5S2AZZ4ME3PTDYEFANCNFSM4EVW4CEQ .

[pabrams]

The name is just Azure DevOps Extension Tasks. I think he was just confused about the last "extension" word in the original link, which isn't actually part of the name.

[matt-manuel]

Are there plans to add this to the product backlog and try to resolve / fix this? Or is this issue still open pending a decision?

[pabrams]

fix what

[pbcahill]

To fix/enhance --rev-version so it also rev the build task versions (in task.json for example).

[pbcahill]

For those using "Azure DevOps Extension Tasks extension" to bump the version of the extension/tasks - How do you get it to actually bump the version in the repo containing the extension? As it only updates the version in the artifact/code downloaded by the agent and lives in the agent's working directory. Meanwhile the version in the actual repo containing the extension code remains the same. And next time you make a change to the extension and run the pipeline to publish, it errors because it tries to bump the version to the same number it did last time.

[pabrams]

This is just to get around manually bumping the version ourselves, right? Wouldn't we want that step to be manual? Does it have to commit the changes and add a comment, too? I don't think it's a good idea to have release jobs changing source code.

[calebcartwright]

This is just to get around manually bumping the version yourself, right? Wouldn't you want that step to be manual?

--rev-version is an optional flag that users can leverage when they want to automate the version management process. Folks that want to manually manage their versions can of course not use that optional flag.

Are we sure we want tfx to change source files?

In my experience the extension manifest file is always checked into source control, and --rev-version already modifies this file. The ask of the issue is to have the ability to extend this to the task manifests as well, which yes are also in version control, but there wouldn't be anything novel with the ask relative to versioned files given the existing behavior.

Does it have to commit the changes and add a comment, too?

IIRC tfx with --rev-version does not commit, but that's not really the topic at hand nor what's been asked for. Today with current behavior on the extension manifest it's up to users whether or not they want to commit the modified file after running tfx. That would continue to be the case if the requested feature was provided

I do think it's worth noting that the packaging tool for VS Code extensions, vsce, does have optional support to also commit and tag the changes for users that want that in their workflows, but that's a separate topic.

I don't think it's a good idea to have release jobs changing source code.

I wouldn't jump to the assumption that --rev-version is exclusively being executed from a "release" job. There's a lot of scenarios including inner dev loop flows as well as what some might call "build" jobs where it's common to use this feature, but ultimately context matters and the non-default options exist for those that need/want them. Folks that don't want them are free to not use them :smile:

[pabrams]

Usually, though, wouldn't we want our inner dev loop flows to be reproducible as release (deployment) jobs? If we're testing our latest changes, we have to do some kind of deployment, don't we? Anyway, I'm not saying you shouldn't have the feature, necessarily. I do think it's low-priority, though.

[jessehouwing]

The problem with the current behavior of --rev-version is that it yields a new extension version without revving the tasks. Azure Pipelines will therefore not push out the new version to the agents and will cause strange behavior during the dev loop.

What I tend to do is to auto set the version on each commit and publish a dev version so I can easily test in a real agent. I now use a script to do what the rev-version should do and what works for other kinds of extensions that don't include build tasks.

Having rev-version fix the task manifests will make the optional flag work for UI extensions as well as Pipeline extensions.

On Sat, 4 Sep 2021, 08:16 Paul Abrams, @.***> wrote:

Usually, though, wouldn't we want our inner dev loop flows to be reproducible as release jobs? If we're testing our latest changes, we have to do some kind of deployment ("release")*1 don't we?

*1: I personally normally think of "release" as a production deployment, and I think that's the correct

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/microsoft/tfs-cli/issues/262#issuecomment-912917598, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA724S7QQU5RH2DDO2W26NTUAG2STANCNFSM4EVW4CEQ .