Issue #1186: Fix release issue

[katelynienaber]

Proposed changes

Fix for the mismatching GH/VSIX releases described in issue #1186

Release Notes

Milestone:

Changelog:

Types of changes

What types of changes does your code introduce to Zowe Explorer?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Updates to Documentation or Tests (if none of the other choices apply)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This checklist will be used as reference for both the contributor and the reviewer

• I have read the CONTRIBUTOR GUIDANCE wiki
• PR title follows Conventional Commits Guidelines
• PR Description is included
• gif or screenshot is included if visual changes are made
• yarn workspace vscode-extension-for-zowe vscode:prepublish has been executed
• All checks have passed (DCO, Jenkins and Code Coverage)
• I have added unit test and it is passing
• I have added integration test and it is passing
• There is coverage for the code that I have added
• I have tested it manually and there are no regressions found
• I have added necessary documentation (if appropriate)
• Any PR dependencies have been merged and published (if appropriate)

Further comments

NOT working WIP :D

[katelynienaber]

@zFernand0 I just tried something, it will probably not work...could you let me know if I am on the right track?

Generally I'm trying to compare the version from the most-recently created release tag, to the version in the new package.json...and I swapped out the old staged files check for this new release version check.

[zFernand0]

I just tried something, it will probably not work...could you let me know if I am on the right track?

You sure are!
Sounds like comparing the top-level package.json#version (which would've changed on a Version-Bump PR) against the existing GH Release Version sounds like a big-brain idea! 😋

Seems like this might just work! 👍

[katelynienaber]

@zFernand0 Do you know how we could test it? Should we just try it on the next release?

I am not super familiar with these commands, I'm worried there might be some syntax error that will cause it to not work as expected.

[zFernand0]

Do you know how we could test it? Should we just try it on the next release?

We can certainly try on the next release.
In the meantime we can verify that the publishing flow makes sense, with either of these options:

1. Only update top level package.json#version and the pipeline takes care of updating all other version numbers.
2. Disable the deployment.yml from being triggered by a package.json change and just allow a manual workflow_dispatch using the input (e.g. 1.19.0)

[zFernand0]

TL;DR: LGTM! 😋
Thanks for changing the base of the PR!
I do think these changes will get the deployment workflow further than what it gets today.

[jellypuno]

@katelynienaber Why is multi-select changes added here?

[zFernand0]

multi-select?

[katelynienaber]

@jellypuno @zFernand0 Don't know how I did that -.- The extra edits have been reverted, please give it another look >.>

[zFernand0]

should we open the other PR to update all package.json#version numbers?

[katelynienaber]

@zFernand0 Yeah we can do that, off master branch?

[jellypuno]

should we open the other PR to update all package.json#version numbers?

That would be part of the release PR. @lauren-li will open that