November 22, 2021 Community Meeting

[SaschaSchwarze0]

• Please add a topic in this thread and add a link to the Github issue associated with the topic.
• Please make sure you give folks enough time to review/discuss the topic offline on Github before coming into the meeting
• (optional) Paste the image of an animal

[SaschaSchwarze0]

Optional fields in our custom resources, see CRD usage of pointers vs non-pointers #945.

Based on Kubernetes API conventions:

we ask that pointers always be used with optional fields that do not have a built-in nil value

I can understand this, but it imo has disadvantages. Let's take a string as example. In many cases where we have optional strings, we do not need to distinguish between nil and "". An example is the Build's spec.source.revision. We allow users to specify it or to leave it out. But, an empty string is invalid. We would need additional validation for those use cases.

How do we want to define our own API convention? Based on what Kubernetes community suggests, or slightly different = use pointers for optional fields where you need to distinguish nil and the built-in nil value, for example "" for strings.

cc @shahulsonhal

🐩

[shahulsonhal]

Replace the existing linters (sanity-check) with all in one golangci-lint

[SaschaSchwarze0]

Looking for an approval of SHIP-0025: Add ship to support array strategy parameters and secret and configmap key references as value #34. Gabe and Matthias approved. Need Adam or Shoubhik to give blessing.

🐴

[HeavyWombat]

Any scans for licenses or patent issues for modules?
🐈

[SaschaSchwarze0]

Pointers topic:

• We make optional fields generally pointers.
• Shoubhik: For fields where nil and "" do not need to be distinguished, we interpret "" as nil (like for the revision)
• Matthias: prefer an empty string to be interpreted as an empty string
• Shoubhik: what would be the expectation of the user specifying an empty string ?
• For build.spec.dockerfile, we have no empty string check atm
• Decision: Use pointers, do not interpret "", check code locations if validation is missing

golintci-lint:

• Jason, Matthias, Sascha: go for it
• Decision: let's go ahead, issues:
  • Use golangci-lint in favor of running individual tools build#948
  • Use golangci-lint in favor of running individual tools cli#77
  • Use golangci-lint for static scanning operator#35

Shoubhik will look at the ship

Scans for licenses/patent issues:

• Matthias: image-spec caused concerns downstream (pending patent)
• Shoubhik: RedHat has an org internally that scans, have not yet done that kind of scanning for Shipwright, image-spec was also noticed (but that's a security alert)
• Sascha: is there maybe a scanning tool in the golangci-lint tool family ?
• Jason: there is a license scanning tool for golang, go-licenses
• It makes sense to include some kind of scanning for this in upstream
• Decision: Sascha will open an issue (in build and cli and operator) to introduce scanning. We should probably do it in one repo first and then copy the approach to the others.
• Matthias: any experiences with excludes in go.mods? -> Not really.
• Issues:
  • Introduce scanning for problematic licenses, patent issues, and similar, in dependencies build#949
  • Introduce scanning for problematic licenses, patent issues, and similar, in dependencies cli#78
  • Introduce scanning for problematic licenses, patent issues, and similar, in dependencies operator#36

[sbose78]

Follow-up from today's discussion on image-spec shipwright-io/build#947