「Git」- 网络加速、提高代码拉取速度

问题描述
但凡要去国外搞点东西回来,这网络就慢的不行。还要有各种加速方法,让我们可以把东西顺利的搞回来。当然,我们这里并不是要介绍这些方法,而是要介绍如何使用,并且每种工具使用这些方法的方式都是不同的(技术文章的断句事件非常痛苦的事情)。
在到 GitHub 拉取那些纯净无害的代码时,我们就会遇到这种网络问题。这时候我们就需要配置 Git 来使用网络加速服务,以提高代码拉取速度。
该笔记将记录:在 Gti 中,如何使用网络加速服务,以提高代码拉取速度,以及相关问题处理。
解决方案
持久配置
修改配置文件:

# 配置当前仓库,以及取消配置
git config http.proxy ‘socks5://127.0.0.1:7070’ # 通过袜子协议:-)
git config –unset http.proxy

# 全局配置,以及取消配置
git config –global http.proxy ‘http://127.0.0.1:8123’
git config –global –unset http.proxy

注意事项: 1)选项 http.proxy 适用于 HTTP 与 HTTPS 协议; 2)对于那些调用 Git 命令来拉取代码的程序,使用 全局配置 方式基本是唯一的选择;
临时配置
仅对本次克隆有效:

# 方法一、命令行选项
git clone https://github.com/xxxxx –config ‘http.proxy=socks5://127.0.0.1:1234′

# 方法二、环境变量
ALL_PROXY=’socks5://127.0.0.1:8888’ git clone https://github.com/some/one.git

特殊场景
仅针对某个地址使用网络加速(并且禁用 SSL 验证):

git config –global http.https://domain.com.proxy “http://proxy.example.com:port”
git config –global http.https://domain.com.sslVerify false

相关链接
关于网络加速的更多配置,参考 Configure Git to use a proxy 页面。
参考文献
Using a socks proxy with git for the http transport[……]

READ MORE

「Git」- 查看在提交中被修改的文件

问题描述
我们需要找到在提交中修改的文件,以进行某些操作。
该笔记将记录:在 Git 中,如何获取在提交中被修改的文件。
解决方案
获取_在某次提交中_修改的文件:

# git diff-tree –no-commit-id –name-only -r 35285f296b68617c0198e770a6a5ca0a7b2db6e8
src/com/k4nz/blog/BlogStorage.groovy

使用 git log 命令查看:

# git log –name-status
commit 7723f2548c26655be9f282ba7a317c9192073c05 (grafted, HEAD -> master, origin/master, origin/HEAD)
Author: Sandeep Somavarapu <sasomava@microsoft.com>
Date: Sat Nov 28 10:11:01 2020 +0100

Fix #109406

A .devcontainer/README.md
A .devcontainer/cache/.gitignore
A .devcontainer/cache/before-cache.sh

仅显示修改的文件:

# git log –format=format: –name-only
.devcontainer/README.md
.devcontainer/cache/.gitignore
.devcontainer/cache/before-cache.sh
.devcontainer/cache/build-cache-image.sh
.devcontainer/cache/cache-diff.sh
.devcontainer/cache/cache.Dockerfile
.devcontainer/cache/restore-diff.sh
.devcontainer/devcontainer.json

参考文献
github – Getting a commit count for each file in a git repository – Stack Overflow How to find the number of files changed from one commit to another in git – Stack Overflow git – Which Jenkins Command to Get the List of Chang[……]

READ MORE

「Git」- 常见错误、常见问题

在 Windows 中,执行特别慢
问题描述: 在 Windows 中,Git Bash Here,当窗口启动后,命令提示符要经过数秒才能显示,并且执行(比如 git status 等等)命令需要数秒才能显示。
原因分析: git commands running slow as hell · Issue #1129 · git-for-windows/git · GitHub Git commands have a 2-3 second delay before returning to the prompt · Issue #1070 · git-for-windows/git · GitHub 2.11.1 slow enough to make it unusable in Windows 10 x64 – upgraded from 2.9 lighting fast · Issue #1071 · git-for-windows/git · GitHub
解决方案: 针对我们的问题,我们通过 Nvdia 驱动提供的「Nvdia 控制面板」将「图形处理器」设置为「高性能 NVIDIA 处理器」来进行解决该问题(我们未深究,也不是很懂,可能并不适用于其他场景)。
fatal: refusing to merge unrelated histories
Git refusing to merge unrelated histories on rebase
使用–allow-unrelated-histories选项。
fatal: index file smaller than expected
git – index file smaller than expected – Stack Overflow
原因分析:我们猜测是异常宕机,导致正常执行的 git 命令突然退出,而导致 .git/index 文件损坏;
解决方案:删除 .git/index 文件;
关于 TLS 的错误
Problem with the SSL CA cert (path? access rights?)
GIT ERROR: PROBLEM IN THE SSL CERTIFICATE, VERIFY THAT THE CERTIF. CA IS OK | Robert Menetray
问题描述:

