最近看到一篇非常有信息量的关于人工智能、云原生、开源的趋势报告，出自于GitHub，翻译并分享给大家，以下是报告全文。
cpp-linter-action 最新版支持 Pull Request Review 功能了 👏
作为 cpp-linter 的创建者和贡献者，我很高兴地宣布 —— cpp-linter-action 从 v2.9.0 版本开始支持 Pull Request Review 功能了 👏
以下是 cpp-linter-action 的 release notes。
其中 Bump cpp-linter from 1.6.5 to 1.7.1 by @dependabot in #191 是其中最重要的变化。注：cpp-linter 包是 cpp-linter-action 的核心依赖。
看看顶级的开源组织都在用哪些服务和工具
本篇介绍的是大名鼎鼎的开源软件基金会 Apache 所使用的服务(Services)和工具(Tools)，这或许能帮助你打开视野，在选择工具的时候提供参考。如果你是一名 DevOps、SRE 或是 Infra 工程师，通过本篇文章内容结果帮助你更好的展示团队所提供的服务有哪些，以及窥探到 Apache Infra 是怎样组织和管理他们的。
Apache 是谁
如果你不太了解 Apache，下面是关于 Apache 的简要介绍。
Apache 是一个开源软件基金会（Apache Software Foundation，简称 ASF）的缩写。ASF 是一个非营利性的组织，致力于支持和发展开源软件项目。Apache 软件基金会通过提供法律、财务和基础设施支持，帮助开发者共同合作创建和维护开源软件。其中，Apache 软件基金会最为著名的项目之一是 Apache HTTP 服务器，也称为 Apache Web 服务器。此外，ASF 还托管了许多其他流行的开源项目，像 ECharts，Superset，Dubbo，Spark，Kafka 等等。
服务与工具
Apache Infra 团队维护着供 PMC（项目管理委员会）、项目提交者和 Apache 董事会使用的各种工具。这些工具中的部分工具只提供给有特定职责或角色的人员使用。其他工具，如显示 Apache 基础设施各部分状态的监控工具，则向所有人开放。
为顶级项目（TLP）提供的服务
网站
- www.apache.org 这是 Apache 的主要网站。
- Apache 项目网站检查器 会定期检查所有为顶级项目（TLP）提供的网站，并报告它们是否符合 Apache 的 TLP 网站政策。
这里只列出了几个挺有意思的连接，比如项目网址检查器，它会检查顶级项目是否有 License, Donate, Sponsors, Privacy 等正确的连接。
电子邮件
- 所有新建电子邮件列表的申请都应通过自助服务系统进行。
- 电子邮件服务器 - QMail/QSMTPD
如何把 GitHub Release Notes 按照 New features、Bug Fixes ... 进行自动分类
如果你使用过 GitHub 发布过项目，你会知道 GitHub 可以自动生成 Release Notes。
就像这样 GitHub 自动生成的 Release Notes。
这个截图里的 Release Notes 内容很少，看起来还很清晰。但如果内容很多，以 Jenkinsci 组织下的 configuration-as-code-plugin 项目为例，可以看出来这里的 Release Notes 中的内容是按照标题进行分类的，假如这些内容混在一起将会非常糟糕的体验。(不要误以为这是手动进行分类的，程序员才不愿意干这种事😅)
本文将分享针对需要对 GitHub Release Notes 的内容按照标题进行自动分类的两种方式。
How to make Jenkins pipeline not fail if a specific error occurs
Sometimes you don’t want Jenkins pipeline failed for a specific error occurs. so you can use catchError to catch error and update stage or build result to SUCCESSFUL or UNSTABLE or FAILURE (if you want)
How to adopt Supply Chain Security for GitHub and Non-GitHub projects
Why Software Supply Chain Security is important?
Software supply chain security is the act of securing the components, activities, and practices involved in creating software.
Attacks in the software supply chain have become more and more frequent in recent years, SonaType reported more than 700% of attacks in open-source software from 2019 to 2022.
In this Google Security Blog, there are many real examples of software supply chain attacks that pose growing threats to users and Google proposed a solution called SLSA in 2021.
Also, some well-known organizations such as Linux Foundation and CNCF have created standards and tools to address the issue of how to produce trusted software and attestations.
Based on this background, many organizations want to incorporate best practices from the open-source community into our CICD pipeline.
Witness 和 SLSA 💃
由于近些年针对软件的供应链的攻击越来越频繁，因此 Google 在 2021 提出的解决方案是软件工件供应链级别（Supply chain Levels for Software Artifacts，”SLSA”）
本篇将介绍在非 GitHub 生态系统中，我们如何生成和验证软件工件的来源，从而提高你的项目的 SLSA Level。
Witness 是一个可插拔的软件供应链风险管理框架，它能自动、规范和验证软件工件出处。它是 in-toto 是 CNCF 下的项目之一。它的最初作者是 Testifysec，后来捐赠给了 in-toto。
什么是 Witness
Witness 是一个可插拔的供应链安全框架，可创建整个软件开发生命周期（SDLC）的证据（Provenance）跟踪，确保软件从源代码到目标的完整性。它支持大多数主要的 CI 和基础架构提供商，是确保软件供应链安全的多功能、灵活的解决方案。
安全 PKI (Public Key Infrastructure - 公钥基础设施)分发系统的使用和验证 Witness 元数据的能力进一步增强了流程的安全性，并有助于减少许多软件供应链攻击向量。
Witness 的工作原理是封装在持续集成流程中执行的命令，为软件开发生命周期（SDLC）中的每个操作提供证据跟踪，这样就可以详细、可验证地记录软件是如何构建的、由谁构建以及使用了哪些工具。
这些证据可用于评估政策合规性，检测任何潜在的篡改或恶意活动，并确保只有授权用户或机器才能完成流程中的某一步骤。
总结 - Witness 可以做什么
- 验证软件由谁构建、如何构建以及使用了哪些工具
- 检测任何潜在的篡改或恶意活动
- 确保只有经授权的用户或机器才能完成流程的每一步
- 分发证词（Attestations）和策略（Policy）
如何使用 Witness
主要分三步：
witness run- 运行提供的命令并记录有关执行的证词。witness sign- 使用提供的密钥签署提供的文件。witness verify- 验证 witness 策略。
快速开始
这是我创建的 Witness Demo 仓库用于演示 witness 的工作流程，具体可以根据如下步骤进行。
Python 和 SLSA 💃
由于近些年针对软件的供应链的攻击越来越频繁，据 SonaType 的统计从 2019 年到 2022 年针对开源软件的攻击增长了 742%，因此 2021 年 Google 提出的解决方案是软件工件供应链级别（Supply chain Levels for Software Artifacts，”SLSA”）
本篇将介绍在 Python 生态系统中，我们如何使用 SLSA 框架来生成和验证 Python 工件的来源，从而让你的 SLSA Level 从 L0/L1 到 L3。
注意：本文介绍的是针对托管在 GitHub 上的 Python 项目。SLSA 框架可通过 GitHub Actions 来实现开箱即用，只需较少的配置即可完成。
对于托管在非 GitHub 上的项目（例如 Bitbucket）可以尝试 Witness，下一篇我将更新关于如何使用 Witness。
内容
下面是从维护人员到用户的端到端工作流程：从构建 Wheel package -> 生成出处 -> 验证出处 -> 发布到 PyPI -> 以及用户验证出处 -> 安装 wheel。接下来让我们一起来完成这其中的每一步。
如果你想了解 Python 打包的流程或是术语可以参见Python 打包用户指南。
Problems and solutions when upgrading XLC from 10.1 to IBM Open XL C/C++ for AIX 17.1.0
In this article, I would like to document the problems encountered when upgrading from IBM XLC 10.1 to XLC 17.1 (IBM Open XL C/C++ for AIX 17.1.0) and how to fix the following 12 errors.
If you’ve encountered any other errors, feel free to share your comments with or without a solution.
2022-23 世界质量报告（World Quality Report）
解决通过 Jenkins Artifactory plugin 上传 artifacts 失败的问题 “unable to find valid certification path to requested target”
最近遇到了通过 Jenkins agent 无法上传 artifacts 到 Artifactory 的情况，具体错误如下：
解决在 AIX 通过 Jenkins agent git clone 失败的问题
最近又遇到了在 AIX 上通过 Jenkins agent 无法下载代码的情况，报了如下错误：
2023 年最值得关注的 DevOps 趋势
DevOps 运动仍然是一个不断发展的领域，受到技术进步、行业趋势和组织需求等多种因素的影响。这使得很难对 DevOps 工程的未来做出具体预测。然而我认为有一些趋势可能会在来年继续影响 DevOps 领域的发展。
Upload artifacts failed to Artifactory from AIX
Recently my CI pipeline suddenly does not work on AIX 7.1 with error Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath..