Remove support for windows builds

[tomkennedy513]

With windows support removed from the lifecycle we have no way to build windows builders.

related discussion #1366

[tomkennedy513]

Should we blow up if someone tries to create a builder for a windows stack? Along the same line, should we blow up if a build tries to happen on an existing builder that is windows based?

[sambhav]

does this mean we can use the core project provided lifecycle images now?

[tomkennedy513]

does this mean we can use the core project provided lifecycle images now?

We have to make a few more changes to use them directly. @natalieparellano has most of a pr adding support for that if you want to help drive it over the line

[jjbustamante]

I believe, after merging this PR we can close the following issues #1131 and #1333, right? @tomkennedy513

[tomkennedy513]

Should we blow up if someone tries to create a builder for a windows stack? Along the same line, should we blow up if a build tries to happen on an existing builder that is windows based?

Added an error and test case if the stack is windows

[chenbh]

We also need an RFC PR for this, mainly so that we can mark https://github.com/buildpacks-community/kpack/blob/main/rfcs/0003-windows-images.md as superseded/reverted

[tomkennedy513]

We also need an RFC PR for this, mainly so that we can mark https://github.com/buildpacks-community/kpack/blob/main/rfcs/0003-windows-images.md as superseded/reverted

Good call

[chenbh]

What do you think about removing the OS field from the BuilderStatus? I'm on the fence as I don't seem much harm either way

kpack/pkg/apis/build/v1alpha2/builder_types.go

Lines 70 to 80 in f5c8a87

	type BuilderStatus struct {
	corev1alpha1.Status `json:",inline"`
	BuilderMetadata corev1alpha1.BuildpackMetadataList `json:"builderMetadata,omitempty"`
	Order []corev1alpha1.OrderEntry `json:"order,omitempty"`
	Stack corev1alpha1.BuildStack `json:"stack,omitempty"`
	LatestImage string `json:"latestImage,omitempty"`
	ObservedStackGeneration int64 `json:"observedStackGeneration,omitempty"`
	ObservedStoreGeneration int64 `json:"observedStoreGeneration,omitempty"`
	OS string `json:"os,omitempty"`
	SignaturePaths []CosignSignature `json:"signaturePaths,omitempty"`
	}

[tomkennedy513]

What do you think about removing the OS field from the BuilderStatus? I'm on the fence as I don't seem much harm either way

kpack/pkg/apis/build/v1alpha2/builder_types.go

Lines 70 to 80 in f5c8a87

	type BuilderStatus struct {
	corev1alpha1.Status `json:",inline"`
	BuilderMetadata corev1alpha1.BuildpackMetadataList `json:"builderMetadata,omitempty"`
	Order []corev1alpha1.OrderEntry `json:"order,omitempty"`
	Stack corev1alpha1.BuildStack `json:"stack,omitempty"`
	LatestImage string `json:"latestImage,omitempty"`
	ObservedStackGeneration int64 `json:"observedStackGeneration,omitempty"`
	ObservedStoreGeneration int64 `json:"observedStoreGeneration,omitempty"`
	OS string `json:"os,omitempty"`
	SignaturePaths []CosignSignature `json:"signaturePaths,omitempty"`
	}

Ya I left it because it didn't seem like it caused harm, but if it's only ever going to be Linux, then it probably can be removed

[tomkennedy513]

What do you think about removing the OS field from the BuilderStatus? I'm on the fence as I don't seem much harm either way

kpack/pkg/apis/build/v1alpha2/builder_types.go

Lines 70 to 80 in f5c8a87

	type BuilderStatus struct {
	corev1alpha1.Status `json:",inline"`
	BuilderMetadata corev1alpha1.BuildpackMetadataList `json:"builderMetadata,omitempty"`
	Order []corev1alpha1.OrderEntry `json:"order,omitempty"`
	Stack corev1alpha1.BuildStack `json:"stack,omitempty"`
	LatestImage string `json:"latestImage,omitempty"`
	ObservedStackGeneration int64 `json:"observedStackGeneration,omitempty"`
	ObservedStoreGeneration int64 `json:"observedStoreGeneration,omitempty"`
	OS string `json:"os,omitempty"`
	SignaturePaths []CosignSignature `json:"signaturePaths,omitempty"`
	}

Ya I left it because it didn't seem like it caused harm, but if it's only ever going to be Linux, then it probably can be removed

@chenbh One issue is that it's technically a breaking change in the api if we remove it