# git push origin master
fatal: unable to access ‘https://git.example.com/foo.git/’: Problem with the SSL CA cert (path? access rights[……]

READ MORE

「Git」- Could not resolve refs/tags/v0.9

问题描述
在Jenkins中,当执行git rev-parse refs/tags/v0.9{commit}命令时,提示如下错误:

ERROR: Could not resolve refs/tags/v0.9
hudson.plugins.git.GitException: Command “git rev-parse refs/tags/v0.9^{commit}” returned status code 128:
stdout: refs/tags/v0.9^{commit}

stderr: fatal: ambiguous argument ‘refs/tags/v0.9^{commit}’: unknown revision or path not in the working tree.
Use ‘–‘ to separate paths from revisions, like this:
‘git <command> [<revision>…] — [<file>…]’

但是,在本地可以执行。
问题原因
推测是 Git 版本导致,因此尝试升级 Git 版本。然而并不是…………升级版本之后依旧出现该问题。
由于在命令行中所指定的 TAG 不存在,从而导致该问题出现。
解决办法
那还能怎么办,后头检查在 Jenkins 中配置,发现是自己的失误……仓库配置错误,在该仓库中没有进行命令行中的TAG定义。
参考文献
GIT fatal: ambiguous argument ‘HEAD’: unknown revision or path not in the working tree[……]

READ MORE

「Git」- 处理 Could not restore untracked files from stash entry 问题

问题描述
使用 git stash –include-untracked 命令,当使用 git stash pop 命令时,产生如下信息:


Could not restore untracked files from stash entry

问题原因
Why does git stash pop say that it could not restore untracked files from stash entry? – Stack Overflow
解决办法

git checkout stash — .

参考文献
Why does git stash pop say that it could not restore untracked files from stash entry? – Stack Overflow[……]

READ MORE

「Git」- fatal: git fetch-pack: expected shallow list

问题描述
在 Gitlab CI/CD 中,执行 Job 返回如下错误:

Running with gitlab-runner 12.6.0 (ac8e767a)
on common-node T-sTrvjZ
Using SSH executor…
Running on centos-001 via eec8077625c3…
Fetching changes with git depth set to 50…
warning: templates not found builds/T-sTrvjZ/0/clientp/foo/webstie.tmp/git-template
Reinitialized existing Git repository in /home/d3rm/builds/T-sTrvjZ/0/clientp/foo/webstie/.git/
fatal: git fetch-pack: expected shallow list
fatal: The remote end hung up unexpectedly
ERROR: Job failed: Process exited with status 1

