没睡好的话工作就容易出错

今天发起的 lockbox 全家桶 build image，每一个的 upload binary 都失败了，需要重新 build

于是就拖到了很晚才临时处理完这个

另外最近 CM 比较多，互相之间又有先后顺序的依赖关系，每一个 Component 都有不同的版本

还很担心漏掉

好好休息也是相当重要的一环

年轻人的第一次 major release

检查了一整天的参数和 component

真的发现有漏掉的，还有若干 Typo

忙里偷闲还在 VM 里搞了下 Docker

准备拿来跑 Jenkins 和 Gitlab

又可以测试 Component Audit

也可以开发 Upload image table

今天的分支版本非常非常多，开会确认了具体的细节

下午几乎又扑在了 code merge pipeline 的 debug 上

测试了昨天写的合并 merge 与 recut

把 token 从本地文件换成了 Jenkins Credentials

一开始写的时候想的太复杂了，其实对于 Secret File，

1
2
3
4

withCredentials([string(credentialsId: 'mytoken', variable: 'TOKEN')]) {
    echo "$TOKEN"
}

显然这个 TOKEN 是不会被 echo 出来的

每天水一发日记混 github commit 也真的是不太行

开日记的初衷是为了记录技术上的学习和成长来着

还是想要多写点 Night shift 时期的学习笔记

比如说今晚又和 react 擦出了怎么样的火花

周五没有仔细检查参数，nucleus 和 nexus 填错了没发现

从长远来看，需要去做一个自动化 parameter check

今天不仅有 production，还有一个新的 CM cut

把 code merge 和 code recut 合并起来了

明天再过来测试

又需要洋洋洒洒70+ commit 了

全是添加删除测试分支水出来的

周五的 merge pipeline 有 bug

今天在用的时候，发现只执行了一半就跳过去了

releases/rel551 这个分支下完全没有更新

后来还是用的 master 分支救急

接着发现如果直接 grep 的话，它会停在 grep 到目标之后就跳去下一步了

甚至最终还是个 success

然后下午又是一通面向 google 和 StackOverflow 编程

终于是找到了在 Jenkins file 里直接操作 console log 的简单办法

1
2
3
4
5
6
7
8
9
10
11
12

def bar = ""
def foo = sh(
    returnStdout: true,
    script: "bash xxx.sh"
)
def arr = foo.split("\n")
arr.each {
    if (it.contains('target')) {
        bar += it
    }
}

像这样就可以找到包含目标字符串的一整行，而且不怕重复出现覆盖掉先前的结果

改了一整天的 code merge pipeline

终于是能够成功获取到 Jenkins file 里某一行特定脚本的输出了

原先是 sh “xxx” 的，其实这里 sh 相当于一个函数

然后就需要写成

sh(returnStdout: true, script: “xxx”)

才可以把输出的内容保存成 string

随后用了 grep 去找里面是不是包含某一个特定的字符串

而为了做这件事情居然花了我五个小时，还是因为不熟悉 groovy 和 Jenkins 吧

在 Jenkins file 里写 lambda 遍历 map 是我最后的倔强

1

npx create-react-app moz-todo-react

直接上脚手架，虽然下载会花上许多时间，但还是可以有一个最最基础的目录结构

用 yarn 的话，带上 --use-npm

基本概念

源码在 src 里（废话

index.js 可以视作整体的入口，但更为核心的内容往往都在 App.js　里

脚手架帮忙做了相当多的事情，最核心的是　ReactDOM.render 那一段

1
2
3
4
5
6

ReactDOM.render(
  <React.StrictMode>
    <App tasks={DATA}/>
  </React.StrictMode>,
  document.getElementById('root')
);

这里的 tasks 目前是传递给 App　这个 Component 的 Prop

和 HTML 属性很像，但在 JSX 里面 class 会叫做 className 来避免和 ES6　语法糖冲突

JSX 里只能用表达式, 语句NG

Components

有用 class 的, 也有用 function 的

涉及到 state 的时候, 用 class

今天先跟着教程写了 function 的那种

1
2
3
4
5
6

