-
Notifications
You must be signed in to change notification settings - Fork 4
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
consider nightly support #12
Comments
At the moment I'm only interested in DEB packages, so I'm neutral here. |
Currently I am attempting POCs in my local and thus interested in DEB packages. Post this phase, would be looking for RPMs. Interested in nightly because some features in development are being utilized. For official usage in future, stable would be considered. |
We're primarily interested in binaries of official releases for supported platforms; we do our own packaging. Nightlies aren't part of our development process, currently. Neutral to this feature. |
ok I'm seeing slight interest and no one against, so far. I'm not going to be voting on this personally, but will implement this if another 2 people have interest. There is care and feeding and some build risk involved in doing this. |
one of the issues here is that unless we start our own pipeline here, nightlies will be limited to what envoy upstream does: windows and linux In fact it would be a daily capture of the "latest" docker tag (or corresponding sha) which is sometimes updated multiple times per day. End impact is this wouldn't help os/x users unless we find or create a build here. So, this would be inconsistent if folks were looking to try on mac and also linux the same code. |
right now, we archive the following:
We could consider doing nightlies, by over-writing a release tag daily (or nightly :P) and generating this URL
This would work via automation via scraping binaries from nightly tags of docker images until official tarballs exist. Versions would be overwritten to control cardinality, size and ease maintenance. You would know if a version is updated because the checksum and date changes.
Ex. https://archive.tetratelabs.io/envoy/download/v1.18.3_nightly/envoy-v1.18.3_nightly-linux-arm64.tar.xz
Whatever versions we do will stop getting nightlies when it stops being possible to archive them (ex via EOL, image disappearing, some reason technical or otherwise outside our control). you could only check the date in func-e output or the versions json to know when they were last updates.
Note: this will not effect official package repositories that replace getenvoy rpm and debian packages. This repo is not an official repo, it is an archive of binaries. We are not doing system packages anymore because they will be done officially. This would only tools that use our permalinks to archives via envoy-versions_nightly.json (notably func-e)
Anyway, should we do it?
If you would personally use this, both thumbs-up this issue and also comment why you need nightlies, how would you use them (ex via func-e or custom use of the json), and for what version and platform matrix.
If you want this to not exist, both thumbs-down and mention why not.
cc'ing end users who made comments related to nightlies on the now archived getenvoy-package repo @techpavan @travisgroth @gdubicki @slovdahl @aalmekhlafi0 @karimlakhani @rrondeau @jamiees2 @alexclarkofficial @jamiees2
The text was updated successfully, but these errors were encountered: