search

winder / Universal-G-Code-Sender

A cross-platform G-Code sender for GRBL, Smoothieware, TinyG and G2core.
http://winder.github.io/ugs_website/
GNU General Public License v3.0
1.88k stars 762 forks source link

jfrog downloads broken #1884

Closed J-Dunn closed 1 year ago

J-Dunn commented 2 years ago

Version

Other

Hardware / Firmware

GRBL 0.9

What happened

The entire download facility on JFrog is out .

I get a badly formatted page with several panels declaring themselves "healthy with more than one unhealthy source". Nothing is downloadable.

Please fix so that there is a means of downloading the project.

How to reproduce

No response

Operating System

No response

Anything else

No response

breiler commented 2 years ago

Gah, @winder do you mind asking Jfrog again?

breiler commented 2 years ago

@J-Dunn, you can find the binaries under: https://github.com/winder/Universal-G-Code-Sender/releases/tag/v2.0.11

winder commented 2 years ago

Oh no. Thanks for the heads up, contacting jfrog again...

J-Dunn commented 2 years ago

@J-Dunn, you can find the binaries under: https://github.com/winder/Universal-G-Code-Sender/releases/tag/v2.0.11

Thanks for that. Why is this not directly linked here on github? I was clicking everything which seemed logical since I thought there was a download here. Is jfrog a revenue source ?

winder commented 2 years ago

For a long time jfrog has been a convenient service that was provided for free because ugs is an open source project. In the past couple weeks it has been a bit less convenient.

J-Dunn commented 2 years ago

Thanks. Why not just use github like most projects seem to do ? I went to look a jfrog and they seem to spend an enormous effort and meaningless blurb to avoid saying what they are actually about. If I had a project I wanted to distribute, I'd still be no wiser about what they offer. Very strange kind of presentation.

winder commented 2 years ago

@J-Dunn jfrog is definitely an enterprise solution, in the artifact management space they are well known. For UGS, and the features we figured out how to use, it's overkill. If I'm remembering right there were a few reasons I picked it: 1) the current github release storage didn't exist when we were choosing where to put artifacts. There was a much older pre-microsoft release distribution system, but it had been specifically deprecated and removed. 2) back then I really wanted to have an auto-update feature in UGS, which needs more than a simple static binary storage. I tried using sourceforge, which kind of worked, but jfrog was way better. 3) back then UGS had a rolling release model, you basically had the "nightly build", or something really old.

None of these are really true anymore. 1) microsoft seems to want github to be a one stop solution for the entire SDLC, so I would be surprised if this feature goes away. 2) auto-update isn't really a priority anymore. 3) @breiler has completely revamped the release process, and now UGS fits the model supported by github.

J-Dunn commented 2 years ago

Thanks for the detailed explanation. If jfrog is broken , why not just drop it and rely on the archive you already have here which breiler link to?

winder commented 2 years ago

@J-Dunn let's let @breiler weigh in, but in the meantime... want to make a PR to update the links? :)

breiler commented 2 years ago

I don't mind using github as the main release storage. Unfortunately the auto update service will not work, but that is maybe ok.

@winder if you want I can have a look at it?

J-Dunn commented 2 years ago

Where is this autoupdate software? Is this something additional being installed along with UGS?

breiler commented 2 years ago

It is built in to the framework we are using available in the plugins menu:

image

However this requires that you configure an update URL and only work properly with the nightly build: https://groups.google.com/g/universal-gcode-sender/c/GRK8HXwucaA

It is better and more safe to update using versioned builds.

J-Dunn commented 2 years ago

Thanks for the clear explanation. Can I point out there are strong objections to having this kind of thing slipped into software and activated by default , which your link states as the ultimate objective here. Basic system security means having control over what gets installed and KNOWING when that is happening. Also maintaining a reliable system means sticking with what works until you have a reason to upgrade. UGS is far from finished to the point of not having things break on newer versions. That last thing I need is my CNC machine to go down because UGS updated behind my back and there's a compatibility or other bug with the new version.

Bugs in machine control software can be costly and dangerous.

IMO this is a really BAD idea in this kind of application, even if some may think it's "cool" to be able to do automatic updates.

In my personal experience software updates on all kinds of devices are frequently a cause of problems and need to be done at times when manpower, expertise and workload allow for ensuing issues to fixed without highly inconvenient and possibly costly down time.

My approach would be to completely drop this kind of feature. If it is retained, it must NOT be "on by default" and MUST be clearly flagged to the user in the top level presentation of what the software does.

My2c.

breiler commented 1 year ago

I have replaced all download links to use github instead of jfrog. Nightly builds are now done using github actions which will upload to a github release. There is still some work left to do with building real releases though.