今天的乐子是阿里给的

外面看笑话，里面腥风血雨

草台班子

我都不用猜，肯定是设环境变量嫌麻烦直接临时硬编码改配置，改完后一套无脑
git add .
git commit
git push
丝滑小连招导致的

世界是个巨大的草台班子

commit 写的很烂啊

跟想象中的超级大厂不一样

讲道理，这不应该清 history 么，为啥是 PR/commit

@hahastudio 已经泄漏了，当然是重置 key 了

@SilenceU 重置 key 是肯定要做的，但 git history 也应该清理啊

@hahastudio #7 为什么要清呢，掩盖问题么？

安全和方便就像鱼和熊掌不可兼得。

我曾经接手过一个别人写的 java spring 项目，一拿到源码，里面一看 dev 、test 、prod 的配置都在里面，一键使用起来的确很方便。哪像我之前维护的项目，每启动一个环境就到处找环境变量配置。

太正常了，下次还有

@hahastudio 没有清的必要，强制 push 不可取

@coolcoffee 吐血 环境变量是真的难找 文档缺失的情况下 从哪来的根本摸不着头脑

工作越久就发现世界就是个草台班子，有技术和细节追求的人很少，大部分人只是个上班的，无法教导所有人的

@hahastudio #7 一般开发不可能有 force push master 的权限，那么为啥组织甚至部长要给 Aias00 擦屁股？

阿里著名草台班子了，闹过的乐子太多了

这种很正常，测试用的 key ，提交的时候忘了删除了，但是一般都应该写到配置文件里，这个配置文件是忽略的

还试图用 commit 改掉配置，更乐子了

@hahastudio #7 用 force push 清了也没用，可以在 activity 里查到，除非把整个仓库删掉重建

@crocoBaby 再大的厂也不排除有蠢货啊。。已经反反复复的强调这种事情，有些人就是不在意。甚至提交代码都有钩子检查，这些人也不注意。只能说活该。等着受处分了

这人什么级别,提交代码没人审核?

这跟人蠢有什么关系，正常情况应该是有自动检测根本没法 commit 的。是个人都会犯错，不去检讨流程而是检讨员工那才是更大的草台班子

没人能保证永远不写 bug 的，出了事应该立刻想办法从流程上去规避，而不是骂别人是蠢货

我私人仓库一直是硬编码, 也想过用环境变量, 但再一想就我一个人用用鸡毛环境变量, 一把嗦多轻松快乐

这很正常吧。不就测试的 api key 提交了，后台重置 key 就行了，又没有任何风险。

从配置文件调用参数和 key 不是基本要求？就算是新手入职也要培训下这个

大家好，我是 spring-ai-alibaba 社区的贡献者，这个 pr 是我提交的内容。我是一名外部贡献者，非阿里内部员工。
这次提交的 key 是我个人账号申请的免费测试 key 。
昨晚上因为处理问题过程中，检查疏忽了导致出现了这次的问题，今天上午发现之后也是优先选择了失效 key ，然后还原代码重新提交了。
也是社区的其他贡献者给我转发了这个帖子，我才知道原来大家已经拿我的事情当乐子来看了。
由于这种事我也是第一次遇到，所以处理问题的方案未必是最优解，也希望大家能够理解吧

以为楼上是预言，没想到是真的

@devilte 见笑了

原来是社区贡献者.没参与过开源贡献,一般的社区贡献者也有权限可以直接 merge 到主分支上吗?这不怕人捣乱吗?

@Artemisr #31 好奇为什么会强调一下“一名外部贡献者，非阿里内部员工”，要是被绑架了你就眨眨眼

@devilte 主要还是担心这个事情对社区造成不良影响，毕竟还是我自己的原因

谁不犯错啊，正常正常，大家都是草台班子的一份子

我更多还是觉得开源社区的氛围是我比较喜欢的，我愿意花时间投入到社区贡献当中，属于是为爱发电了。
花时间投入当然是为了让社区能向好的方向发展，如果因为我个人导致了不好的事情，那我难免会愧疚的

@Artemisr 大佬，还有个错没改啊，配置文件里的 toolcalling: weather: enabled: enable ，这是 true ，不是 enable 啊，用 enable 代码不起效果，你昨天把 true 改成了 enable 。。

@fy718 got ，一会儿处理下

@Artemisr #34 害 人都会犯错，不会有人一直记得曾经有这个错误，笑一下过去了，不必给自己太多心理负担

@devilte 谢谢

@fy718 代码使用过程中有问题的话，可以随时提 issue 进行反馈啊，另外也欢迎提交 pr

阿里内部的 git 统一做了配置，我记得不会把各种 key 提上去，因为出过事

@fy718 #37 这也太离谱了

外包/临时工又主动出背锅了 怪不得每次出事都是这个说辞 看来是真管用

这是 main 分支啊，branch pull_request 到 main 和 code review 环节都没有的吗？

@kzfile git merge 到 main 的时候工作流定义里至少要有两步骤吧？自动化 review 和人工 review 。

@me1onsoda 自动化审核就能规避，说明没有设置 git 自动化审核规则。

@Artemisr #29 我以为是复制过来的，没想到是正主

这个框架好用么

特地搜了一下，没有看到 pre-commit / hook 之类的 secret scan.

大家好，我是 Spring AI Alibba PMC 成员，GitHub ID chickenlj 。

首先，非常感谢大家对我们项目的关注和善意提醒，这次确实是我们在开源流程中的一次疏忽。还好发现得及时，没有给 Aias00 造成实际的财务损失。

Aias00 作为 spring-ai-alibaba 的重要协作者之一，为开源社区做出了很大的贡献， 在这里也感谢 Aias00 和其他贡献者对开源社区的支持。

我本人作为一名长期贡献开源的普通人，过去也犯过类似错误，处理的时候实际上挺慌张的，感谢各位的理解，我们非常珍视每一个为开源社区付出的贡献者的努力。

大家关于项目流程的建议都非常好。理论上，GitHub 的 Secret Scanning 应该能检测到类似问题，但这次没有生效，我们会进一步排查原因。

接下来，项目 PMC 成员们会一起商量如何强化此类流程检查，规范项目协作，防止类似事情再次发生。

也欢迎大家多多使用 spring-ai-alibaba 以及阿里的其他开源产品，提出宝贵意见。如果能参与代码贡献就更好了：）

@devilte 可能是已被光速开除，从阿里员工降级为社区贡献者。(手动狗头)

@Aitisikuoliv1d 人家正主不是自己出来解释了么，咋还搁这儿阴谋论呢

@hllpark 你就是短视频里面说的那种承认错误然后 "高升" 的 "小李"?

@hllpark Alibaba 打错了

之前 leader 一直要求代码至少要看 3 次，每次给他提 pr 时候都会问我次数看没看够。保持这个习惯之后，错误真的能减少很多。

多大点事

@Artemisr 我非常好奇，你写的代码不会在提交的时候再自己检查一遍吗，但凡不是工具生成的，而是亲手写的，都需要检查下吧。

是不是操作的时候 git add . 然后 commit 了

@FrankAdler 我再逼逼几句，大部分写代码的人都多用点心呗，提交之前自己 review 下，那种临时注释掉，方便调试的修改，但凡检查下，都不会提交到仓库，包括我所在的公司很多人，写完自己简单测试下好像没问题，就提交了，一堆文件，哪些修改是真有用的，哪些没有也不管，出了问题再提交去修正，不觉得太低级了吗？不觉得污染历史记录吗？
典型的案例：我们有个系统，入口文件做了鉴权，本地调试的时候自己构造不出来带有效期的 token ，所以调试起手就是把鉴权那一行注释掉，然后就有人把他提交上去，拜托，不罚你个开除就不长记性是吧，动动脑子看一眼就知道那一行能不能提交。

虽然是外部贡献者写的，但是你们合代码都没有 review 出来吗

@FrankAdler 谨遵教诲，我下次注意

@crocoBaby 哈哈，你想多了

git 在提交的时候不是会对这种密钥属性的 key 进行提醒，不允许提交的吗

阿里竟然没有 git pre check

@Shatyuka 绝了，第一句 alibaba 就打错了，哈哈哈哈

多大点事，现在的人天天在这装圣人吗？自己不会犯错？

@BeautifulSoap #3
我们也嫌设置环境变量麻烦
但是我们都是
.env.sample
然后.gitignore 里忽略
.env.dev
.env.testing
.env.release
.env.production

@realpg 那么请问 假设 .env.testing 用于本地调试，里面原本放着平时开发主要用的 key ，这时候因为开发调试需要，要临时修改.env.testing 换成另一个 key 调试一两天然后换回来，偶尔可能还要再换回去。因为你.env.testing 添加了 ignore 那么就没有版本控制，如何恢复被覆盖的原本的 key ？

当然解决方法多的是，找个笔记记录下原本的 key ，或者复制一份 env 再恢复。但最简单粗暴的还是直接硬编码，然后在提交代码之前不 stage 这个变更就行。当然，这次阿里这事是最后一步玩脱了

@BeautifulSoap .env.testing1 ， .env.testing2 ， .env.testing3 。。。这样？

@realJamespond ummmm ，那么如何切换 env 文件？一般通过一个比如叫 APP_ENV 的变量比较多吧。APP_ENV=testing1 或者 APP_ENV=testing2 这样来决定使用什么 env 文件
那么问题来了，绕了一圈，最终问题又回到了怎么管理 APP_ENV 这个环境变量上了