search

kliment / Printrun

Pronterface, Pronsole, and Printcore - Pure Python 3d printing host software
GNU General Public License v3.0
2.34k stars 995 forks source link

CI actions not working as expected #1427

Closed rockstorm101 closed 1 week ago

rockstorm101 commented 1 month ago

Latest release did not trigger neither Windows nor macOS apps builds. I believe the following change might help but can't really test GitHub actions. Might have been my bad because I created the tag before the release and I used to do both things at the same time.

on:
  push:
  pull_request:
  release:
    types:
-      - created
+      - published

Also something needs fixing regarding the uploading to PyPI. Last attempt threw the following error. I'll contact @kliment see if we can work something out.

25hWARNING  Error during upload. Retry with the --verbose option for more details. 
ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/        
         User 'kliment' does not have a verified primary email address. Please  
         add a verified primary email before attempting to upload to PyPI. See  
         https://pypi.org/help/#verified-email for more information.
kliment commented 1 month ago

Account on pypi is now verified

DivingDuck commented 1 month ago

Upload_pypi runs after re-run the job. Maybe we need to re-run all jobs once more?

DivingDuck commented 1 month ago

I couldn't resist and re-run all job's with debug information activated. It seems everything runs fine except uploading to upload_pypi (what I have expect). It looks like one of you need to restart the job.

https://github.com/kliment/Printrun/actions/runs/9245207731/job/25486667830, log#3, Line 92 + 93

##[debug]Using a user-provided API token for authentication against https://upload.pypi.org/legacy/
Warning: Trusted Publishers allows publishing packages to PyPI from automated environments like GitHub Actions without needing to use username/password combinations or API tokens to authenticate with PyPI. Read more: https://docs.pypi.org/trusted-publishers

and line 174 to 177

25hWARNING  Error during upload. Retry with the --verbose option for more details. 
ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/        
         File already exists. See https://pypi.org/help/#file-name-reuse for    
         more information.
kliment commented 1 month ago

You're trying to upload the same version you already uploaded. It will fail by design.

rockstorm101 commented 1 month ago

Second attempt at building and uploading the wheels did run fine. So everything is up to date now on PyPI. So that bit is fixed. We'll see on next release whether the actions that build the Win/macOS apps work flawlessly.

DivingDuck commented 1 month ago

How did you attach the files? I missed that step

rockstorm101 commented 1 month ago

How did you attach the files? I missed that step

I had to do that manually I'm afraid 🥲

khipp commented 1 month ago

The binary for macOS 11 is missing from the 2.1.0 release. Has support been dropped, or will it still be added?

DivingDuck commented 1 month ago

@khipp, Indeed, we removed macOS11 from the build and I can't remember why. Can you please test this build below and report back?

https://github.com/DivingDuck/Printrun/actions/runs/9286412163

I will post a new PR for the workflow if the macOS-11 version is working for you.

Best regards, DD

khipp commented 1 month ago

@DivingDuck Thanks. Unfortunately, I don't have a way to directly test the binary for macOS 11. I could only trigger the CI test if the binary is added to the release assets.

rockstorm101 commented 1 month ago

Indeed, we removed macOS11 from the build and I can't remember why.

Removal of the macOS 11 build occurred as part of PR #1407. Allegedly, the Python wheels produced using macOS 11 and macOS 12 runners where identical. So I guess the app/zip was thought to be identical as well for both and therefore one could be removed. If that's not the case, it would be super easy to reinstate the build.

Please forgive my ignorance here, can you run the macOS 12 app/zip currently released on a macOS 11 system?

khipp commented 1 month ago

Please forgive my ignorance here, can you run the macOS 12 app/zip currently released on a macOS 11 system?

I reran the tests for macOS 11 by substituting with the binary for macOS 12. No issues were reported (see run).

DivingDuck commented 1 month ago

Removal of the macOS 11 build occurred as part of PR #1407.

Ah, I forgot that. This makes sense.

khipp commented 1 month ago

The Homebrew installation script has been updated to only use the macOS 12 version going forward. Thanks, everyone!

rockstorm101 commented 3 weeks ago

What are your thoughts on reinstating the macOS 11 to avoid people thinking we dropped support?

neofelis2X commented 3 weeks ago

Currently the release file is called printrun-2.1.0_macos-12_x64_py3.10.zip I guess you could avoid this confusion by omitting the 12 and just name it: printrun-2.1.0_macos_x64_py3.10.zip

Also, Printrun still supports python 3.8? The _py3.10 in the name might make people think they need that particular version.

rockstorm101 commented 3 weeks ago

Currently the release file is called printrun-2.1.0_macos-12_x64_py3.10.zip I guess you could avoid this confusion by omitting the 12 and just name it: printrun-2.1.0_macos_x64_py3.10.zip

Also, Printrun still supports python 3.8? The _py3.10 in the name might make people think they need that particular version.

Please forgive my ignorance regarding macOS stuff. Currently the CI runner uses macOS 12 and python 3.10 to build the macOS app. Could this application be run on say macOS 11 with Python 3.8? My current understanding is the OS version does not make a difference but regarding Python it doesn't work "backwards". So maybe we need to build with Python 3.8 instead? And as you suggest, remove the bits about OS and Python versions.

DivingDuck commented 3 weeks ago

Also, Printrun still supports python 3.8?

Yes, this is the latest version where we can support binaries for 32 bit Windows in combination with module pillow. Having the python version was in the past helpful to identify compatibility problems in some modules like wxpython.

A question I had in the past was, is it somehow possible to identify how many downloads we had for all different OS packages we offer? This is maybe helpful to know.

For macOS12 vs 11 I'm unbiased. We should at least wrote in the description that it support macOS 11 and 12. ☺

neofelis2X commented 2 weeks ago

Please forgive my ignorance regarding macOS stuff.

No ignorance at all! :) OS: Yes, so it seems it is backwards compatible to macOS 11. And it definitely works from 12 to all the way to the latest macOS 14.5. python: I was a bit confused for a moment, but pyinstaller actually packages up the python version it is used with. So the user doesn't even need to have any python installed. No need to change the build of the macos release to py3.8. :)

I honestly do not have a strong opinion how the naming should be. But changing macos-12 to macos makes sense to me.

An by the way, GitHub will deprecate the macos11 runner: The macos-11 label has been deprecated and will no longer be available after 28 June 2024.

is it somehow possible to identify how many downloads we had

This website outputs some stats about the downloads. Pretty interesting. https://somsubhra.github.io/github-release-stats/?username=kliment&repository=printrun&page=1&per_page=5

DivingDuck commented 2 weeks ago

Yes indeed. Hadn't expect so much downloads in such a short time frame. Only Linux is a black box. Here are some additional information from PyPi I found yesterday: https://pypistats.org/packages/printrun

rockstorm101 commented 2 weeks ago

Thank you both for those links. So interesting. Can't get my head around how someone other than GitHub/PyPI has access to information that (in my mind) is only available within GitHub/PyPI servers XD

OS: Yes, so it seems it is backwards compatible to macOS 11. And it definitely works from 12 to all the way to the latest macOS 14.5. python: I was a bit confused for a moment, but pyinstaller actually packages up the python version it is used with. So the user doesn't even need to have any python installed. No need to change the build of the macos release to py3.8. :)

Awesome, thanks. Let's remove those from the file name then. And last but not least, I guess the architecture bit must be kept as 'x64'. Or would the app work on apple chips too?

Having the python version was in the past helpful to identify compatibility problems in some modules like wxpython.

Agreed. I would only remove those on the "release" files but keep the full name with all its bits for the nightly/testing ones as proposed in #1432

neofelis2X commented 2 weeks ago

I guess the architecture bit must be kept as 'x64'. Or would the app work on apple chips too?

pyinstaller produces an intel binary at the moment (x86_64) and it works on the arm apple chips because of the rosetta2 translation layer. That is okay, no need to change anything. If you want to, tho, you could try set up an arm64 runner and produce a native binary for this platform. ;) Or maybe I test it on my repo, when I have some time left.