问题原因
在 CentOS 7 中,Git 版本比较旧(相当旧)。
解决方法
升级 Git 版本,参考 Git/Installing and upgrading 笔记
参考文献
gitlab runner doesn`t work on a specific project – Stack Overflow[……]

READ MORE

「Git」- -bash: __git_ps1: command not found

问题描述
在 Bash 中,可以将 __git_ps1 添加到 PS1 中,已在命令行显示当前分支。
但是,在 CentOS 7.4 中,设置 export PS1=”\u@\h \w “‘$(__git_ps1 ” (%s)”)'”# ” 之后,产生如下错误:

-bash: __git_ps1: command not found

问题原因
原因有很多,这里只记录我们遇到的场景: 1)这个 Shell 函数是 git 提供的(不是 1Bash Completion 提供),而 git-prompt.sh 没有载入。
解决办法
第一步、下载脚本

curl -o /etc/bash_completion.d/git-prompt.sh \
https://raw.githubusercontent.com/git/git/master/contrib/completion/git-prompt.sh

第二步、重新登录,或者 source /etc/bash_completion.d/git-prompt.sh
参考文献
macos – (Mac) -bash: __git_ps1: command not found – Stack Overflow[……]

READ MORE

「Git」- git rev-parse returned status code 128

问题描述
在 Jenkins 中,当构建开始后发生如下错误:

> git rev-parse remotes/origin/test^{commit} # timeout=10
hudson.plugins.git.GitException: Command “git rev-parse remotes/origin/test^{commit}” returned status code 128:
stdout: remotes/origin/test^{commit}

stderr: fatal: ambiguous argument ‘remotes/origin/test^{commit}’: unknown revision or path not in the working tree.
Use ‘–‘ to separate paths from revisions, like this:
‘git <command> [<revision>…] — [<file>…]’

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2010)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2006)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1638)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1650)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:835)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at hudson.plugins.git.RevisionParameterAction.toRevision(RevisionParameterAction.java:98)
at hudson.plugins.git.GitSCM.[……]

READ MORE

「Gogs」- 安装(Linux、CentOS)

问题描述
该笔记将记录:在 CentOS 7.x 中,安装 Gogs 0.11 的方法,以及相关问题的解决方法。
第一步、安装环境依赖
安装数据库服务
MySQL Version >= 5.7 / PostgreSQL / TiDB / NOTHING with SQLite3
由于我们用户量较小,所以我们使用 SQLite3 数据库,因此无需安装任何数据库服务。
安装 Git 命令

# apt-get install -y git

# yum install -y git

第二步、安装并运行服务(CentOS 7.5)
From packages – Gogs Installation of gogs/gogs v0.11.91 for CentOS / RHEL 7 64 bits

# 安装 Gogs 服务
wget -O /etc/yum.repos.d/gogs.repo https://dl.packager.io/srv/gogs/gogs/master/installer/el/7.repo
yum install -y gogs

# 配置 Nginx 服务
cat > /etc/nginx/conf.d/gogs.conf <<EOF
server {
listen 80;
server_name gogs.example.com;

client_max_body_size 20m;

location / {
proxy_pass http://127.0.0.1:6000;
}
}
EOF

systemctl enable nginx.service
systemctl start nginx.service

# 初始化配置
# 浏览器访问 http://gogs.example.com

如果使用该方法安装,则配置文件位于 /etc/gogs/ 目录中(请勿修改 /opt/gogs/conf/app.ini 配置文件)。
# 08/06/2021 当时,我们安装 Gogs 0.11 版本的时候,忘记在文档中记录如何设置管理员帐号。后来,我们测试 0.12.3 版本时,首个注册的用户将成为管理员。所以,今天在这里进行补充记录。
相关链接
通过二进制包安装:From binary – Gogs 修改配置并运行:Config and run – Gogs
我们安装的版本:

# yum info gogs.x86_64

Installed Packages
Name : gogs
Arch[……]

READ MORE

「Gogs」- 升级 0.11.91 到 0.12.3 版本(迁移、Docker Compose)

问题描述
最开始我们使用 YUM 安装 Gogs 0.11.91 版本,但是在 YUM 仓库中的 Gogs 使用未升级。
官方现在(08/06/2021)已经发布到 0.12.3 版本,我们只能采用其他方式升级到 0.12.3 版本。
该笔记将记录:在 CentOS 中,将 Gogs 0.11.91 升级到 0.12.3 版本的方法,以及相关问题的解决方案。
解决方案
官方主页提供 binary、source、package 安装方式,GitHub 仓库提供 Docker 安装方式。
经过对比,对于此次升级,我们使用 Docker 部署(使用 Docker Compose 编排)。
第一步、停止服务,并备份数据

systemctl stop gogs.service gogs-web.service gogs-web-1.service

rsync –progress -avz /home/gogs/gogs-repositories/ /srv/backup/gogs/gogs-repositories-20210806

第二步、创建数据目录
在测试 Gogs 0.12.3 版本时,我们发现其目录结构如下:

# tree -L 3
.
├── git
│   └── gogs-repositories
│   └── team-common
├── gogs
│   ├── conf
│   │   └── app.ini
│   ├── data
│   │   └── gogs.db
│   └── log
│   ├── gogs.log
│   ├── gorm.log
│   └── xorm.log
└── ssh
├── ssh_host_dsa_key
├── ssh_host_dsa_key.pub
├── ssh_host_ecdsa_key
├── ssh_host_ecdsa_key.pub
├── ssh_host_ed25519_key
├── ssh_host_ed25519_key.pub
├── ssh_host_rsa_key
└── ssh_host_rsa_key.pub

需要进行如下操作,来创建数据目录:

mkdir -pv /srv/hdd/gogs/

mkd[……]

READ MORE

「Gogs」- 常见错误汇总

fatal: the remote end hung up unexpectedly / 413 Request Entity Too Large
Nginx Upload Module – Nginx Guts Module ngx_http_core_module/client_body_temp_path Nginx failed space when upload – Server Fault
问题描述

# git push -u origin master
Enumerating objects: 15899, done.
Counting objects: 100% (15899/15899), done.
Delta compression using up to 4 threads
Compressing objects: 100% (8080/8080), done.
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large
fatal: the remote end hung up unexpectedly
Writing objects: 100% (15899/15899), 75.80 MiB | 102.40 MiB/s, done.
Total 15899 (delta 8964), reused 13944 (delta 7312)
fatal: the remote end hung up unexpectedly
Everything up-to-date

问题原因
看到错误日志中的 413 Request Entity Too Large 提示,我们就立刻想到是 Nginx 配置原因。通常较大的仓库会遇到该问题。
解决办法
在 Nginx 中,添加 client_max_body_size 配置:

server {
listen 80;
server_name gogs.example.com;

client_max_body_size 200m;

location / {
proxy_pass http://127.0.0.1:6000;
}
}

fatal: the remote end hung up unexpectedly
问题描述
在 git push 时,产生如下错误:


fatal: the remote end hung up unexpectedly

原因分析[……]

READ MORE

「Mercurial」

常见错误汇总
#1 执行 hg paths default 返回 not found!
我们的原因是 Mercurial 的版本问题,项目检出是 Mercurial Distributed SCM (version 4.0) 版本,而执行其他操作时环境是 Mercurial Distributed SCM (version 1.6.3) 版本。[……]

READ MORE

「Subversion」- 杂记

安装方法(编译安装)
版本:Subversion 1.9.5 主页:https://subversion.apache.org/ 文档:https://subversion.apache.org/docs/community-guide/ 下载:https://subversion.apache.org/download.cgi
安装过程 参考 BLFS/Subversion-1.9.5 手册
附加说明 在编译时指定 serf 库,可以使 SVN 支持 http 形式的项目地址:

–with-serf=PREFIX Serf HTTP client library (enabled by default if found)

安装的二进制文件

bin
├── svn # 用于访问 Subversion 版本库的工具;
├── svnadmin # 用于创建、调整、修复 Subversion 版本库;
├── svnbench # 标杆管理工具;
├── svndumpfilter # 过滤 svn仓库dump文件的工具
├── svnfsfs # FSFS(FileSystem atop of the FileSystem – Subversion filesystem implementation) 仓库操作工具
├── svnlook # 版本库检查工具;
├── svnmucc # 多URL命令客户端;
├── svnrdump # 用于查看远端仓库信息;
├── svnserve # 独立的服务端程序,用于创建服务进程 或者 被 ssh 调用;
├── svnsync # Subversion 仓库同步工具;
└── svnversion # 用于报告 版本号 和 工作的svn仓库副本的状态

0 directories, 11 files

Visual SVN Server
常见错误汇总
#1 Cannot start service: 由于登录失败而无法启动服务。 (0x8007042d) VisualSVN Server 服务启动失败,svn Cannot start service: 由于登录失败而无法启动服务。 (0x8007042D)
在「服务」中找到「Visual SVN Server」这个服务,右键「属性」,选择「登录」菜单栏,在此账户选项下,把「密码」改成新的密码,然后应用即可
参考文献
Apache Subversion Community Guide (aka “HACKING”) Version Control with Subversion[……]

READ MORE

「repo」

repo,建立在Git之上的仓库管理工具,用于获取Android源码的工具。
Repo是Android开发人员在Git之上构建的仓库管理工具。 Repo在必要时统一了多个Git仓库,上传到Android版本控制系统,并自动部署了Android开发工作流程。 Repo并不意味着取代Git,只是为了使Android在Android环境中更容易使用Git。
repo命令是一个可执行的Python脚本,您可以将其放在路径的任何位置。在使用Android源文件时,您将使用Repo进行跨网络操作。例如,使用单个Repo命令,您可以将文件从多个存储库下载到本地工作目录。
repo是一个不寻常的工具,因为它使用GPG签名的git标签下载所有自己的Python模块,并将这些文件作为项目的一部分进行存储。所以这个包只提供了包装器脚本,它提供了GPG签名密钥,用于验证是否下载了正确的Python代码。
repo version 1.12.32-2
命令行语法格式
repo [ command ] [ options ]
命令支持的选项及含义
以下是可以识别的命令列表:
abandon,永久的放弃一个开发分支。 branch,查看当前主题分支。 branches,查看当前主题分支。 checkout,检出一个用于开发的分支。 cherry-pick,Cherry-pick a change. diff,显示提交于工作树之间的更改。 diffmanifests,对比manifest程序。 download,下载并检出更改。 forall,在每个项目目录中运行shell命令。 gitc-delete,删除一个GITC Client。 gitc-init,初始化一个GITC Client。 grep,显示匹配的行。 info,获取manifest分支、当前分支、未合并分支的信息。 init,在当前目录下初始化repo。 list,列出项目及其相关目录。 manifest,检查Manifest。 overview,显示为合并分支的概览。 prune,删除已经合并的topic。 rebase,在上游分支上rebase本地分支。 selfupdate,更新repo到最后一个版本。 smartsync,更新工作树到最后一个已知的好的版本。 stage,暂存文件,用于提交。 start,创建一个用于开发的新分支。 status,显示工作树的状态。 sync,将工作树更新到最新版本。 upload,上传更改,用于代码审查。 version,显示repo的版本 help,repo help [ command ]显示命令的详细帮助信息。
参考文献
Homepage: https://source.android.com/sou[……]

READ MORE

「CI/CD」- 持续集成,Continuous Integration

[……]

READ MORE

「GitHub Actions」- 持续集成服务(学习笔记)

问题描述
GitHub Actions 是 GitHub 的持续集成服务,类似与 Jenkins、Travis CI、GOCD 等等工具,都是为了完成自动化任务。于 2018 年 10 月推出,正式版于 2019 年 11 月正式推出。
最近(04/09/2021)还火了一把:黑客用 GitHub Action 服务器挖矿,三天跑了 3 万个任务,代码惊现中文……啊哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
该笔记将记录:如何使用 GitHub Actions 服务来构建自己的应用,以及常见问题处理。
解决方案
快速入门
1)在项目目录中,创建 .github/workflows/example.yml 文件。
2)并将如下内容写入 example.yaml 文件(如下为官方示例,同时我们也进行简单补充):

name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on: ubuntu-latest
steps:
# 拉取代码(GitHub Action 不会自动拉取仓库代码,因此基本每个 Workflow 中都有该 Action)
– uses: actions/checkout@v2
# 安装 NodeJS 环境(其他 Action 可以参考 Actions Marketplace 页面)
– uses: actions/setup-node@v1
– run: npm install -g bats
– run: bats -v

3)最后提交代码,然后就能够在仓库主页的 Actions 中看到 CI 的执行过程。
解释说明
1)runs-on: ubuntu-latest,表示使用 GitHub 提供的 ubuntu-latest 主机。目前(02/02/2021)指向 18.04 TLS 版本,预装 Docker-Moby 19.03.14、Pip3 9.0.1、Docker Compose 1.27.4、jq 1.5 等等很多应用。在安装必要应用前,建议阅读官方文档(参考 virtual-environments/Ubuntu1804-README.md at main 文档),因为多数常见应用已预装,无需我们再次安装。
2)指令 run 与 uses 不能出现在同个字典中,否则提示 a step cannot have both the `uses` and `run` keys 错误。

# 这是错误的写法
– uses: actions/checkout@v2
run:[……]

READ MORE

「GitLab CI/CD」- 持续方法

[……]

READ MORE

「GitLab CI/CI」- 概念及架构(学习笔记)

GitLab CI/CD
GitLab CI/CD is a tool built into GitLab for software development through the continuous methodologies: Continuous Integration (CI) Continuous Delivery (CD) Continuous Deployment (CD)
GitLab Runner
GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline.
Executors
GitLab Runner implements a number of executors that can be used to run your builds in different scenarios.
Registering runners
Registering a runner is the process that binds the runner with a GitLab instance.
操作流程概述
如何使用 GitLab CI/CD 进行 CI/CD 操作(这里只复述大致流程)?
1)前期设置(需要管理权限):

在某主机中,运行 gitlab-runner 进程
执行 gitlab-runner register 以向 gitlab 注册 executor 实例(可以注册各种 executor 类型)
2)开发使用:

在项目仓库中,定义 .gitlab.yml 文件
当提交后,将触发作业,开始执行流水线;

如下是对上述流程的补充说明,用于辅助我们理解 GitLab CI/CD 是什么: 1)对于 .gitlab.yml 文件,其内容多是 Shell 脚本,以及定义脚本的执行流程和执行条件等等; 2)可以向 gitlab 注册多个 executor 实例:SSH Executor 将在远程主机中执行命令;Docker Executor 将在容器中执行命令; 3)术语 gitlab-runner 与 executor 经常会被混淆;
参考文献
Executors | GitLab GitLab Runner | GitLab Registering runners | GitLab[……]

READ MORE

「GitLab CI/CD」- Kubernetes Agent Server

解决方案
第一步、GitLab agent server

vim /etc/gitlab/gitlab.rb
… gitlab_kas[‘enable’] = true

gitlab-ctl reconfigure

第二步、修改 Nginx 配置


location /-/kubernetes-agent/ {
proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection “upgrade”;

proxy_pass http://127.0.0.1:8929;
}

否则,agentk 将产生 expected handshake response status code 101 but got 426 错误信息;
使用方法
在特定的项目中: 1)Infrastructure / Connect a cluter 2)填写名字,来新建 Agent 实例; 3)将输出的部署命令,在集群中运行,并确保 Agent 能够正常连接; 4)在项目中,使用:Using GitLab CI/CD with a Kubernetes cluster
参考文献
build/deployment/gitlab-agent gitlab.rb.template Kubernetes agent fails to connect to GitLab with “expected handshake response status code 101 but got 426″[……]

READ MORE

「GitLab CI/CD」- 常见问题处理

docker+machine, kubernetes, parallels, shell, ssh, virtualbox, docker-ssh+machine, custom, docker, docker-ssh
Starting with GitLab Runner 10.0, both Docker-SSH and Docker-SSH+machine executors are deprecated and will be removed in one of the upcoming releases.
配置重载
GitLab Runner commands | GitLab
对于 Docker 容器:

docker container kill –signal SIGHUP “<container name>”

Auto DevOps vs. GitOps Workflow vs. GitLab CI/CD
WIP[……]

READ MORE

「GitLab CI/CD」- 编写 .gitlab-ci.yaml 文件(学习笔记)

示例 .gitlab-ci.yaml 文件
如下内容,为示例 .gitlab-ci.yaml 文件,记录我们的常用指令及含义:

variables:
PROJECT_FOLDER: /data/${CI_PROJECT_NAMESPACE}_${CI_PROJECT_NAME}

stages:
– build
– test
– deploy

default:
before_script:
– # run some shell cmds

####### 项目构建 #######

build:
stage: build
tags:
– “<tag of gitlab runner>”
before_script:
– docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
script:
– mvn $MAVEN_CLI_OPTS compile
– docker-compose build
– docker-compose push

####### 项目测试 #######

unit_tests:
stage: test
tags:
– “<tag of gitlab runner>”
script:
– mvn $MAVEN_CLI_OPTS test

integration_tests:
stage: test
tags:
– “<tag of gitlab runner>”
script:
– mvn $MAVEN_CLI_OPTS test

####### 代码分析 #######

# https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html
code_quality:
stage: test
except:
– master
tags:
– “<tag of gitlab runner>”

####### 应用部署 #######

deploy_to_staging:
stage: deploy
only:
– develop
tags:
– “<tag of gitlab runner>”
before_script:
– mkdir -pv ${PROJECT_FOLDER} && rsync -av ./ ${PROJECT_FOLDER}/ &amp[……]

READ MORE

「GitLab CI/CD」- 使用远程主机的 Docker 服务进行构建(Docker Executor on Remote Host)

问题描述
在 GitLab CI/CD 中,可以使用 Docker Container 作为构建环境,即:可以直接使用 Maven NodeJS Rust 等等镜像,然后在 Docker Container 中运行构建命令,这样可以无需在主机中安装各种环境,避免依赖冲突、版本冲突等等问题。
但是,我们不希望在所有的主机中都运行 GitLab Runner,那么 GitLab Runner 是否可以向 docker 命令那样连接远程的 Docker 服务呢?
该笔记将记录:在 GitLab CI/CD 中,如何让 GitLab Runner 使用远程主机的 Docker 服务,来执行构建命令。
解决方案
WIP
参考文献
The Custom executor | GitLab Install and register GitLab Runner for autoscaling with Docker Machine | GitLab The Docker executor | GitLab[……]

READ MORE

「GitLab CI/CD」- 环境变量(常见问题整理)

在 .gitlab-ci.yml 中,针对环境,使用不同的变量
GitLab CI/CD environment variables | GitLab Environments and deployments | GitLab
问题描述
在 .gitlab-ci.yml 中,我们需要针对不同环境,使用不同的变量值。
解决方案
注意:我们这里的示例采用“先使用,后定义”的流程,这样比较容易理解。
第一步、在 YAML 中,使用环境变量: 1)使用 environment.name.staging 指定环境; 2)在脚本中,使用我们定义的 ${FOO} 环境变量(在第二步中定义):

stages:
– deploy
deploy_staging:
stage: deploy
environment:
name: staging
script:
– echo ${FOO}

第二步、在 GitLab 中,定义 FOO 变量: 1)在项目中 => Settings / CI/CD / Variables => 定义变量 2)当定义变量时,在 Scope 中,设置不同的值(通配符),以匹配 environment.name.staging 字段 3)执行 Job 即可,然后观察 echo ${FOO} 输出;
定义全局环境变量(Instance-level environment variables)
GitLab CI/CD environment variables / Instance-level CI/CD environment variables | GitLab
问题描述
我们定义“全局环境变量”,以在各个项目中使用(而不是仅仅定义项目级环境变量或者组级别环境变量)。
解决方案
首先,保证 GitLab >= 13.1 版本。 然后,在 Admin Area’s Settings / CI/CD / Variables 中,点击 Add variable 设置;
参考文献
GitLab CI/CD environment variables | GitLab[……]

READ MORE

「GitLab CI/CD」- 在远程主机中执行命令

问题描述
我们使用 GitLab CI/CD 实践自动化,有时我们需要在远程主机执行部署命令。
该笔记将记录:在 GitLab CI/CD 中,如何在远程主机中执行命令。
解决方案
使用 GitLab Runner / SSH Executor 功能。
第一步、注册 SSH Execurtor 执行器

# gitlab-runner register
Runtime platform arch=amd64 os=linux pid=42 revision=ac8e767a version=12.6.0
Running in system-mode.

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.exmaple.com —————————————————— <输入 GitLab 地址>
Please enter the gitlab-ci token for this runner:
xxxxxxxxxx ——————————————————————— <在 Admin Area / Overview Runners 中查看>
Please enter the gitlab-ci description for this runner:
[eec8077625c3]: ssh executor ————————————————— <添加描述信息>
Please enter the gitlab-ci tags for this runner (comma separated):
staging-host ——————————————————————- <添加 Tag 信息,我们通常设置为主机名>
Registering runner… succeeded runner=zxTzZ7Ec
Please enter the executor: virtualbox, docker+machine, kubernetes, docker, parallels, shell, docker-ssh+machine, custom[……]

READ MORE

「GitLab CI/CD」- 常见错误汇总

Runner-related
… prepare environment: Process exited with status 1 …
问题描述:


ERROR: Job failed: prepare environment: Process exited with status 1. Check http
s://docs.gitlab.com/runner/shells/index.html#shell-profile-loading for more info
rmation

环境信息: GitLab Runner 15.2.2, SSH Executor
原因分析: https://docs.gitlab.com/runner/shells/index.html#shell-profile-loading
解决方案: rm -rf $HOME/.bash_logout
… /root/.ssh/known_hosts: no such file or directory …
Types of shells supported by GitLab Runner | GitLab “ssh: handshake failed: knownhosts: key is unknown” error for VirtualBox executor SSH | GitLab
问题描述:

Using SSH executor…
ERROR: Preparation failed: ssh command Connect() error: getting host key callback: open /root/.ssh/known_hosts: no such file or directory
Will be retried in 3s …

环境信息: GitLab Runner 15.2.2, SSH Executor
原因分析:Introduced in GitLab 14.3. To enable SSH StrictHostKeyChecking, make sure the [runners.ssh.disable_strict_host_key_checking] is set to false. The current default is true. In GitLab 15.0 and later, the default value is false, meaning host key checking is required.
解决方案:

[[runners]]
..[……]

READ MORE

「Jenkins」- 在 Tomcat 中,运行 Jenkins 服务

问题描述
该笔记将记录:在 Tomcat 中,运行 Jenkins 服务,而不是运行独立的 Jenkins 服务。
解决方案
补充说明: 1)该笔记属于实验进行,在实际的生产中,我们并未在 Tomcat 中部署 Jenkins 服务;
第一步、安装 Tomcat 服务
我们直接从发行办的仓库中安装:

# 安装服务(Kali)
apt-get install tomcat9

# 启动服务,并开机启动
systemctl enable tomcat9

发行版不同,安装方法不同,细节不再赘述。
第二步、安装 Jenkins 服务

wget -P /var/lib/tomcat9/webapps/ http://mirrors.jenkins.io/war-stable/latest/jenkins.war

然后最自动生成 jenkins 目录。
第三步、修改配置文件
为什么需要进行该步骤? 1)进行该步骤配置是因为发行版自带的 Tomcat 进行安全配置,执行命令 systemctl cat tomcat9.service 了解配置。 2)阅读 systemd.exec(5) 手册,了解 PrivateTmp= ReadWritePaths= 参数。
设置 JENKINS_HOME 变量
修改 /etc/tomcat9/context.xml 配置:

<Context>

<Environment name=”JENKINS_HOME” value=”/var/lib/jenkins/” type=”java.lang.String”/>

</Context>

创建 JENKINS_HOME 目录

mkdir -pv /var/lib/jenkins/
chown -R tomcat: /var/lib/jenkins/

调整 tomcat9.service 配置

# systemctl edit tomcat9.service
[Service]
ReadWritePaths=/var/lib/jenkins/

第四步、启动 Tomcat 服务

systemcat start tomcat9

最后启动浏览器访问,http://<ip address>/jenkins/,按照提示进行初始化即可。
参考文献
Jenkins/Installing Jenkins How to Install Jenkins on the Apache Tomcat Server How to[……]

READ MORE

「Jenkins」- 通过 Nginx 反向代理 Jenkins 服务

配置文件
参考 Running Jenkins behind Nginx 文档,以获取官方对反向代理的详细说明;
下面是配置文件(直接复制自官方,我们并未深入研究):

upstream jenkins {
keepalive 32; # keepalive connections
server 127.0.0.1:8080; # jenkins ip and port
}

server {
listen 80; # Listen on port 80 for IPv4 requests

server_name jenkins.example.com;

#this is the jenkins web root directory (mentioned in the /etc/default/jenkins file)
root /var/run/jenkins/war/;

access_log /var/log/nginx/jenkins/access.log;
error_log /var/log/nginx/jenkins/error.log;
ignore_invalid_headers off; #pass through headers from Jenkins which are considered invalid by Nginx server.

location ~ “^/static/[0-9a-fA-F]{8}\/(.*)$” {
#rewrite all static files into requests to the root
#E.g /static/12345678/css/something.css will become /css/something.css
rewrite “^/static/[0-9a-fA-F]{8}\/(.*)” /$1 last;
}

location /userContent {
#have nginx handle all the static requests to the userContent folder files
#note : This is the $JENKINS_HOME dir
root /var/lib/jenkins/;
if (!-f $request_filename){
#this file does not exist, might be a directory or a /**view** url
rewrite (.[……]

READ MORE

「Jenkins」- 部署到 Kubernetes 环境 、迁移到 Kubernetes 环境

问题描述
该笔记将记录:在 Kubernetes Cluster 中,如何部署 Jenkins 服务,重点将现有 Jenkins 服务迁移到 Kubernetes 中;
解决方案
补充说明: 1)鉴于迁移是我们的重点工作,所以部署过程会涉及迁移相关的内容;
服务部署

# 添加仓库
helm repo add jenkinsci https://charts.jenkins.io
helm repo update
helm search repo jenkinsci

# 下载
# 我们 Jenkins 2.345 版本,但是没有该版本的 Chart 资源,
# 而 4.1.12 对应 Jenkins 2.346.1 版本,最贴近(算是微小升级);
helm pull jenkinsci/jenkins –version 4.1.12 # jenkins-4.1.12.tgz

# 修改配置
helm show values ./jenkins-4.1.12.tgz > jenkins-4.1.12.helm-values.yaml
…(1)修改 storageClass 参数,以配置其使用的存储类;
…(2)修改 Ingress 参数,以保留服务提供 HTTP 访问;

# 服务部署
helm –namespace jenkins \
install jenkins ./jenkins-4.1.12.tgz -f jenkins-4.1.12.helm-values.yaml \
–create-namespace

# 查看密码
kubectl exec –namespace jenkins -it svc/jenkins -c jenkins — /bin/cat /run/secrets/additional/chart-admin-password && echo

# 服务登录
# admin:<password>

服务迁移
问题描述
在 Kubernetes 大为流行前,我们已经开始使用 Jenkins 服务,现在我们需要将 Jenkins 迁移到 Kubernetes 环境,而非重新部署 Jenkins 服务;
解决方案
目前(07/10/2022),我们的想法是: 1)首先,运行 rsync 容器,并创建 PV 与 PVC 资源,负责将数据复制到 PV 内; 2)在启动 Jenkins 服务,并在其中引用该 PVC 资源,并检查[……]

READ MORE

「Jenkins」- 服务管理

重启 Jenkins 服务
How to restart Jenkins manually? – Stack Overflow
(jenkins_url)/safeRestart (jenkins_url)/restart[……]

READ MORE

「Jenkins」- 使用 Kubernetes Cluster 作为构建节点

解决方案
通过 Kubernetes 插件,我们能够在 Kubernetes Pod 中运行构建任务;
配置步骤
我们不再展开细节,大致分为两步:
1)添加 Kubernetes 节点:Manage Jenkins ⇒ Manage Nodes and Clouds ⇒ Configure Clouds Jenkins URL:填写 Jenkins Server 地址; Container Cleanup Timeout:控制 Container 清理。默认在任务结束时将自动清理;
2)通过 Pipeline 使用:通过 PodTemplate 调用即可

podTemplate(
cloud: “cluster name”,
containers: [
containerTemplate(name: ‘maven’, image: ‘maven:3.8.1-jdk-8’, command: ‘sleep’, args: ’99d’),
containerTemplate(name: ‘golang’, image: ‘golang:1.16.5’, command: ‘sleep’, args: ’99d’)
]) {

node(POD_LABEL) {
stage(‘Get a Maven project’) {
git ‘https://github.com/jenkinsci/kubernetes-plugin.git’
container(‘maven’) {
stage(‘Build a Maven project’) {
sh ‘mvn -B -ntp clean install’
}
}
}

stage(‘Get a Golang project’) {
git url: ‘https://github.com/hashicorp/terraform.git’, branch: ‘main’
container(‘golang’) {
stage(‘Build a Go project’) {
sh ”’
mkdir -p /go/src/github.com/hashicorp
ln -s `pwd` /go/src/github.com[……]

READ MORE