作为 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 的核心依赖。

什么是 cpp-linter-action

如果你还不了解 cpp-linter-action 可以查看我之前的文章。

简单来说，cpp-linter-action 是 cpp-linter 组织下的一个 GitHub Action，针对 C/C++ 代码做代码格式、诊断和修复典型的编程错误。

目前 cpp-linter-action 大概被超过 500 个开源项目所使用（闭源项目无法统计到），这其中包括 Microsoft、Linux Foundation、CachyOS、nextcloud、Jupyter 等知名组织或项目。

可以说目前 cpp-linter-action 是 GitHub 上 C/C++ 项目的最佳 Linter 选择。

关于 Pull Request Review 功能

此次新增的 Pull Request Review 功能可以直接在 cpp-linter-action 检查完成后给出 review 建议，开发者无需本地修改检查到的错误，并提交到远程。
而是可以直接点击 GitHub 上的 Commit suggestions 按钮，就可以把建议修改直接 merge 到当前的 pull request 中，省去了人为的修改和推送。

一旦所有的 suggestions 都已经修复了，github-action bot 会自动你 approve 你的 pull request。

cpp-linter-action 其他已经支持的功能

除了 Pull Request Review 功能之外，cpp-linter-action 目前还支持另外三个选项：Annotations，Thread Comment 和 Step Summary。

GitHub Annotations

即在指定的需要修改的代码行位置提示执行结果​。

Thread Comment

即在 Pull Request 上以评论形式添加执行结果。​

Step Summary

​即在 GitHub Action job 运行界面添加并显示执行结果。

关于本次发布背后的故事

我终于在大年初八的晚上孩子睡着了之后有时间坐下来写一篇文章了，来记录一下本次发布背后的故事。

这次发布要特别感谢 cpp-linter 联合创建者 @2bndy5 的贡献。他和我素未谋面，但却与我一起“共事”了三年。
我们的相识是因为他的一次主动贡献而开始的，但一直以来的交流仅限于 GitHub 上的 issue 和 pull request 的讨论，只有不公开信息才会通过邮件来传达。

正如 @2bndy5 的个人介绍那样：热衷于编程，喜欢 DIY 电子产品，坚持写易懂的文档。他是我认识的人当中少有的技术全面且文档十分友好的极客。

不久前我收到了他的邮件说：因家中变故，他要休息一段时间，他没有动力坐下来写代码了，并告诉我 Pull Request Review 所有改动似乎都通过测试了。如果我想主导发布，他可以提供支持。

在此，我想对发生在他身上的事情再次表示最深切的同情和慰问🙏

继续他的工作我需要先认真阅读他的修改并搞清楚这部分功能，但年底了迟迟没有一个充足的时间来开始，想等着春节假期再来补作业吧。

可是还没有到春节放假，就在腊月二十七孩子生病了，并告知需要住院治疗，因为我们发现得早，病症不严重，孩子在除夕当天恢复得很好，期待着再观察两天就可以出院了。
哎，可是意外发生了，孩子不小心胳膊被烫伤了，作为父母非常痛心，这是我永远都不想回忆的至暗时刻。总之就是雪上加霜。就这样我们从年前腊月二十七一直住院到正月初六，住了 10 天医院。
孩子出院的第二天我和妻子都生病了，可能是当放松下来，人一下子就累病了。

在这段时间里 @2bndy5 完成了对 Pull Request Review 功能测试、文档修改和发布。他在评论里说花时间在编码上会让他短暂地逃离现实。

终于上班的前一天我差不多恢复了体力，就迫不及待的打开 GitHub，审查并测试别人对项目的贡献代码，这次是一个 Title 是来自于德国多特蒙德大学的天体物理学家的贡献者，确实有点惊讶到我了。

但这就是开源的有趣之处，它能让你有机会和任何高手近距离免费过招。如果你给 Linux 内核提交代码，那你极有可能得到 Linus 的指导 ：）

最后，欢迎使用 cpp-linter 组织下的任何项目并提出您的宝贵意见、建议、或贡献代码。

———— 于 2024 年 2 月 17 日 23:34

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

本篇介绍的是大名鼎鼎的开源软件基金会 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）提供的服务
  • 网站
  • 电子邮件
  • ASF 自助服务平台
  • ASF 账户管理
  • 支持 LDAP 的服务
• 项目孵化服务
• ASF 项目工具
  • 版本控制
  • 问题跟踪和功能请求
  • 将版本库与 Jira 票据集成
  • 源码库发布者/订阅者服务
  • 构建服务
  • 产品命名
  • 代码签名
  • 代码质量
  • 代码分发
  • 虚拟服务器
  • 在线投票
• 其他工具
  • DNS
  • URL 短缩器
  • 共享片段
  • 机器列表
  • 奇思妙想

为顶级项目（TLP）提供的服务

网站

• www.apache.org 这是 Apache 的主要网站。
• Apache 项目网站检查器 会定期检查所有为顶级项目（TLP）提供的网站，并报告它们是否符合 Apache 的 TLP 网站政策。

这里只列出了几个挺有意思的连接，比如项目网址检查器，它会检查顶级项目是否有 License, Donate, Sponsors, Privacy 等正确的连接。

电子邮件

• 所有新建电子邮件列表的申请都应通过自助服务系统进行。
• 电子邮件服务器 - QMail/QSMTPD

Read More

时间过得很快，2023 年转瞬即逝。如果不记录下自己在这一年里发生的事情，过不了多久就很难回想起来这一年都发生过什么。

因此按照惯例还是要先回顾 2023 年，然后展望 2024 年。

回顾 2023

回顾这一年，我想用三个关键词来形容生活、工作以及业余。

生活中，是“奶爸”

从孩子一出生就是我和我的队友独立带娃，白天我上班，她带娃；晚上下班我火速回去接班、陪玩、家务直到孩子睡觉。周末至少有一天会带孩子出去溜达。

带娃的过程中会觉得辛苦，漫长，然而回顾这一年会发现孩子一眨眼就长大了。年初时候还只会爬、扶站；到了年末孩子已经能爬桌子能跑了，有消耗不完的能量。

接下来就是流水账的记录了，记录一下平凡一年中的小事件：

• 四月：跟公司活动去了一趟发现王国、爬了童牛岭、玩了三国杀、在渔公码头吃了海鲜自助
• 五月：在星海和庄河分别给孩子办了生日宴
• 九月：第一次带娃住酒店，去了金石滩希尔顿住了一晚、吃了一顿酒店自助早餐
• 十月：国庆回庄河住了一晚，吃了一顿家庭烧烤；回来去了一趟横山寺，吃了一顿自助素食餐；假期踢了一场球；办了大连森林动物园的卡开始打卡动物园
• 十一月：去了大连森林动物园、旅顺太阳沟、大连自然博物馆、参加了公司在钱库里的聚餐
• 十二月：收到非常突发的消息（以后有机会再细说）、参加组内团建、大连博物馆、陪爸爸住院检查、逛旅顺博物馆

工作中，是“最佳实践”的坚守着

这一年我依旧坚持 DevOps 最佳实践：

1. 继续拓展 Ansible Playbook 仓库的应用范围
2. 创建了 Infrastructure as Code 仓库，用 Code 来管理 Infra
3. 创建了 Docker Image 仓库来容器化产品，在 Bitbucket 仓库中应用了很多我的 DevOps 实践
4. 承担了更多产品的 Build 和 Release 工作
5. 提出并实施了 Software Supply Chain Security 想法
6. 在团队内部分享 DevOps 实践，以 Jenkins 共享库的形式分享给其他团队

业余时间，是“开源和写作”的爱好者

和去年一样，业余时间我还做同样的事情：

1. 开源项目

• cpp-linter-action 截至目前已经有 400 多个用户在使用，包括微软、Jupyter、Waybar、libvips、desktop、chocolate-doom 等知名开源项目，希望之后还有更多的想法去改进
• commit-check 目前处在初期发展阶段，目前的用户很少，还需要优化它以及引入更多好的想法

2. 写作 - 2023 年我一共更新了 20 篇博客 + 6 篇公众号文章，距离年初设定的 24（博客）+ 12（公众号）打了一些折扣
3. 学习 - 加入的知名社区里学习和贡献这件事没有做到，有了孩子之后确实没有多少业余时间了，希望 2024 娃能早睡我能有更多自己的时间

展望 2024

每年的愿望或是 Flag 还是要设置的，万一实现了呢？

1. 希望能顺利的度过职业发展期，希望会是一个崭新的、充满挑战的开始
2. 家人身体健康，工作和家庭的平衡，带她们多出去走走
3. 补足在 DevOps 一些方面的不足，争取参与到实际的项目中来获得提升
4. 以教促学，持续在博客、公众号等分享，坚持个人成长
5. 保持运动，不论是跑步还是踢球，把体重降下来

过去的年终总结

2022 年终总结
2020 年终总结
2019 年终总结
2018 从测试转开发

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

如果你使用过 GitHub 发布过项目，你会知道 GitHub 可以自动生成 Release Notes。

就像这样 GitHub 自动生成的 Release Notes。

这个截图里的 Release Notes 内容很少，看起来还很清晰。但如果内容很多，以 Jenkinsci 组织下的 configuration-as-code-plugin 项目为例，可以看出来这里的 Release Notes 中的内容是按照标题进行分类的，假如这些内容混在一起将会非常糟糕的体验。(不要误以为这是手动进行分类的，程序员才不愿意干这种事😅)

本文将分享针对需要对 GitHub Release Notes 的内容按照标题进行自动分类的两种方式。

方式一：使用 GitHub 官方提供的功能

方式一是通过 GitHub 提供的功能对 Release Notes 进行自动分类，即在仓库下面创建配置文件 .github/release.yml。这个功能与 GitHub 的 Issue Template 和 Pull Request Template 类似。具体的配置选项可以参考官方文档

以下我是在 commit-check-action 项目的配置

changelog:
  exclude:
    labels:
      - ignore-for-release
  categories:
    - title: '🔥 Breaking Changes'
      labels:
        - 'breaking'
    - title: 🏕 Features
      labels:
        - 'enhancement'
    - title: '🐛 Bug Fixes'
      labels:
        - 'bug'
    - title: '👋 Deprecated'
      labels:
        - 'deprecation'
    - title: 📦 Dependencies
      labels:
        - dependencies
    - title: Other Changes
      labels:
        - "*"

针对上面的示例，在添加了 .github/release.yml 配置文件之后，当再次生成 Release Notes 时就会自动将其内容进行自动归类（下图中的标题 📦 Dependencies 是自动添加的）

方式二：使用 Release Drafter

方式二是使用 Release Drafter，即在仓库创建配置文件 .github/release-drafter.yml。

从 Release Drafter 项目提供的配置参数可以看出来它提供的功能更多，使用也更加复杂。另外它还支持将配置文件放到组织下的中央仓库 .github 来实现统一的配置、并将其共享给其他仓库。

目前方式一 .github/release.yml 不支持通过中央仓库 .github 来实现统一的配置，详见这个讨论。

这里还以 jenkinsci/configuration-as-code-plugin 为例看到它的 .github/release-drafter.yml 的配置。

_extends: .github

这个配置的 _extends: .github 表示从中央仓库 .github/.github/release-drafter.yml 继承过来的配置。

# Configuration for Release Drafter: https://github.com/toolmantim/release-drafter
name-template: $NEXT_MINOR_VERSION
tag-template: $NEXT_MINOR_VERSION
# Uses a more common 2-digit versioning in Jenkins plugins. Can be replaced by semver: $MAJOR.$MINOR.$PATCH
version-template: $MAJOR.$MINOR

# Emoji reference: https://gitmoji.carloscuesta.me/
# If adding categories, please also update: https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/action.yaml#L16
categories:
  - title: 💥 Breaking changes
    labels:
      - breaking
  - title: 🚨 Removed
    labels:
      - removed
  - title: 🎉 Major features and improvements
    labels:
      - major-enhancement
      - major-rfe
  - title: 🐛 Major bug fixes
    labels:
      - major-bug
  - title: ⚠️ Deprecated
    labels:
      - deprecated
  - title: 🚀 New features and improvements
    labels:
      - enhancement
      - feature
      - rfe
  - title: 🐛 Bug fixes
    labels:
      - bug
      - fix
      - bugfix
      - regression
      - regression-fix
  - title: 🌐 Localization and translation
    labels:
      - localization
  - title: 👷 Changes for plugin developers
    labels:
      - developer
  - title: 📝 Documentation updates
    labels:
      - documentation
  - title: 👻 Maintenance
    labels:
      - chore
      - internal
      - maintenance
  - title: 🚦 Tests
    labels:
      - test
      - tests
  - title: ✍ Other changes
  # Default label used by Dependabot
  - title: 📦 Dependency updates
    labels:
      - dependencies
    collapse-after: 15
exclude-labels:
  - reverted
  - no-changelog
  - skip-changelog
  - invalid

template: |
  <!-- Optional: add a release summary here -->
  $CHANGES

replacers:
  - search: '/\[*JENKINS-(\d+)\]*\s*-*\s*/g'
    replace: '[JENKINS-$1](https://issues.jenkins.io/browse/JENKINS-$1) - '
  - search: '/\[*HELPDESK-(\d+)\]*\s*-*\s*/g'
    replace: '[HELPDESK-$1](https://github.com/jenkins-infra/helpdesk/issues/$1) - '
  # TODO(oleg_nenashev): Find a better way to reference issues
  - search: '/\[*SECURITY-(\d+)\]*\s*-*\s*/g'
    replace: '[SECURITY-$1](https://jenkins.io/security/advisories/) - '
  - search: '/\[*JEP-(\d+)\]*\s*-*\s*/g'
    replace: '[JEP-$1](https://github.com/jenkinsci/jep/tree/master/jep/$1) - '
  - search: '/CVE-(\d{4})-(\d+)/g'
    replace: 'https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-$1-$2'
  - search: 'JFR'
    replace: 'Jenkinsfile Runner'
  - search: 'CWP'
    replace: 'Custom WAR Packager'
  - search: '@dependabot-preview'
    replace: '@dependabot'

autolabeler:
  - label: 'documentation'
    files:
      - '*.md'
    branch:
      - '/docs{0,1}\/.+/'
  - label: 'bug'
    branch:
      - '/fix\/.+/'
    title:
      - '/fix/i'
  - label: 'enhancement'
    branch:
      - '/feature\/.+/'
    body:
      - '/JENKINS-[0-9]{1,4}/'

以上是中央仓库的 .github/.github/release-drafter.yml 配置，可以看到 Jenkins 官方使用了很多特性，比如模板、替换、自动加 label 等，需要在通读 Release Drafter 的文档之后能更好的理解和使用。

总结

以上两种方式都可以帮助你在自动生成 Release Notes 的时候自动进行标题分类，但两者有一些如下差别，了解它们可以帮助你更好的进行选择。

1. GitHub 官方提供的方式更容易理解和配置，可以满足绝大多数的项目需求。主要的不足是不支持从中央仓库 .github 中读取 .github/release.yml。
2. Release Drafter 提供了更为强大的功能，比如模板、排序、替换、自动对 pull request 加 label 等等，尤其是可以通过中央仓库来设置一个模板，其他项目来继承其配置。

如果是大型的开源组织，Release Drafter 是更好的选择，因为它提供了强大的功能以及支持继承中央仓库配置。如果是个人项目，GitHub 官方提供的方式基本满足需求。

以上就是我对两个生成 GitHub Release Notes 并进行自动分类的分享。

如果有任何疑问或建议欢迎在评论区留言。

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

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)

Here is the Jenkinsfile of pipeline

pipeline {
    agent { node { label 'linux' } }

    stages {
        stage('Catch Error') {
            steps {
                catchError(buildResult: 'UNSTABLE', stageResult: 'UNSTABLE', message: 'abc: command not found') {
                    sh "abc"
                }
            }
        }
    }
}

Here is the output of pipeline

17:14:07  [Pipeline] Start of Pipeline
17:14:08  [Pipeline] node
17:14:08  Running on linux in /agent/workspace/Stage-Job/catch-error
17:14:08  [Pipeline] {
17:14:08  [Pipeline] stage
17:14:08  [Pipeline] { (Catch Error)
17:14:08  [Pipeline] catchError
17:14:08  [Pipeline] {
17:14:08  [Pipeline] sh
17:14:08  + abc
17:14:08  /agent/workspace/Stage-Job/catch-error@tmp/durable-303b03ca/script.sh: line 1: abc: command not found
17:14:08  [Pipeline] }
17:14:08  ERROR: abc: command not found
17:14:08  ERROR: script returned exit code 127
17:14:08  [Pipeline] // catchError
17:14:08  [Pipeline] }
17:14:08  [Pipeline] // stage
17:14:08  [Pipeline] }
17:14:08  [Pipeline] // node
17:14:08  [Pipeline] End of Pipeline
17:14:08  Finished: UNSTABLE

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

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.

How to adopt Supply Chain Security for GitHub and Non-GitHub projects

Next, I will show you how to adopt on both GitHub and Rocket Bitbucket as an example to show you how we integrate software supply chain security

GitHub projects

On GitHub, the easiest and most popular option is to use slsa-github-generator, a tool provided by the official slsa-framework for native GitHub projects to create attestations during the build process and upload signed attestations to Rekor a transparency log system created by Sigstore. Here is the demo reposistory for reference.

Before installing your product package, the user can download the package and verify the provenance file at the end of .intoto.jsonl first, then run the following command manually or in their CI pipeline to verify whether the artifact is tampered with or not

bash-4.4$ slsa-verifier verify-artifact test-1.0.0-py3-none-any.whl --provenance-path test-1.0.0-py3-none-any.whl.intoto.jsonl --source-uri github.com/shenxianpeng/slsa-provenance-demo
Verified signature against tlog entry index 49728014 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77af7063689e8760fd7134f37e17251ec1d5adc16af64cb5cb579493278f7686e77
Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0" at commit fb7f6df9f8565ed6fa01591df2af0c41e5573798
Verifying artifact test-1.0.0-py3-none-any.whl: PASSED

PASSED: Verified SLSA provenance

Non-GitHub projects

However, there are many organizations’ codes are hosted on Non-GitHub SCM, so you can use the Witness, a tool from CNCF in-toto, which can help us generate and verify attestations.

It’s easy to scale Witness to your products, just integrate witness command into the existing build command it will generate proof of the software build and release execution process and can be verified.

You can follow this demo to integrate with witness, then will generate the build package along with attestations file, policy-signed.json file, and a public key.

Before user installing your product package, they can run the following command manually or in their CI pipeline to verify whether the artifact is tampered or not.

witness verify -f dist/witness_demo-1.0.0-py3-none-any.whl -a witness-demo-att.json -p policy-signed.json -k witness-demo-pub.pem 
INFO    Using config file: .witness.yaml             
INFO    Verification succeeded                       
INFO    Evidence:                                    
INFO    0: witness-demo-att.json 

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

由于近些年针对软件的供应链的攻击越来越频繁，因此 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

主要分三步：

