0%

在特定情况下,用 nginx 反代 git 仓库,且避免出现 go get meta tag did not match import path 的报错。

配置如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
location / {
if ($query_string ~ "go-get=1") {
set $condition goget;
}
if ($uri ~ ^/([a-zA-Z0-9_\-\.]+)/([a-zA-Z0-9_\-\.]+).*$) {
set $condition "${condition}path";
}
if ($condition = gogetpath) {
return 200 '
<!DOCTYPE html>
<html>
<head>
<meta name="go-import" content="$host/$1/$2 git http://$host/$1/$2.git">
<meta name="go-source" content="$host/$1/$2 _ http://$host/$1/$2/src/mster{/dir} http://$host/$1/$2/src/master{/dir}/file#L{line}">
</head>
<body>
$uri
</body>
</html>
';
}

proxy_pass http://原本的git仓库;
}

后续 go get 时,可能出现 terminal prompts disabled 的报错,使用 GIT_TERMINAL_PROMPT=1 go get 方可化解。

记几个命令行,用来暂停/恢复 spotlight 搜索的索引进程:


As you know, the mds and mds_stores are Spotlight activities.

The reason why your Spotlight is so active could be a number of things; it could be you have an app or multiple apps constantly changing some folder contents.

First let's check whether Spotlight is the cause of the fans running so much. To test this, run the following in your terminal:

1
sudo mdutil -a -i off # 暂停索引建立

this turns off indexing of files, and should result in a clear slow down of the fans if mds and/or mds_stores are to blame.

To turn indexing back on, run:

1
sudo mdutil -a -i on # 恢复索引建立

After this you could run the complete re-indexing of your hard drive (be aware this could be an over night job), it will delete your Spotlight data base forcing it to start over.

1
sudo rm -rf /System/Volumes/Data/.Spotlight-V100/*

The next and final step would be to add others to your (do not scan), privacy settings.

参考自: https://apple.stackexchange.com/questions/144474/mds-and-mds-stores-constantly-consuming-cpu


mdutil 用法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ mdutil --help
mdutil: unrecognized option `--help'
Usage: mdutil -pEsa -i (on|off) -d volume ...
mdutil -t {volume-path | deviceid} fileid
Utility to manage Spotlight indexes.
-i (on|off) Turn indexing on or off.
-d Disable Spotlight activity for volume (re-enable using -i on).
-E Erase and rebuild index.
-s Print indexing status.
-a Apply command to all stores on all volumes.
-t Resolve files from file id with an optional volume path or device id.
-p Publish metadata.
-V vol Apply command to all stores on the specified volume.
-v Display verbose information.
-r plugins Ask the server to reimport files for UTIs claimed by the listed plugin.
-L volume-path List the directory contents of the Spotlight index on the specified volume.
-P volume-path Dump the VolumeConfig.plist for the specified volume.
-X volume-path Remove the Spotlight index directory on the specified volume. Does not disable indexing.
Spotlight will reevaluate volume when it is unmounted and remounted, the
machine is rebooted, or an explicit index command such as 'mdutil -i' or 'mdutil -E' is
run for the volume.
NOTE: Run as owner for network homes, otherwise run as root.

安装还在仓库里的 formula

如果需要用 Homebrew 安装已经被 disable 掉的 formula,例如需要安装 v1.12 版本的 golang, 使用 brew install go@1.12 是无法安装的,需要修改对应的 formula 脚本:

1
> brew edit go@1.12

该操作会在默认的编辑器中打开位于 /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula 目录下的 go@1.12.rb 脚本文件。

编辑脚本文件,找到 disable 方法的调用,并注释掉,例如:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class GoAT112 < Formula
desc "Go programming environment (1.12)"
homepage "https://golang.org"
url "https://dl.google.com/go/go1.12.17.src.tar.gz"
mirror "https://fossies.org/linux/misc/go1.12.17.src.tar.gz"
sha256 "de878218c43aa3c3bad54c1c52d95e3b0e5d336e1285c647383e775541a28b25"
license "BSD-3-Clause"

# ......

keg_only :versioned_formula

disable! date: "2021-02-16", because: :unsupported # **就是这一行** TODO: 注释掉

depends_on arch: :x86_64

# ......

之后,再次使用 brew install go@1.12 ,虽然会有 warning 但最终还是可以顺利安装 v1.12 版本的 golang 。

安装已给移除仓库的 formula

通过 github 仓库搜索 go@1.12.rb, 在 commits 中找到对应的提交。将 rb 文件保存到本地, 例如: go@1.12.rb 。 然后执行:

1
> HOMEBREW_NO_INSTALL_FROM_API=1 brew install ./go@1.12.rb

温故 base64 编码过程。

虽然现在绝大多数编程语言都已经在标准库中实现了 base64 编码和解码,但还是要时不时回顾其原理。

编码原理

TLDR: 将 8 位 二进制串 分割为 多个 4 个 6 位 二进制串,参考 https://zh.wikipedia.org/wiki/Base64

  • 将每个字符都转换成对应的 ASCII
  • 将每个 ASCII 码由十进制转为 8 位二进制
  • 将这些二进制按照每 6 位分进行分隔,4 个 6 位二进制位 一组 ,若在分隔的时候,位数不够则用 0 填补在末尾
  • 将这些 6 位的二进制重新转为十进制,并根据十进制数在 base64 索引表 中找到对应的编码。
  • 若构不成 一组,则用 = 号填补在末尾

编码 (encode) 过程如下:

Text
ASCII
8 Bit
Index
Base64
1
echo -n 'mixx' | base64 # 输出: bWl4eA==

程序简单实现

阅读全文 »

最近恰巧有机会在一台 Centos 物理机上搭建 Jenkins, 也借此机会实践了从 git 提交自动触发 Jenkins build 的工作流,故在此记录,以作备忘。

Jenkins 安装

docker 镜像在 https://hub.docker.com/r/jenkins/jenkins

docker-compose.yml 配置如下:

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

services:
jenkins:
image: jenkins/jenkins:lts-alpine-jdk11
ports:
- '8180:8080' # web 端口
- '50000:50000'
volumes:
- ./jenkins/:/var/jenkins_home # 持久化
environment:
TZ: "Asia/Shanghai"

需要注意宿主机的 ./jenkins/ 目录需要将用户和组更改为 1000:1000:

1
> sudo chown -R 1000:1000 ./jenkins

启动之后,进入 web 界面,需要输入 admin 的密码,这个密码可以在容器的日志中获得:

1
> docker-compose logs jenkins # 查看容器日志
1
2
3
4
5
6
7
8
9
10
11
12
13
14
jenkins_1  | *************************************************************
jenkins_1 | *************************************************************
jenkins_1 | *************************************************************
jenkins_1 |
jenkins_1 | Jenkins initial setup is required. An admin user has been created and a password generated.
jenkins_1 | Please use the following password to proceed to installation:
jenkins_1 |
jenkins_1 | aee0014b14124efe03c361e1eed93589
jenkins_1 |
jenkins_1 | This may also be found at: /var/jenkins_home/secrets/initialAdminPassword
jenkins_1 |
jenkins_1 | *************************************************************
jenkins_1 | *************************************************************
jenkins_1 | *************************************************************

接下来建议直接选择安装社区 推荐 的插件,然后进行简单配置后,就可以正常登陆到 Jenkins 控制台了, 然后进行slave节点配置,顺便配置下域名反代。

阅读全文 »

之前的博客是需要在我本地电脑上手动执行命令来部署的:

1
> make deploy

如今已经成功将这个部署的过程迁移到了 Github Actions。 整个 workflow 包括 npm 依赖的安装和缓存,将 Markdown 生成静态 html 文件,和部署到服务器。

配置如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
name: deploy

on:
push:
branches:
- 'master' # 只会在 master 分支发生 push 事件时,才触发

jobs:
deploy:
runs-on: ubuntu-latest
environment: # 环境变量在 github 项目的设置页面里进行配置
name: deploy # 这里需要手动进行授权,才会进行job
steps:
- name: Checkout Code
uses: actions/checkout@v2

# 指定 nodejs 版本
- name: Setup Nodejs
uses: actions/setup-node@v2
with:
node-version: '12'

# 依赖缓存设置
- name: Cache node dependency
uses: actions/cache@v2
with:
path: ~/.npm # 缓存目录
key: cache-node-${{ hashFiles('**/package-lock.json') }} # 缓存的key
restore-keys: | # 恢复缓存时要去匹配的key
cache-node-
cache-

# 安装 npm 依赖包
- name: Install dependency
run: npm install

# 生成静态文件
- name: Build to static
run: make build

# 部署到服务器,使用 rsync 来传递文件
- name: Deploy to server
uses: burnett01/rsync-deployments@5.1
with:
switches: -azvhP --delete
path: ./public/
remote_path: ${{ secrets.SSH_REMOTE_PATH }} # secrets 在 github 项目的设置页面里进行配置
remote_user: ${{ secrets.SSH_USER }}
remote_host: ${{ secrets.SSH_HOST }}
remote_port: ${{ secrets.SSH_PORT }}
remote_key: ${{ secrets.SSH_SECRET }}

近日有机会在 Linux 环境中从零开始使用 docker 部署 JIRA, 在此记录下部署过程中遇到的问题及解决.

镜像选择

在 docker 的镜像仓库中搜索 'jira', 会看到好几个相关的镜像: atlassian/jira-software, atlassian/jira-core 等. 这里应当选择 atlassian/jira-software.

