Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update paths should be improved #1415

Open
Confectrician opened this issue Sep 18, 2022 · 8 comments
Open

Update paths should be improved #1415

Confectrician opened this issue Sep 18, 2022 · 8 comments

Comments

@Confectrician
Copy link

After facing the latest extended JFrog outage, we already changed the manual download urls on the openHAB website.
They now point to files we have uloaded in the release notes of this repository.
Reference: openhab/website#357

We have also removed the explicit bintray and jfrog references via #1271 already.
This was done with netlify redirects. (https://docs.netlify.com/routing/redirects/ and https://docs.netlify.com/routing/redirects/redirect-options/ for reference)
Our websites redirects those urls to the explicit jfrog artifactory path, which prevented us from configuring a simple workaround during the jfrog outage.

Therefore i would suggest the following steps for getting this a little bit more stable in the future.

  1. Change the update paths here to a basic scheme
    I would suggest adapting to the url scheme from github releases
    Runtime => https://www.openhab.org/download/releases/TARGET_VERSION/openhab-TARGET_VERSION.zip
    Addons => https://www.openhab.org/download/releases/TARGET_VERSION/openhab-TARGET_VERSION.kar
    (With this we could also skip the milestone check in the update script aside.)
  2. Adapt the corresponding redirects in the website repo with the next release
  3. Add some explicit version based redirects to jfrog to prevent breaking updates of currently installed versions
@wborn
Copy link
Member

wborn commented Sep 18, 2022

Did you also consider configuring Netlify to proxy to another service instead of redirecting?
That would allow for hiding where the original files are downloaded from and it would allow for using the Netlify or Cloudflare CDN.

@Confectrician
Copy link
Author

Confectrician commented Sep 18, 2022

Did you also consider configuring Netlify to proxy to another service instead of redirecting?

That would be possible too, of course.
I am not bound to any of the possible ways to solve this personally.

My main goal is to be independent, when we want/must adapt something.
A well choosen base path combined with either of the technics would be feasable for this in my vie. :)

@Confectrician
Copy link
Author

I have filed openhab/website#360 which should already solve 3., since it already maps JFrog paths to GitHub.

@kaikreuzer is working on uploading the needed files for stable releases from 2.5.12 an and the milestones for 3.4.0.

@kaikreuzer
Copy link
Member

I have uploaded all but version 3.0.0, which is for some reason missing on JFrog...

@wborn
Copy link
Member

wborn commented Sep 19, 2022

It was probably only released to Bintray. These artifacts are still available on Maven Central, see:

https://repo1.maven.org/maven2/org/openhab/distro/openhab-addons/

@kaikreuzer
Copy link
Member

Ah, cool, thanks. Now 3.0.0 is uploaded as well. 😇

@wborn
Copy link
Member

wborn commented Sep 19, 2022

I also added openhab-addons-legacy-2.5.12.kar for completeness.

@wborn
Copy link
Member

wborn commented Oct 9, 2022

It would also be nice if these artifacts are also automatically uploaded during a release. I.e. you can no longer use the www.openhab.org download URLs in builds triggered by the release pipeline. I had to change the download URLs back to openhab.jfrog.io in the Docker container build because of this (openhab/openhab-docker#407).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants