May 6th, 2024 Community Meeting

[qu1queee]

• 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 😸

[qu1queee]

• Follow on https://github.com/shipwright-io/build/issues/1119 . @Adarsh-jaiss I think you are on this topic as well, pls feel free to share anything you might have or bring your questions.

• @karanibm6 we are wondering if you could provide a demo on your PR, for giving context to folks that are not yet familiar.

• On v0.13.0 release. Current state for shipping? We really need it!

• State of Triggers and Image repo?

• On Dependabot, should we update indirect dependencies as well?

[karanibm6]

Sure, I can present the demo on Monday.

[qu1queee]

Meeting minutes:

• On Dependabot, should we configure indirect dependencies?

  • We think we have this, per previous PRs, but there are some CVEs that have not been addressed by dependabot. It seems indirect dependencies are updated when a vulnerability is found, but we don't have this enabled for version updates.
  • To discuss again later, no conclusion on this so far.

• @karanibm6 presented a demo on Vulscan (Recording):

  • Introducing .spec.output.vulnerabilityScan
  • A first class citizen to enable/disable on demand a container image vulnerability scanning.
  • .spec.output.vulnerabilityScan.fail if set to true, it will not push the image to the registry(as part of the buildrun) and will switch the BR status to False. If set to false, it lists the CVEs in the status of the BR, but will push the container image. By default is set to false. Feedback: can we have a more descriptive key , instead of fail.
  • .spec.output.vulnerabilityScan.fail
  • For the severities, by default, it will find all severities, but there is a limit of the number of them that are surfaced in the BuildRun, 50max.
  • Do we need a global flag to disable the feature?

• On v0.13.0 release. Current state for shipping?

  • Release Branch needed some work, @SaschaSchwarze0 took care. We can already ship for Build, after CLI repo(go.mod updates required). Blog post goes after, without the instructions for Operator(We will update it after Operator v0.13.0 release is completed)
  • Operator is getting closer.

• On multi-arch support. @SaschaSchwarze0 and @Adarsh-jaiss would be presenting on their work on this next week. If you are interested on the topic, please take a look on where we are.

• On CNCF application. The application is moving, we have been working on this, from our internal discussions with the TAG App Delivery Group to trying to figure out some of the initial feedback.