Comments (38)
Unfortunately the script itself is also internal-only since it runs internal-only commands. This doesn't get us any closer to a process that non-Googlers can run, but it should help us get packages out more promptly in the meantime.
from sig-release.
@timothysc We are slowly moving toward something like that model with triggered staged releases. Not every build, but builds that pass the "release blocking" test set being staged and ready to release.
from sig-release.
Who is going to work on this?
from sig-release.
Any volunteers?
cc @kubernetes/sig-cluster-lifecycle-feature-requests @kubernetes/sig-release-feature-requests @kubernetes/sig-testing-feature-requests
from sig-release.
So here is my conundrum, we need a couple of people to own this, with at least one person being a non-googler... and by own, I mean they will maintain it across at least 2 releases to ensure the automation is better than what we do today.
from sig-release.
I don't know what's the best way to create a yum repo, but will look for something useful
createrepo
(see e.g. http://www.rightbrainnetworks.com/blog/using-amazon-s3-as-a-hosted-yum-repository/).
from sig-release.
It appears we do not have anyone stepping up on this. What is the best way to widen the net? These deliverables are an important part of the product we deliver during releases.
from sig-release.
I can try to work on the rpm side of things.
from sig-release.
I agree with @timothysc's assesment. There's some significant unglamorous legwork that needs to get done here. I'll speak on Debs since RPMs seem to be covered.
Initially and potentially until the project stabilizes we will need to host our own apt repos. Reason for this: Debian self defines their stable channel as containing stable and well tested software, which changes only if major security or usability fixes are incorporated. They are very strict about this. If we got kubeadm in debian 9, it would have to be the same kubeadm version forever. We could only bump the version when debian 10 is released.
I'd like to bring deb build into our make release but that's gated on multi-platform bazel builds which is O(week or two) away. We could do the same with rpms but I don't know if that is desirable. At that point we will be able to publish raw debs to GCS. Then (a pretty big then) someone needs to build the publishing/signing pipeline.
from sig-release.
I looked at https://www.aptly.info/ once upon a time. Might be useful for debs.
from sig-release.
Also note:
There are currently 10 CNCF projects. Many of them have similar needs to us as far as OS packaging solutions. Let's see if we can kill 10 birds with one stone.
from sig-release.
Ideally with the maturing of atomic installation we could create a single container for *RPM installations backed this mechanism. The idea of curating our own RPM channel on this side-jiggery is odd.
/cc @jasonbrooks
from sig-release.
Is there any remote chance we could test automating these artifacts in the upcoming v1.8.0-alpha.3 release on 8/23?
from sig-release.
We need someone who is going to own maintenance of the packaging and I can work with them on it.
from sig-release.
A reminder that we once again had to rely on someone cutting these manually for v1.8.0
@abgworrall did .debs, @pipejakob did .rpms
from sig-release.
from sig-release.
I planned on talking with @pipejakob in more detail on the next sig-cluster-lifecycle mtg about this.
from sig-release.
Any chance this will get traction for 1.9?
from sig-release.
I recently started getting familiar with the internal docs for this process, and it currently requires Google-internal commands. That likely means we'd have to port it to public infrastructure as a prerequisite to automating the steps in an open-source tool (anago). @pipejakob can correct me if I'm wrong.
As a middle ground, I'm going to see about automating via an internal script, and/or spreading around expertise in this process. I also want to clarify who's responsible for publishing the packages. Ideally it should be the branch manager, but that wasn't the case when I was the branch manager for 1.6. @jdumars Who did it for 1.8?
from sig-release.
@abgworrall and myself split the debs/rpms for the 1.8.0 release for expediency.
from sig-release.
@pipejakob Do you think it's too much work for one person? Or is it just that you wanted to minimize latency since it happens after the release already went out?
For 1.9, I'd like to absorb responsibility for pushing debs/rpms into the official release team (i.e. the branch manager, @dashpole) so it's under our full control, although we'll need help learning from those who've done it before. Does anyone have objections to that?
from sig-release.
@enisoc Ideally I want every build to look-like a release, except someone gets to push to the stable repo. I'd like to talk about this topic if it's an agenda item for sig-release.
from sig-release.
I've now got a prototype for the "middle ground" automation I mentioned above in #10 (comment).
This at least reduces the push process to one command per release, but it still relies on Google-internal tools. If you're a patch manager who's interested in trying it, let me know.
from sig-release.
Great, thanks @enisoc! Is that coming as a PR to kubernetes/release or is it internally only?
from sig-release.
@enisoc No worries, thanks for improving the internal process meanwhile, will greatly reduce the time-to-pkg-publish metric :)
from sig-release.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
from sig-release.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale
from sig-release.
/remove-lifecycle rotten
from sig-release.
/sig release
/sig cluster-lifecycle
from sig-release.
Has there been any progress in automating this in anago?
With kubernetes/kubeadm#803 & kubernetes/test-infra#8020 I'm improving an e2e test that we'll put in all branch-specific sig-release-1.X-all
dashboards (like: https://k8s-testgrid.appspot.com/sig-release-1.10-all) and the master-blocking tab (https://k8s-testgrid.appspot.com/sig-release-master-blocking), for more visibility in case someone forgets to push the packages.
from sig-release.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
from sig-release.
/remove-lifecycle stale
from sig-release.
/lifecycle frozen
from sig-release.
@timothysc We chatted about this in a couple of different contexts at KubeCon Seattle, does SIG Cluster Lifecycle have resources to commit to this for the v1.14 release cycle?
from sig-release.
Yes, the tracking issue for execution is here - kubernetes/kubernetes#71677
We will need to PR here to remove some of the behavior.
from sig-release.
/priority important-soon
/area release-eng
/milestone v1.15
from sig-release.
Closing in favor of kubernetes/release#631
/close
from sig-release.
@justaugustus: Closing this issue.
In response to this:
Closing in favor of kubernetes/release#631
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
from sig-release.
Related Issues (20)
- Cut v1.26.13 release HOT 3
- Cut v1.30.0-alpha.1 release HOT 5
- Cut v1.x.y-{alpha,beta,rc}.z release HOT 1
- Kubernetes v1.30 Major Themes contact HOT 4
- Release Manager access for @mehabhalodiya
- Cut v1.30.0-alpha.2 release HOT 4
- Cut v1.29.2 release HOT 3
- Cut v1.28.7 release HOT 2
- Cut v1.27.11 release HOT 2
- Cut v1.26.14 release HOT 3
- Cut v1.30.0-alpha.3 release HOT 5
- Fix hyperlinks in 1.30 release markdown
- Cut v1.30.0-beta.0 release HOT 6
- Cut v1.29.3 release HOT 3
- Cut 1.28.8 release HOT 4
- Cut 1.27.12 release HOT 5
- Cut 1.26.15 release HOT 2
- Cut v1.30.0-rc.0 release HOT 8
- Update publishing-bot for release-1.30
- Cut v1.30.0-rc.1 release HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sig-release.