1. witness run - 运行提供的命令并记录有关执行的证词。
2. witness sign - 使用提供的密钥签署提供的文件。
3. witness verify - 验证 witness 策略。

快速开始

这是我创建的 Witness Demo 仓库用于演示 witness 的工作流程，具体可以根据如下步骤进行。

Read More

由于近些年针对软件的供应链的攻击越来越频繁，据 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。

内容

1. 构建纯净的Python包
2. 生成出处证明
3. 上传到PyPI
4. 验证Python包的来源
5. 文中用到的项目

下面是从维护人员到用户的端到端工作流程：从构建 Wheel package -> 生成出处 -> 验证出处 -> 发布到 PyPI -> 以及用户验证出处 -> 安装 wheel。接下来让我们一起来完成这其中的每一步。

如果你想了解 Python 打包的流程或是术语可以参见Python 打包用户指南。

Read More

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.

1. Change cc to ibm-clang

First you need to change all the related cc to ibm-clang in the the global Makefile. for example:

- CC=cc
- CXX=xlC_r
- XCC=xlC_r
- MAKE_SHARED=xlC_r
+ CC=ibm-clang
+ CXX=ibm-clang_r
+ XCC=ibm-clang_r
+ MAKE_SHARED=ibm-clang_r

And check following link of Mapping of options to map new Clang options if any.

2. error: unknown argument: ‘-qmakedep=gcc’

- GEN_DEPENDENTS_OPTIONS=-qmakedep=gcc  -E -MF $@.1 > /dev/null
+ GEN_DEPENDENTS_OPTIONS= -E -MF $@.1 > /dev/null

3. should not return a value [-Wreturn-type]

- return -1;
+ return;

4. error: non-void function ‘main’ should return a value [-Wreturn-type]

- return;
+ return 0;

5. error: unsupported option ‘-G’ for target ‘powerpc64-ibm-aix7.3.0.0’

- LIB_101_FLAGS := -G 
+ LIB_101_FLAGS := -shared -Wl,-G

6. Undefined symbol (libxxxx.so)

- LIB_10_FLAGS := -bexport:$(SRC)/makefiles/xxxx.def
+ LIB_10_FLAGS := -lstdc++ -lm -bexport:$(SRC)/makefiles/xxxx.def

7. unsupported option -qlongdouble

- drv_connect.c.CC_OPTIONS=$(CFLAGS) -qlongdouble -brtl
+ drv_loadfunc.c.CC_OPTIONS=$(CFLAGS) $(IDIR) -brtl

8. Undefined symbol: ._Z8u9_closei

- extern int u9_close(int fd) ;
+ extern "C" int u9_close(int fd) ;

9. ERROR: Undefined symbol: .pow

- CXXLIBES = -lpthread -lC -lstdc++
+ CXXLIBES = -lpthread -lC -lstdc++ -lm

10. ‘main’ (argument array) must be of type ‘char **’

- d_char *argv[];
+ char *argv[];

11. first parameter of ‘main’ (argument count) must be of type ‘int’

- int main(char *argc, char *argv[])
+ int main(int argc, char *argv[])

12. ERROR: Undefined symbol: ._ZdaPv

- LIB_3_LIBS	:= -lverse -llog_nosig
+ LIB_3_LIBS	:= -lverse -llog_nosig -lstdc++

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

2202-23 世界质量报告（World Quality Report 简称 WQR）是一项全球研究，不论是作为软件测试、开发工程师，关注这类软件质量报告可以帮助我们快速了解软件行业的现状和趋势。

七个主题

今年的 WQR 的关键趋势和推荐包括包括以下七个关键建议：

• 敏捷质量调配 (DONE)
• 质量自动化 (DONE)
• 测试基础设施测试和配置 (DONE)
• 测试数据提供和数据验证 (WIP)
• 质量和可持续的 IT (NOT START)
• 新兴技术趋势的质量工程 (NOT START)
• 价值流管理 (NOT START)

Read More