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

consider nightly support #12

Open
codefromthecrypt opened this issue Jul 8, 2021 · 5 comments
Open

consider nightly support #12

codefromthecrypt opened this issue Jul 8, 2021 · 5 comments

Comments

@codefromthecrypt
Copy link
Contributor

codefromthecrypt commented Jul 8, 2021

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

@slovdahl
Copy link

slovdahl commented Jul 8, 2021

At the moment I'm only interested in DEB packages, so I'm neutral here.

@techpavan
Copy link

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.

@travisgroth
Copy link

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.

@codefromthecrypt
Copy link
Contributor Author

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.

@codefromthecrypt
Copy link
Contributor Author

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.

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

4 participants