-
Notifications
You must be signed in to change notification settings - Fork 165
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
Bump build api from v1alpha1 v1alpha2 #676
Bump build api from v1alpha1 v1alpha2 #676
Conversation
@matthewmcnew Could you have a look? This takes the "dumb" bumping of #555 and #669. So the PRs could rebase and focus on needed changes to the api. Could this be a way forward? WDYT? |
bc2541f
to
75ebbd7
Compare
Codecov Report
@@ Coverage Diff @@
## main #676 +/- ##
==========================================
+ Coverage 68.54% 69.42% +0.87%
==========================================
Files 93 117 +24
Lines 4130 5069 +939
==========================================
+ Hits 2831 3519 +688
- Misses 951 1184 +233
- Partials 348 366 +18
Continue to review full report at Codecov.
|
Note: After 0.3.0 is released, we'll review all changes and copy them to the next api version. |
276e01e
to
20026f8
Compare
@matthewmcnew @tomkennedy513 As discussed in the last community meeting, this is the follow up on #675 |
582022b
to
e3f2848
Compare
bda567d
to
530df24
Compare
|
||
type stepModifier func(corev1.Container) corev1.Container | ||
|
||
func (b *Build) BuildPod(images BuildPodImages, secrets []corev1.Secret, taints []corev1.Taint, config BuildPodBuilderConfig) (*corev1.Pod, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we delete the equivalent of these domain methods in v1alpha1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right I guess. I have removed them, but in a separate commit. So it is easier to revert again. I can squash it, once this is ready to merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually we'd like to keep them to minimize the manual effort when doing a version bump. Also we should not touch old versions to not break existing code (maybe deprecate the methods instead).
I am a bit concerned about the proliferation of api versions and the added complexity introduced with multiple conversions/etc. I wonder if similar to tekton we should jump to v1beta1 or introduce v1alpha1 as unstable "testing" version before ultimately releasing it as a stable api in v1alpha1. I'll add it to the agenda as this would be a great topic to rediscuss during working group. |
530df24
to
16e215c
Compare
There is definitely some complexity coming with having more versions. But on the other hand, adding new features like #669 #555 or #670 and going from
Thanks. |
I'd argue that alpha is the right stage to start practicing versioning of CRDs. Once something is |
16e215c
to
bbd4fc6
Compare
bbd4fc6
to
58d7679
Compare
- Bump Build CRDs (copy v1alpha1) - Change buildapi import alias to v1alpha2 - Adapt documentation how to bump build api Co-authored-by: Benjamin Haegenlaeuer <benjamin.haegenlaeuer@sap.com> Co-authored-by: Ralf Pannemans <ralf.pannemans@sap.com> Co-authored-by: Johannes Dillmann <j.dillmann@sap.com>
58d7679
to
73d4c18
Compare
Thanks @c0d1ngm0nk3y! |
This only introduces the api version
v1alpha2
with no changes yet.This is based on #675
This PR would be the common base for #555 and #669 which both introduce incompatible changes.