最近一段时间一直在预研electron的覆盖率的事宜。大致的流程已经基本ok,剩余最后的数据验证。由于electron的插桩分为了渲染进程的插桩以及主进程的插桩。然后在验证的时候发现。主进程的覆盖率数据基本都没有上报上来。
从日志入手
由于主进程的定时任务数据上报是有日志打印的，所以我们先看下日志的信息是如何的。
找到了如下的日志:
提示说Commit提交号没有匹配到对应的测试计划。
这里先需要说明下我们electron覆盖率的逻辑，我们做插桩以后会将对应当前的代码的commit号以及覆盖率数据进行上报到覆盖率后台。由覆盖率后台来判断上报的commit所对应的测试计划是哪个。
但是我们通过fiddler抓包发现实际上渲染进程上报就不存在这样子的问题
这里就很奇怪了。因为不管是主进程还是渲染进程获取git的commit都是用的同样的逻辑进行获取的，为啥唯独主进程的数据上报存在问题呢？ 那首先我们需要确认一个问题主进程中获取到的commit到底是多少
通过查看electron打包后的asar包的内容，我们发现了真正的commit号：
确实与渲染进程上报的commit是不一致的。 所以我们需要确认主进程与渲染进程在commit号或者说数据提交上有什么区别了。
大胆推测
以下就是主进程打包的变量赋值的过程
const istanbul = require("./webpack/istanbul");
option.plugins.unshift(new webpack.EnvironmentPlugin({
JENKINS_PATH: process.cwd(),
GIT_COMMIT: istanbul.getGitCommit(),
}))
istanbul.js
/**
* Helper file
* 增加了一些方法，供覆盖率测试使用
*/
var fs = require('fs');
var helper = {
getGitCommit: function () {
try {
var gitHEAD = fs.readFileSync('.git/HEAD', 'utf-8').trim(); // 在jenkins上面，这里拿到的就已经是commit号了
//var ref = gitHEAD.split(': ')[1];
//var gitVersion = fs.readFileSync('.git/' + ref, 'utf-8').trim();
return gitHEAD;
} catch (e) {
console.log('get git commit fail!');
}
},
};
module.exports = helper;
看上去问题不大呀。那我们就打印下 gitHEAD 试试看吧。
从这个打印信息看 主进程以及渲染进程的commit号都是一样的才对。 那到底是谁又从新将这个commit号做了修改呢？
所以我们需要关注到一个变量名称 GIT_COMMIT 有没有可能是这个变量名称跟哪个冲突了呢？ 所以我们在jenkins的页面全局搜索了下。结果还真的有所发现
本身就有一个变量名称就叫做这个。并且就是主进程上报的commit号。 到这里真相就大白了。我们用的变量名称与本身的全局的变量名称冲突了。所以我们只要做一下修改就好了。
