AWS Labs 拿 Amazon S3 搞了 Git Remote?還有 AWS CodeCommit 落日計畫...

昨天看到「S3 as a Git remote and LFS server (github.com/awslabs)」這個東西,本來沒仔細看想說拿 Amazon S3Git 的 backend storage 有什麼特別的,但發現是 AWS 自己搞的東西就... 笑出來?:「git-remote-s3」。

先是看到 id=41892890 這個笑出來:

Wow, AWS really wants to get rid of CodeCommit.

但結果意外看到在 id=41890687 這邊提到 AWS CodeCommit 已經進到 deprecation 階段:

Amazon has deprecated Amazon Code Commit, so this may be an interesting alternative.

沒印象啊,但連到 AWS CodeCommit 的網站上可以確認到這件事情,最上頭就看到不接受新用戶的消息:

AWS CodeCommit is no longer available to new customers. Existing customers of AWS CodeCommit can continue to use the service as normal. Learn more

然後點進去看公告,看起來是七月的公告:「How to migrate your AWS CodeCommit repository to another Git provider」。

After careful consideration, we have made the decision to close new customer access to AWS CodeCommit, effective July 25, 2024. AWS CodeCommit existing customers can continue to use the service as normal. AWS continues to invest in security, availability, and performance improvements for AWS CodeCommit, but we do not plan to introduce new features.

沒注意到這個消息...

Conventional Commits

查資料的時候翻到的,寫 commit 常有 feat: 或是 fix: 這樣的 prefix,剛剛才突然想到這應該是有人訂規範的,翻了一下應該是「Conventional Commits」這個,裡面也引用了另外一個專案:「commitlint」。

所以 type 的部分可以有很多種類,剛剛前面提到的 feat: 以及 fix: 都在裡面:

build
chore
ci
docs
feat
fix
perf
refactor
revert
style
test

對於有規範用英文寫 commit log 的單位可以直接套用,不算太複雜。

馬上想到的好處大概是這樣對於 junior engineer 可以很自然的把 fixfeat 拆開 (其他的也類似),而且對於 code reviewer 也可以注意變化。

Git 的「災難處理」

但印象中之前看過 (在 Internet Archive 上可以看到 4 Sep 2017 的版本),但搜尋 Hacker News 後發現沒有提過... 這幾天紅起來的「Dangit, Git!?!」,也有簡體中文版可以看。

裡面其實提到了很多要怎麼處理不小心塞錯資料進 Git 的情況,不過好像還是有些東西沒涵蓋到,像是遇到不小心塞到 credentials 進去後需要清除掉的 git rebase -i HASH,接著一連串的手動修 conflict 與 git rebase --continue,最後再接上 git push --force 這種禁招...

另外推一下「為你自己學 Git」這本書,裡面其實也有提到類似的情境:

第7章:修改歷史紀錄
7.1 狀況題 修改歷史訊息
7.2 狀況題 把多個 Commit 合併成一個Commit
7.3 狀況題 把一個 Commit 拆解成多個Commit
7.4 狀況題 想要在某些 Commit 之間再加新的Commit
7.5 狀況題 想要刪除某幾個 Commit 或是調整Commit 的順序
7.6 Reset、Revert 跟 Rebase 指令有什麼差別?

這本書也有網頁版,在 gitbook.tw 這邊。

PHP 的 Git Server 被打穿,決定把整個 Git 系統搬到 GitHub 上

就如同標題說的:「Changes to Git commit workflow」,Hacker News 上的討論也可以看一下:「PHP's Git server compromised, moving to GitHub (php.net)」。

Yesterday (2021-03-28) two malicious commits were pushed to the php-src repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).

While investigation is still underway, we have decided that maintaining our
own git infrastructure is an unnecessary security risk, and that we will
discontinue the git.php.net server. Instead, the repositories on GitHub,
which were previously only mirrors, will become canonical. This means that
changes should be pushed directly to GitHub rather than to git.php.net.

不知道發生什麼事情,要等事後的報告出來...

AWS 新的折扣方式 (Saving Plans)

前幾天看到 AWS 推出新的折扣方式,也就是「New – Savings Plans for AWS Compute Services」這篇。裡面給了兩個新的折扣模式:

  • Compute Savings Plans
  • EC2 Instance Savings Plans

首先是 Compute Savings Plans,不限制地區,而且包括了很多類型的服務,不僅是 EC2

The plans automatically apply to any EC2 instance regardless of region, instance family, operating system, or tenancy, including those that are part of EMR, ECS, or EKS clusters, or launched by Fargate.

而 EC2 Instance Savings Plans 則是只有在 EC2 上使用,需要指定地區與機型:

Just like with RIs, your savings plan covers usage of different sizes of the same instance type (such as a c5.4xlarge or c5.large) throughout a region.

就目前的理解來看,EC2 Instance Savings Plans 其實就是換個包裝的 Regional RIs,因為 Regional RIs 本來就可以給同個 family type 使用 (沒有使用到的 c5.xlarge RI 可以拿到 c5.2xlarge 使用,照比率抵一半計算,另外一半照正常價錢)。

Compute Savings Plans 算是新的東西,你給個 hourly commit 付錢後,很多服務都可以使用這筆 hourly commit 折抵。

「Oh shit, git!」:常見的 Git 操作問題

Oh shit, git!」這個站台列出了常見的 Git 問題與可能的解法,不過我最愛最後一個,看起來很萬用的砍掉重練:

cd ..
sudo rm -r fucking-git-repo-dir
git clone https://some.github.url/fucking-git-repo-dir.git
cd fucking-git-repo-dir

雖然最後這個方法有種惡搞感,不過裡面其他提到的問題其實都還蠻常見的,包括了修改最新一個 commit 的 commit log,或是想要再多加一些東西到最新的 commit 上,以及 commit 錯 branch 後要怎麼處理。

看檔案改變的過程

像是這樣的東西:

專案在「pomber/github-history」這邊,目前只支援 GitHub 平台。在選好檔案後,只要把本來網址上的 github.com 改成 github-history.netlify.com 就可以切過去操作了。

主要是看起來頗有趣的,實用性我覺得有點低 XD

PostgreSQL 10 發表

PostgreSQL 10 發表,有不少重要的功能 (進步):「PostgreSQL 10 Released」。

首先提到的是 Logical Replication:

Logical Replication - A publish/subscribe framework for distributing data

以往內建的 replication 是 block level change (同步哪個 block 改變的內容),對於版本不同的 PostgreSQL 就會痛。所以在 10 之前,想要處理 PostgreSQL 版本不同的問題都會使用第三方套件 (一種常見的情境就是資料庫的版本升級)。在 10 內建支援 Logical Replication 後就不需要掛其他套件了:

Logical replication extends the current replication features of PostgreSQL with the ability to send modifications on a per-database and per-table level to different PostgreSQL databases. Users can now fine-tune the data replicated to various database clusters and will have the ability to perform zero-downtime upgrades to future major PostgreSQL versions.

於是就可以達到 zero-downtime upgrade,這對於商業維運考量是個很重要的進展。

另外一個是 Improved Query Parallelism (在 9.6 就有,現在又再改善了),針對可平行化的 CPU-bounded SQL query 可以利用多 CPU 大幅加速,這點也是目前在 MySQL 上還沒看到的:

PostgreSQL 10 provides better support for parallelized queries by allowing more parts of the query execution process to be parallelized. Improvements include additional types of data scans that are parallelized as well as optimizations when the data is recombined, such as pre-sorting. These enhancements allow results to be returned more quickly.

上面提到這兩點其實對於某些需求是相輔相成的。

因為很多報表分析是可平行化的 CPU-bounded SQL query,但以前在 RDBMS 都不能被平行運算,於是很多單位就會想要倒出來到其他類型的資料庫運算 (以現在比較紅的產品,像是 Amazon RedshiftAmazon Athena,或是 BigQuery,甚至是丟進 ELK 裡)。但你用 PostgreSQL 又會痛在沒辦法很方便的把資料同步拉出來... (於是就會稍微妥協,用 cron job 每天倒資料)

現在 10 的這兩個功能剛好從兩個面向解決:一個是對於剛開使用 PostgreSQL 的人,他們可以繼續只用 PostgreSQL 撐久一點,因為報表需求的 SQL query 快很多;另外一方面也讓目前用 cron job 每天倒資料的人有了同步的選擇 (用 replication 同步到其他系統上)。

再來是 Quorum Commit for Synchronous Replication 這個功能,把分散式架構中需要「正確性」的底層技術做起來:

PostgreSQL 10 introduces quorum commit for synchronous replication, which allows for flexibility in how a primary database receives acknowledgement that changes were successfully written to remote replicas. An administrator can now specify that if any number of replicas has acknowledged that a change to the database has been made, then the data can be considered safely written.

整體來說,PostgreSQL 10 有非常多進步,而且這些進步對於商業營運考量都很有幫助...

透過 DMCA takedown notice 非法下掉 Easylist 內的過濾條件

參考「Ad blocking is under attack」這邊,有業主 functionalclam.com 透過 DMCA takedown notice 發信要求 Easylist 移除過濾條件 (參考「2017-08-02-LevenLabs.md」),對應的 commit 參考「M: Removed due to DMCA takedown request」) 這邊。

這件事情再次證實了 DMCA takedown notice 被濫用的情況,明明不是侵權的情況卻被拿來濫用 (因為對原提出者唯一的處罰必須過反過來提告,然後要得自己舉證因為這樣受損)。

目前看起來 EFF 願意介入,就來看看後續了。

GitHub 提供新的 contribution (小綠點) 計算方式

以往 GitHub 在個人頁面上的 contribution 只會計算 public repository,現在則可以設定將 private repository 也統計進去:「More contributions on your profile」。

private repository 的部份只會顯示數量,不會公開任何細節,像是我用 incognito mode (無痕模式) 可以看到在沒有登入時的資訊:

但如果是登入後就會有詳細資料: