總結之提交代碼並部署到服務器上，為什麽代碼卻沒有更新？
遇到過幾次這種情況：開發將代碼提交之後，通過打包部署，發現部署到服務器上的代碼不是最新的，還是修改之前的老代碼。
打包部署流程背景說明：
gitlab——》jenkins服務器打jar包——》將打好的jar包過濾並推送到服務器A上build鏡像——》將鏡像推送到harbor倉庫——》部署容器到服務器
1、代碼沒有提交成功
這個不用多說，遇到過幾次。
2、jenkins上的緩存沒有清除
例如test服務的構建包的緩存目錄就是在jenkins服務器的~/.m2/repository/com/run/test-api 這個test服務打包會生成這個緩存api目錄，因此在每次打包之前，腳本要寫好先rm -rf ~/.m2/repository/com/run/test-api ，再進行打包操作。
3、jenkins上面的工程目錄變更，而打包腳本沒有更新
例如：jenkins上有一個叫“rpc”的構建項目。有一次同事將jenkins上面的rpc改成了“IOT”，然後構建部署，發現打出來的包裏面的代碼不是最新的。
原因是構建項目原來的名字是rpc，在jenkins的工程目錄下面生成的目錄也是rpc，當將rpc改成了“IOT”，就會在jenkins的~/.jenkins/workspace目錄下面生成新的工程目錄“IOT”，最新提交的代碼打好的包也是在這裏。但是jenkins的打包腳本並沒有更新，還是默認去~/.jenkins/rpc目錄下面找打成的jar包，導致不管構建多少次，每次找到的jar包都是rpc目錄下面的，都是老的包。
4、jar包命名規則變更，腳本原有命令過濾不到包
例如test-0.0.1.jar 這個包，原本jenkins打出來的包就是這個名字，中途開發變更了命名規則，變成了tes-0.0.1.RELEASE.jar ，但是jenkins的打包腳本並沒有更新，還是用原來的命令ls ~/.jenkins/workspace/tes/target/tes-|grep -E "[0-9.]{1,7}.jar\$"去找這個jar包，然後推送到服務器A上面去build鏡像，但是因為變更了jar包的名字，找不到新的包，實際上還是用A服務器上老的代碼包打的鏡像部署到服務器上，因此還是老的代碼。
（備註：因為推送jar包、build並push鏡像、部署都是在jenkins腳本裏面遠程完成的，找不到tes-0.0.1.RELEASE.jar這個包，jenkins構建應該是會報錯的，但是第一次遇到的是jenkins沒有報錯，所以沒有及時看出問題，但是在構建第二次的時候，就報錯了，提示找不到包，需要註意這個坑）
5、Dockerfile有變更，導致打包有問題
例如下面的這個構建，在jenkins構建的時候日誌並沒有報異常，但是部署好的鏡像卻是老的包。在服務器A上面去手動執行build鏡像，發現少了一個文件，導致其實新的鏡像並沒有構建成功，而且harbor倉庫裏面鏡像的更新時間也不是最新的：
[root@slave-4 test]# /usr/bin/docker build -t registry.seff.com/seff/test:latest /usr/local/src/test
Sending build context to Docker daemon 35.51 MB
Step 1 : FROM docker.io/java:jre-alpine
---> fdc893b19a14
Step 2 : ADD authz-service-crud.jar /var/www/
---> Using cache
---> 9be1e7e46629
Step 3 : ADD server.properties /opt/settings/
---> Using cache
---> 1a42bca461fe
Step 4 : ADD localtime /etc/
---> Using cache
---> 5668e7e0f7bb
Step 5 : WORKDIR /var/www/
---> Using cache
---> adaee0558909
Step 6 : ADD crud-dump /etc/
---> Using cache
---> 4ab8834f71a9
Step 7 : ADD crud-heap_trace.txt /etc/
**lstat crud-heap_trace.txt: no such file or directory**因此將缺失的文件補充好，然後重新build鏡像，再部署就OK了
總結之提交代碼並部署到服務器上，為什麽代碼卻沒有更新？