初次启动

根据 dockerhub 中的描述, 编排出下面的 docker-compose.yml 配置:

1
2
3
4
5
6
7
8
9
10
11
version: '3'

services:
jira:
image: atlassian/jira-software
environment:
TZ: Asia/Shanghai
ports:
- "18081:8080"
volumes:
- ./jira-data:/var/atlassian/application-data/jira # 应用数据持久化

启动之后, 进入web界面, 选择手动配置, 然后开始配置 JIRA.

在配置数据库时, 此时还只能选在内置数据库, 不能选择 MySQL 或者 PostgreSQL, 因为 atlassian/jira-software 镜像中并没有包含连接 MySQL 或 PostgreSQL 的驱动 jar 包. 接下来就需要去下载对应的 jar 包, 并将其放入容器中特定的目录下, 来完成 MySQL 或 PostgreSQL 的配置.

阅读全文 »

回首这些年工作和业余时间的 git 使用,发现在提交内容时,写的 commit message 其实并没有做到统一和规范化。 于是抽空去 Google 了一番,发现有不少的开源项目在使用一种语义化的提交。 这种语义化的提交能够做到足够简短且开门见山。 看过之后确实也是受益匪浅,故在此记录。

https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716 。 这是一个拥有 2k+ star 的 gist,里面陈述着语义化提交的基本范式。 下面是我个人对这套规范的理解。

语义化的提交

来看看这个提交信息的小小改动,能对你的程序带来多少益处吧。

格式: <type>(<scope>): <subject>,其中 <scope> 是非必要的。

1
2
3
4
5
6
git commit -m "feat: add hat wobble"
^--^ ^------------^
| |
| +-> 总结内容(subject),注意是用现在时态
|
+-------> 类型(type): chore, docs, feat, fix, refactor, style, test

不同类型(type)的语义

Type语义
feat针对用户侧的新特性。是对外的而非对内的
fix针对用户侧的 bug 修复。是对外的而非对内的
docs仅文档内容的变更
style仅格式化相关,比如行尾的分号(;),空格等。不影响线上使用
refactor重构功能代码,如重命名变量,抽象方法等
test添加或重构单元测试。不影响线上使用
chore更新 CI/CD 流程、任务或脚本。不影响线上使用

Fuzzing is Beta Ready

原文地址 : https://blog.golang.org/fuzz-beta

作者 : Katie Hockman and Jay Conrod

时间 : 3 June 2021

我们兴奋地宣布: 原生 fuzzing 已经可供beta测试了,就在 dev.fuzz 中的 development 分支里!

Fuzzing 是自动化测试的一种,通过持续操控程序的输入来找出问题,比如说 panic 或 bug。 这些半随机的变换数据能够覆盖到已有单元测试所遗漏的地方,并且揭露出一些不易察觉的边界 bug。 正因为 fuzzing 可以抵达这些边界情况,fuzz 测试对于查找安全漏洞和弱点是尤为重要的。

详见 golang.org/s/draft-fuzzing-design

Getting started

你可通过运行下面命令来上手

1
2
$ go get golang.org/dl/gotip
$ gotip download dev.fuzz

该操作从 dev.fuzz 的 development 分支构建 Go toolchain,将来一旦代码合并到了 master 分支就不用这样了。 运行之后,gotip 可以看做 go 命令的绿色替代 (drop-in replacement)。 你现在可以这样运行命令

1
$ gotip test -fuzz=FuzzFoo

因为在 dev.fuzz 分支中会不断地开发和bug修复,所以你应当有规律地执行 gotip download dev.fuzz 来应用最新的代码。

为兼容已发行的 Go 版本,在提交含有 fuzz target 的源文件到仓库时,要使用 gofuzzbeta build tag。 dev.fuzz 分支中,这个 tag 在 build-time 是默认开启的。 如果你对 tags 使用有疑问,参考 the go command documentation about build tags

1
// +build gofuzzbeta
阅读全文 »

Context and Structs

原文地址: https://blog.golang.org/context-and-structs

作者: Jean de Klerk, Matt T. Proud

时间: 24 February 2021

Introduction

在许多尤其是现代的 Go API 中, function 或 method 的第一个参数常常是 context.Context. Context 为传输提供了 deadline, 为调用方提供了 cancellation, 也为其他进程间跨 API 请求提供了传值手段. 它常常被间接或直接使用了远程服务的库所使用, 例如数据库, API 等.

Context 文档 所述:

Context 不应存储在 struct 内部, 而应传给需要它的 function.

这篇文章就是针对上述建议的详述, 通过举例说明的方式来阐述为什么要传递 Context 而不是存储在另一个 type 里. 本文也强调了一种边缘情况: 将 Context 存储在 struct 中也是合理的. 以及如何安全实现.

阅读全文 »