Add machine readable description of platforms

[hasheddan]

What would you like to be added:

A machine-readable file describing the platforms (OS / architecture) that each binary is expected to be released for (xref kubernetes/sig-release#1360).

Why is this needed:

This description will allow krel to perform checks on produced artifacts and make sure that the artifacts that are intended to be released actually are being released.

/assign

[hasheddan]

@justaugustus @saschagrunert thinking about this a little more, I wonder if it may make sense for this to live in k/k. Krel theoretically should be able to run a release for any project, so it seems the project itself should indicate the artifacts that it intends to be released. This could be a standard that we define for "krel-releasable" projects, in which case maybe we add that standard in this repo and then add an implementation in k/k. Thoughts?

[hasheddan]

@dims in case you have any thoughts on this as well :)

[hasheddan]

This could also be related to #1819 if we want to have a formal specification.

[dims]

@hasheddan it would make sense to reach out to @swinslow from LF to have a chat as it looks like there is scanning to SPDX that's being done:
https://github.com/lfscanning/spdx-cncf/tree/master/kubernetes/2020-02

Also related:
cncf/foundation#6

The license exceptions granted by CNCF for non-standard licenses are also in SPDX:
https://github.com/cncf/foundation/blob/master/license-exceptions/README.md

[hasheddan]

Thanks @dims! This looks pretty important in regards to the BOM effort, but I am not sure it directly relates the list of supported platforms that we intend to release

[saschagrunert]

Krel theoretically should be able to run a release for any project,

krel stage/release is tightly scoped to Kubernetes, so it seems fine to me to stick to k/release. I can imagine that we have an API for checking binaries of different formats (like elf) against a set of criterias (like ABI or ISA). This could be re-used by other projects, too.

[dims]

whoops! sorry my head was still in the BOM :) @hasheddan

[hasheddan]

krel stage/release is tightly scoped to Kubernetes, so it seems fine to me to stick to k/release.

@saschagrunert this is definitely true today, but some of the original discussion when krel was started was around moving towards more generally applicable tooling, which I think could influence this decision if we still have that goal.

[saschagrunert]

@hasheddan I see your point. From a usability perspective, would it be better if the definitions live in k/k? Let's say we add/remove a binary, then it probably would make more sense for developers to modify the definition in k/k.

On the other hand: Let's assume that SIG Release owns the definitions. It's easier for us to change it in k/release rather than modifying k/k which might lead into a release blocker.

[hasheddan]

@saschagrunert @justaugustus I am leaning towards something like a .krel.yml file in repos that krel releases. I think we should add an API in the form of Go structs in k/release that defines the schema for declaring binaries / images that should be produced. We could start with a kubernetes.krel.yml in k/release and test this out for a while before moving it to k/k, how does that sound?

[saschagrunert]

how does that sound?

Sounds good to me! 👍

[fejta-bot]

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-contributor-experience at kubernetes/community.
/lifecycle stale

[fejta-bot]

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-contributor-experience at kubernetes/community.
/lifecycle rotten

[puerco]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[palnabarun]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/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.