export default function Todo(props) {
    return (
        // JSX stuff
        {props.xxx}
    );
}

大概这样就可以在里面用外面通过 props 传给 Component 的一些数据了

在需要传的数据有很多的时候这样一个个写出来会很吓人

一早过来之后，porpoise 的 MR 已经 Approve 了

于是 build image 测试了下，pass

那么这个 pipeline 的修改分支 MR 也能被 Approve 了

今天的 cut 里面发现 Code-Merge-Pipeline 在执行 merge 之前并不会 diff

也就是说它并不会确认要合并的目标分支和当前分支之间的差别

就导致了新的改动并没有更新进去，后来在 bash 脚本的语法上纠结了非常长的一段时间

最终是通过 git diff 的输出有没有 + 或 - 来判断有没有 change，临走前提了个 MR，Approve 了

然后玩了会 EADP JIRA，给 fix pipeline 做了个补充 work log

大概这个任务就结了

下午收到了邮件，记录着不同部分的具体 Owner 和 Backup，要熟悉一下 emergency flow 和 drive test sign off

昨晚再一次确认了 component audit pipeline 的细节，但是要修改的还是有很多，明天来做这件事情

在今天确认 Get Component 的时候，发现在它给出的 Component 列表以外，仍然需要人工去确认 gitlab

也就是说这个和 component audit pipeline 没有啥关联是吧，明天需要确认

明天需要 focus on component audit pipeline 的 Console output 整理

事情很多，需要排优先级顺序

写日记的时候发现 KB212 反应有些慢，主要是回弹和按键触发力度上，有点跟不上自己

早上发现上回的 cut 漏掉了 guardiola，是人工检查的时候出的差错

后来 James 开了个 pipeline 来让糊成一团的 console log 变得更友好

写了个框架，后面的我来填

其实就是不同的 component 信息，难受的点在于确认既没有多出来，也没有漏掉

大体找了一些，明天会继续做这件事情，对照 component list 和历史记录

今天也是一下午都在fix fast-liquibase pipeline

从 Infra Team 那里得到了回答，对包里没有 my-liquibase.py 的加入了对 cassandra.py 的支持

然后发现 liquibase 这个文件没有执行权限，所以脚本里也处理了下

在测 porpoise 的时候发现 jdbc_url 配置有问题，向 Zezhou Li 提了个 MR

和 James 和 Lu Zhong 开了个小会，我需要弄明白 sox-audit 和 component_audit 这两个的 Java 部分

Script 部分由 Lu Zhong 负责，而我也需要懂一些

其中有个文件里写了一些需要跳过的 components，后面需要确认这些是否依然需要跳过

和谁确认？明天再来问问 Kyle

明天还需要来重点着手解决 component audit pipeline 的 error log

上回的 java service 后来又变成了用 git 和 gitlab 的 api 来解决

好像是变成了用 pipeline 来做，还需要去玩一下如何把 csv 转成 markdown 的格式

今天花了很多时间在 fix fast-liquibase pipeline 上

问了很多问题，最后涉及到 Cassandra 的部分还是需要去问 Infra Team，等明天的答复

对照 wiki 确认了有 liquibase.data 的 component，接着再去 Artifactory 上一个个找到对应的 tarfile 文件夹路径，写了一长串极其吓人的 if-else，终于是能够成功获取到 tarfile 了

剩下的细节明天再来处理看看

也许大概从 Yanqin 那里接到了一个新的任务。

release步骤相当零散，做出来的 image 也是手工去填进 confluence，这个位置也没法填写进 pipeline

所以需要有一个中心化的 service，去存储每次 build 出来的 image

两种实现方案，一种是调用 git 和 gitlab 的 api，更新文件从而生成一个 markdown

另一种是自己写一套，可以参考 ReleaseMe，照猫画虎搞个量产型

可以用 activemq 和 MySQL， 本地可以搭一个 Linux VM

这两天需要给出一个具体细节的 task 步骤，和 Yanqin 过一下

明天过来之后也想要了解如何给自己在 EADP-JIRA 上给自己开个 ticket，追踪自己正在做的事情

明天还需要至少解决剩下两个问题中的其中一个