`add-path` on GitHub Actions is going to be disabled on November 16th
thboop opened this issue · 10 comments
See the blog post for details on why.
It is being replaced by environment variables
Currently, on install, we use the old commands to update the Path, for example (
).This will start failing workflows on GitHub actions, resulting in users trying to install ghc from choco falling their job at that step.
This is also impacting the setup-haskell action, which installs
ghc using choco.
sigh ... If I read that correctly I need to do
echo "{path}" >> $GITHUB_PATH now?
Do you need all packages updated or can I just do the latest versions? i.e. 8.8.4 and 8.10.2. I can't modify existing packages so submitting revisions of all the point releases will cause a versioning mess..
Thanks for taking a look so quickly!
Do you need all packages updated or can I just do the latest versions? i.e.
8.8.4and8.10.2. I can't modify existing packages so submitting revisions of all the point releases will cause a versioning mess..
Ideally all packages updated would be nice so users can manually specify older ones, but if that isn't possible at this time the latest would work well!
echo "{path}" >> $GITHUB_PATH now?
Correct, you need to append the path to the file at the path pointed to by the env variable GITHUB_PATH
If doing it in pwsh, it looks like
echo "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append
I've pushed updated versions of all affected stable releases (3630eb8):
- 8.10.2.2
- 8.10.1.1
- 8.8.2.1
- 8.8.3.1
- 8.8.4.1
They should be available as soon as they go through automated moderation on chocolatey which can take a couple of hours depending on server load.
Packages are available now. Thanks for the report!
I'm not sure if I'm doing something completely wrong here, but the newest versions don't appear to work correctly when I try to use them. Here is the error I get when using GHC 8.10.2.2 (although I also experience the same error when using GHC 8.8.4.1):
Progress: Downloading ghc 8.10.2.2... 100%
Progress: Downloading chocolatey-core.extension 1.3.5.1... 100%
KB2919442 v1.0.20160915 [Approved]
kb2919442 package files install completed. Performing other installation steps.
Downloading KB2919442 64 bit
from 'https://download.microsoft.com/download/D/6/0/D60ED3E0-93A5-4505-8F6A-8D0A5DA16C8A/Windows8.1-KB2919442-x64.msu'
Progress: 100% - Completed download of C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\KB2919442\1.0.20160915\Windows8.1-KB2919442-x64.msu (10.22 MB).
Download of Windows8.1-KB2919442-x64.msu (10.22 MB) completed.
Hashes match.
Installing KB2919442...
ERROR: Running ["C:\windows\System32\wusa.exe" "C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\KB2919442\1.0.20160915\Windows8.1-KB2919442-x64.msu" /quiet /norestart /log:"C:\Users\appveyor\AppData\Local\Temp\1\chocolatey\KB2919442.Install.evt" ] was not successful. Exit code was '1058'. See log for possible error messages.
The install of kb2919442 was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\KB2919442\tools\ChocolateyInstall.ps1'.
See log for details.
Here is the corresponding appveyor.yml file, if that is needed.
That looks like an issue with AppVeyor.. Error 1058 means the Windows installer service isn't running or not responding.
Error 1058: The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.
The core of the issue is that Microsoft have forced the deprecation of older SSL protocols, which leaves older OSes unable to download using https. https://blogs.windows.com/msedgedev/2020/03/31/tls-1-0-tls-1-1-schedule-update-edge-ie11/
Unfortunately while I don't personally care about these OSes and GHC doesn't even run on them I am forced to adhere to the chocolatey rules which validate the packages on older OSes as well.
This forces me for every new package to add a dependency on the Microsoft patch kb2919355 to install support for newer SSL on these OSes.
On modern Windows these would already exist so the installer won't do anything. It would run, detect this and exit. But in this case something went wrong with the AppVeyor configuration.
Now personally I think chocolatey is being stupid here, they should enforce this requirement at install time of chocolatey, not on every package.. but I lost that discussion. So if this is repeatable a bug needs to be files with AppVeyor..
So if this is repeatable a bug needs to be files with AppVeyor..
It definitely appears to be repeatable, as I've restarted the failing builds only to experience the same failures again.
This looks like an AppVeyor issue, they do indeed start with the Windows update service disabled. https://help.appveyor.com/discussions/problems/5616-not-able-to-build-due-to-problem-in-chocolateyinstallps1
adding
- ps: Set-Service wuauserv -StartupType Manual
before running the install should fix it. I really wish I didn't have to add this dependency... but if I "detect" chocolatey and use a non-secure link to get through validation that may get the packages revoked... Need to look into if merely providing a non-https fallback isn't against any rules.
Thanks! I can confirm that the workaround in #10 (comment) works. (See RyanGlScott/code-page@40cce07.)