[BUG] flytectl upgrade is broken after moving to the monorepo

[eapolinario]

Describe the bug

The command itself is broken and also unit tests are failing with:

--- FAIL: TestUpgrade (0.29s)
    --- FAIL: TestUpgrade/Successful_upgrade (0.29s)
        upgrade_test.go:53: 
            	Error Trace:	/home/runner/work/flyte/flyte/flytectl/cmd/upgrade/upgrade_test.go:53
            	Error:      	Expected nil, but got: &errors.errorString{s:"unexpected EOF"}
            	Test:       	TestUpgrade/Successful_upgrade
        upgrade_test.go:54: 
            	Error Trace:	/home/runner/work/flyte/flyte/flytectl/cmd/upgrade/upgrade_test.go:54
            	Error:      	"" does not contain "Successfully updated to version"
            	Test:       	TestUpgrade/Successful_upgrade
Flytectl rollback is not available on windows 

 A new release of flytectl is available: v0.2.20 → v1.12.0 
https://github.com/flyteorg/flyte/releases/tag/v1.12.0 

time="2024-05-15T19:23:52Z" level=info msg="Initialized Mock Clientset"
--- FAIL: TestSelfUpgrade (0.02s)
    --- FAIL: TestSelfUpgrade/Successful_upgrade (0.02s)
        upgrade_test.go:116: 
            	Error Trace:	/home/runner/work/flyte/flyte/flytectl/cmd/upgrade/upgrade_test.go:116
            	Error:      	Expected nil, but got: &errors.errorString{s:"unexpected EOF"}
            	Test:       	TestSelfUpgrade/Successful_upgrade
time="2024-05-15T19:23:52Z" level=info msg="Initialized Mock Clientset"
time="2024-05-15T19:23:52Z" level=info msg="Initialized Mock Clientset"
time="2024-05-15T19:23:52Z" level=info msg="Initialized Mock Clientset"
time="2024-05-15T19:23:52Z" level=info msg="Initialized Mock Clientset"
time="2024-05-15T19:23:52Z" level=info msg="Initialized Mock Clientset"
--- FAIL: TestSelfUpgradeRollback (0.00s)
    --- FAIL: TestSelfUpgradeRollback/Successful_rollback (0.00s)
        upgrade_test.go:145: 
            	Error Trace:	/home/runner/work/flyte/flyte/flytectl/cmd/upgrade/upgrade_test.go:145
            	Error:      	Expected nil, but got: &errors.errorString{s:"flytectl backup doesn't exist. Rollback is not possible"}
            	Test:       	TestSelfUpgradeRollback/Successful_rollback
FAIL	github.com/flyteorg/flyte/flytectl/cmd/upgrade	0.387s

Expected behavior

The upgrade command should either work or be removed. I can see an argument for removing it, since we have other means of upgrading (e.g. on the mac we can use brew upgrade flytectl).

Additional context to reproduce

No response

Screenshots

No response

Are you sure this issue hasn't been raised already?

• [X] Yes

Have you read the Code of Conduct?

• [X] Yes

[runllm[bot]]

The issue with the flytectl upgrade command breaking after the monorepo migration is known. The error traces indicate issues with unexpected EOF and missing backups for rollback. This is likely due to changes in the repository structure and dependencies.

Would you like more details on potential fixes or workarounds?

Sources:

• https://github.com/flyteorg/flyte/issues/4305
• https://github.com/flyteorg/flyte/issues/1233
• https://discuss.flyte.org/t/16022712/hey-folks-i-m-trying-to-update-our-go-repositories-using-the/

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @runllm to ask follow-up questions. See runllm.com for more!

[eapolinario]

The work here has to do with how to list flytectl releases from the monorepo and use that list of releases as opposed to all releases.

More specifically, we use https://github.com/mouuff/go-rocket-update to provide this self-upgrade functionality, the issue is that when we check the releases this library ends up calling a github API that doesn't return the flytectl releases (which use git tags of the form flytectl/vX.Y.Z).

Resolving this issue will require some investigation. Here are some ideas:

1. implement a new provider that understands flytectl releases (similar to how we do in https://github.com/flyteorg/flyte/blob/31802c730ca92305cfdf42ea558fec9639f171f2/flytectl/pkg/github/githubutil.go#L76)
2. use the zip provider (given that we download the new release separately).

[novahow]

#take

[novahow]

@eapolinario Hi, I investigated the issue and implemented a new provider. I'm curious about how flytectl upgrade used to work before moving to monorepo? because according to https://github.com/flyteorg/flyte/blob/25c35961f7d39b75868c0cad312984d73aa245ae/flytectl/cmd/upgrade/upgrade.go#L122 latest infers smth like "v0.8.20", and stdlibversion.Version is the version tag of flyte, which may be "v1.12.0" . How did this comparison work before the monorepo migration?

[eapolinario]

latest infers smth like "v0.8.20", and stdlibversion.Version is the version tag of flyte, which may be "v1.12.0" . How did this comparison work before the monorepo migration?

before the monorepo migration, stdlibVersion was the current version of flytectl as defined here. Notice that the before the move to the monorepo this referred to git tags of the flytectl repo.