这章是总结一下Windows用docker部署jenkins+sonarqube+db 遇到的一些问题,如何部署可以参考这本书的“持续集成部署”那章,本章内容可能会不完整,后面会去调整,完善。
解决方法:
在.ssh下配置config文件,文件中添加:
Host *
KexAlgorithms +diffie-hellman-group1-sha1
注意点:
是配置jenkins用户下的.ssh,而不是主机下的.ssh
创建文件也一定是jenkins用户,无法切换jenkins用户(我是没有切换成功)可以用 cp 命令,cp 一个jenkins用户的文件,然后对拷贝过来的文件做修改。
解决方法:
首先sonar服务器一定要起来
其次sonarQube server 地址要与docker-compose设置的一致
可以把流水线(pipeline)想象成 13 号线地铁,把流水线的阶段(stage)想象成地铁的每一个站点,把流水线脚本(jenkinsfile)想象成地铁线路图。这就是流水线的多样性,每条线路都有不同的站点。
pipeline脚本的缺点和为什么使用jenkinsfile?
pipeline脚本内容复杂时,在网页编辑和查找都不方便;
无法对脚本文件做脚本管理,例如提交到GitHub上;
jenkinsfile一般放在根目录
WARN: SonarScanner will require Java 11 to run starting in SonarQube 8.x
新版本的sonarqube 最好使用jdk 11
在启动的时候报内存的问题,问题怎么解决网上有教程,当时的问题是不知道怎么按教程去修改(linux命令,Windows不支持)
打开Microsoft Store,搜索ubuntu,然后下载ubuntu版本并安装
启动ubuntu,输入命令(网上解决问题的命令)
重启sonarqube,如果还报,打开docker-设置-Resources-WSL INTEGRATION 有个Ubuntu按钮,点开它,然后再重启sonarqube。
代码规范
潜在的缺陷
糟糕的复杂度分布
重复代码
注释的检测
单元测试
糟糕的设计
bug(错误):标识代码中存在错误,它将在不久的将来爆发出来,它需要立即修复。
code smell(代码味道):代码中与可维护性相关的问题。离开它意味着维护者将更难以修改维护代码。在最坏的情况下,维护人员会在进行更改时引入其它错误,使他们会对代码状态感到困惑
remediation cost(补救成本):修复漏洞和可靠性问题所需的估计时间
security hotspot(安全热点):一个与安全相关的问题,突出显示使用安全敏感API的代码段(如:使用弱算法,连接到没有密码的数据库)
technical debt(技术债务):修复所有可维护性问题/代码味道所需的估计时间
vulnerability(漏洞):与安全有关的问题,它代表攻击者可能攻击的后门