Skip to content
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

May 6th, 2024 Community Meeting #203

Closed
qu1queee opened this issue May 2, 2024 · 3 comments
Closed

May 6th, 2024 Community Meeting #203

qu1queee opened this issue May 2, 2024 · 3 comments

Comments

@qu1queee
Copy link
Contributor

qu1queee commented May 2, 2024

  • 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
Copy link
Contributor Author

qu1queee commented May 2, 2024

  • Follow on Feature Discussion: Primary Support for Multi-Arch Builds build#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
Copy link

Sure, I can present the demo on Monday.

@qu1queee
Copy link
Contributor Author

qu1queee commented May 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

2 participants