ey-commerce-lib 1.0.34

eeyoung电商客户端调用封装

ey-commerce-lib

发版流程

下面是从“升级功能”到“发布新版本”的完整流程。示例版本号使用 1.0.34，实际发版时替换成要发布的新版本。

1. 开发功能

git status

先确认当前工作区状态，避免把无关文件一起提交。完成代码修改后，优先运行默认测试：

python -m pytest

如果修改了打包配置、依赖或发布流程，再运行构建检查：

python -m build

如果修改了需要真实平台凭证的集成测试，确认本地已配置 tests/integration_config.py 后再运行：

python -m pytest -m integration -s

2. 提交功能代码

只提交和当前功能相关的文件：

git status
git add 需要提交的文件
git commit -m "feat: describe your change"
git push origin main

main 分支推送只同步代码，不会发布 PyPI。

3. 升级版本号

发布前必须升级版本号，并确保 pyproject.toml 和 uv.lock 里的版本一致。PyPI 不允许重复上传同一个版本号。

例如发布 1.0.34：

# 修改 pyproject.toml 和 uv.lock 中的 version 为 1.0.34
git diff pyproject.toml uv.lock
git add pyproject.toml uv.lock
git commit -m "chore: bump version to 1.0.34"
git push origin main

4. 创建并推送 tag

tag 名称必须和版本号对应，建议使用 vX.Y.Z 格式：

git tag v1.0.34
git push origin v1.0.34

推送 tag 后，GitLab CI 会自动执行发布流水线：

build -> publish_pypi -> notify_dingtalk_release

5. 检查发布结果

在 GitLab 中查看：

CI/CD -> Pipelines

确认 tag pipeline 的三个 job 都成功：

build
publish_pypi
notify_dingtalk_release

发布成功后，再确认 PyPI 上已经出现新版本，并检查钉钉群是否收到发版成功通知。

6. CI 变量说明

CI 中的 pip 下载依赖默认使用清华 PyPI 镜像源，以减少自建 GitLab Runner 在国内网络环境下安装 build、twine 等工具的耗时。这个配置只影响依赖下载，不影响 twine upload 上传到官方 PyPI。

PyPI token 不写在仓库里，GitLab CI 通过下面两个变量上传：

TWINE_USERNAME = __token__
TWINE_PASSWORD = pypi-你的 PyPI API token

钉钉通知通过下面变量发送：

DINGTALK_WEBHOOK = 钉钉机器人 webhook
DINGTALK_SECRET = 钉钉机器人加签密钥，没开加签可以不填

这些变量都应配置在 GitLab 项目的：

Settings -> CI/CD -> Variables