Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support version upgrade for MSI packages #1764

Closed
wants to merge 7 commits into from
Closed
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions tools/packaging/windows/aws-otel-collector.wxs
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,12 @@ SummaryCodepage='1252'
InstallScope="perMachine"
Platform="x64"
/>

<MajorUpgrade
AllowDowngrades="no" DowngradeErrorMessage="A later version of ADOT Collector is already installed. Setup will now exit"
AllowSameVersionUpgrades="yes"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to set this to no. As we don't usually look after the fourth version field and may not be useful setting.

'''
This is useful when two product versions differ only in the fourth version field. MSI specifically ignores that field when comparing product versions, so two products that differ only in the fourth version field are the same product and need this attribute set to yes to be detected.
'''

Copy link
Contributor

@bryan-aguilar bryan-aguilar Jan 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After reading the docs for this field here, I am wondering if this is the correct solution. I do not think we should be in a situation where we need to perform upgrades for the same version. We also do not use the fourth version field. Would a viable solution, which also may be required anyways, be to ensure that this version field is upgraded before each collector release?

I think a time when this COULD happen would be if the end user was building their own windows packages. This would cause the same version to be different. This should never be true for our official released assets MSIs though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think this doc could be relevant here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that is a good point. My initial thinking after reading the docs was on updating release version after each CD trigger. But it looks to be tricky as this needs to be passed as a env variable while running this file. We use the cached msi packages from successful CI run which are then used by our CD workflow. So one possible solution is to rebuild the MSI package during our CD workflow to make sure we have access to the version parameter.

This approach needs a bit of refactor, so I temporary set AllowSameVersionUpgrades="yes" to make sure customers can upgrade the collector even-though all the release versions are tagged at 0.0.1.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vasireddy99 looping you in for the comment you left above

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think updating the version should be a step in the release process before triggering the CD. It may have to be done manually or the bump-version-create-release-note script could be updated. I created an issue here to track this requirement.

/>

<MediaTemplate EmbedCab="yes"/>

<Feature Id="ProductFeature" Title="ADOT Collector" Level="1">
Expand Down