/AzurePipelines run

/AzurePipelines run

trying to close and re-open because the only thing that has change between this and our last release is the guids.

Whether this issue is the problem create by the nushell maintainers or not, I'm honestly sick of the user experience of this repo. Not trying to disparage the maintainers and people here that support this and work so hard. It's just my viewpoint as a user. I have to essentially duplicate parts of this ci just to see what the error message is and it's a horrible experience watching it fail release after release after release with very little discernible error messages.

I run our msi on my desktop and it works fine. I run our msi in a Windows 11 sandbox and it fails with 1603. I then have to do something like msiexec /i "C:\Users\WDAGUtilityAccount\Desktop\Downloads\nu-0.86.0-x86_64-pc-windows-msvc.msi" /l*v c:\temp\insta.log just to get a log to see what's happening. Then it takes a msi-rocket scientist to figure out what all that gibberish means.

I really wish there was a better way to get releases into winget for our users. I'm sorry for being spicy about all this.

I have an idea, but it still needs to be verified: Would it be less error prone if we chose exe files instead of the MSI files? Because MSI requires an installation process

Automatic Validation ended with:

Installation failed with exit code -1978335226
2023-10-17 12:07:08.236 [CLI ] ShellExecute installer failed: 1603
CAQuietExec: Error 0xc0000135: Command line returned an error.
CAQuietExec: Error 0xc0000135:
QuietExec Failed
CAQuietExec: Error 0xc0000135: Failed in ExecCommon method CustomAction ReplacePathsInWindowsTerminalProfile returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Property(S): ErrorDialog = ErrorDlg
MSI (s) (10:D4) [12:07:07:950]: Product: nu -- Installation failed.
MSI (s) (10:D4) [12:07:07:950]: Windows Installer installed the product. Product Name: nu. Product Version: 0.86.0. Product Language: 1033. Manufacturer: The Nushell Project Developers. Installation success or error status: 1603.

• 1603 often indicates a missing dependency.

Manual Validation ended with:

Hi @fdncred,

Do you know of a new dependency or other condition to install this version?

I have an idea, but it still needs to be verified: Would it be less error prone if we chose exe files instead of the MSI files? Because MSI requires an installation process

Hi @hustcer,

This is an interesting theory, but unfortunately I don't have the time to gather the data. It might be possible to pull this from historical PRs, or it might be preferrable to collect new data by measuring equal packages in fresh VMs. If you decide to pursue this, please feel free to keep us informed.

Hi @fdncred,

Do you know of a new dependency or other condition to install this version?

I worked on it for 2 hours today and recreated the same log that you mentioned.

The wix file that generates the msi hasn't changed in four months. Our ci changes pretty frequently. No idea if that's causing a problem.

I'm just guessing, but it may have something to do with writing to c:\programdata. Although the last release had no problems with that.

This winget ci has always been super brittle for nushell.

/AzurePipelines run

@stephengillie Thanks for your help and support.

We had to make the CI look like this

    - name: Setup Rust toolchain and cache
      uses: actions-rust-lang/setup-rust-toolchain@v1.5.0
      # WARN: Keep the rustflags to prevent from the winget submission error: `CAQuietExec:  Error 0xc0000135`
      with:
        rustflags: ''

instead of this

    - name: Setup Rust toolchain and cache
      uses: actions-rust-lang/setup-rust-toolchain@v1.5.0

That's it. I have no idea what rust flags are there by default nor what the rust flags are what stops our msi from installing.

@fdncred, you're quite welcome. That's a very interesting change to your CI - I have no idea that Rust was involved under the hood. Seems like it's everywhere these days. Happy hacking!

Publish pipeline succeeded for this Pull Request. Once you refresh your index, this change should be present.