1.git的码包安装
2.Gitea源码分析（一）
3.GitLab ARM64源码在信创统信UOS下的搭建
4.jenkins+gitlab持续集成环境配置100%可用
git的安装
在CentOS系统上，安装Git有两种常见方法：yum自动安装和源码编译安装。码包尽管yum安装方便快捷，码包但版本控制有限，码包因此，码包本文将重点介绍源码编译安装Git（以2..0版本为例）的码包全景显示源码详细步骤。
首先，码包通过wget下载Git源码包：wget kernel.org/pub/software...
接着，码包解压下载的码包文件：tar -xzvf git-2..0.tar.gz
为了顺利编译，确保安装必要的码包依赖，运行以下命令安装gcc、码包openssl等：yum -y install gcc openssl openssl-devel curl curl-devel unzip perl perl-devel expat expat-devel zlib zlib-devel asciidoc xmlto gettext-devel openssh-clients libiconv autotools 有时可能需要移除yum已安装的码包Git，使用 yum remove git 。码包
接下来，码包进入解压后的码包Git目录，执行编译安装：cd git-2..0 && make prefix=/usr/local/git install
安装完成后，添加环境变量至系统配置文件中：vim /etc/profile，并在文件末尾添加 export PATH=$PATH:/usr/local/git/bin，然后执行source /etc/profile使更改生效，无需重启系统。
最后，检查安装是否成功，只需运行 git --version，如果显示出Git的qt charts 源码版本号，说明安装已完成。
Gitea源码分析（一）
Gitea是一个基于Go编写的Git代码托管工具，源自于gogs项目，具有良好的后端框架和前端集成。
前端框架采用Fomantic UI和Vue，路由控制器框架在年4月从macaron切换到chi，形成了gitea项目的结构基础。
在调用接口时，gitea引入了'User'，'Repo'，'Org'等内容，简化了接口调用，便于管理。'ctx.User'和'ctx.Repo'内容动态变化，需要用户登录和进入仓库时赋值。
在'routers'下，'handler'相关文件分为'get'和'post'两类，前者涉及前端渲染，后者负责执行操作。
'get'请求通过'templates'中的文件渲染到前端，通过'ctx.Data["name"]'传递需要渲染的数据，获取URL参数使用'c.Query'。
'post'请求接收前端数据，aapt工具源码通常通过'form'传值，从'context'生成，可以使用'form.xxx'直接调用，添加内容则需在'form'结构体中定义。
渲染生成网页使用'ctx.Html(,tplName)'，根据'context'内容做条件判断。
权限管理功能实现中，数字越大权限越高，便于后续对比。'UnitType'包含多项，如仓库页面导航栏显示。检查权限时，对比AccessModeRead和模块权限，大于则认为具有读权限。
gitea默认运行于单一服务器，伸缩性有限。若需分布式改造，需解决大规模并发访问、存储库分片和数据库支撑等问题。通过ELB负载均衡分散到多个节点，数据库使用集群方案，但存储库分片面临巨大挑战，现有技术难以实现。潘多拉源码
官方文档提供了其他开源库的介绍，包括配置文件、容器方式下的轻量仓库与CI使用方案等。深入研究可发现Gitea的配置、路由控制框架chi、权限管理实现及分布式架构改造思路。
GitLab ARM源码在信创统信UOS下的搭建
GitLab是一个基于Ruby on Rails语言开发的开源应用，提供私有化的Git项目仓库，可通过Web界面进行访问和管理。GitLab官方提供了多种安装方式，包括通过操作系统软件源安装、Docker容器部署以及源代码自编译安装。然而，GitLab官方构建的软件包和镜像主要针对X架构，并未提供针对ARMv8的版本。UOS操作系统支持多种CPU架构（AMD、ARM、MIPS、SW）和六种国产CPU平台（鲲鹏、龙芯、申威、海光、兆芯、leaflet源码分析飞腾）以及Intel/AMD的主流CPU，UOSV基于Debian stable，内核为4.，支持多种架构。由于GitLab官方Omnibus安装包并未支持arm架构，因此需要通过源码编译来安装GitLab-ce .1-stable在UOSV arm架构上。
在部署GitLab-ce .1-stable之前，首先需要搭建编译环境，包括Ruby 2.7.4、redis 6.2.4、git 2..0、Go:.、Postgres: 、Node: .x、Nginx:1..1。编译过程较为平顺，但安装Ruby、Node和Go时需要注意选择国内镜像源以确保顺利编译。GitLab-ce:-1-stable版本要求Git2..x或以上版本，推荐使用Gitaly提供的git版本。UOSV 版本若选择调试工具包，则系统自带的git版本不符合要求，需要手动安装Gitaly所提供的git版本，确保版本满足GitLab要求。安装完成后，系统会显示版本为2..0，满足要求。此外，还需安装GraphicsMagick支持GitLab引入的自定义图标功能，以及安装Postfix邮件服务器和exiftool以支持GitLab Workhorse功能。Ruby的安装也非常重要，更换国内Ruby Gem源能够提高编译过程的稳定性。
在完成编译环境搭建后，需为GitLab创建一个名为git的用户。GitLab .1及以后版本仅支持PostgreSQL数据库，GitLab-ce .1-stable需要PostgreSQL 或以上版本，并且需要pg_trgm扩展和btree_gist扩展。GitLab .0及以后版本要求Redis版本4.0或以上，推荐使用6.0或以上版本。部署GitLab-ce .1-stable需要编译三个部分：gitLab核心代码、gitlab-shell和GitLab-Workhorse。编译完成后，主要目录结构会根据部署环境进行相应调整。
配置GitLab的各个组件时，需要将源码配置调整为已搭建环境的配置。主要修改数据库配置为已安装的PostgreSQL 版本。安装过程中可能会遇到一些小问题，如使用sudo执行某些命令时的超时错误。解决这类问题通常需要检查和调整环境变量，确保git账号的环境变量能够正常工作。例如，通过修改/etc/sudoers文件，确保在执行sudo命令时保留所需的环境变量，如GOPROXY。安装完成后，GitLab及其环境应已正确配置，系统架构识别为arm，GitLab版本为.1，redis版本未读取但不影响使用。至此，GitLab在UOSV arm架构上成功部署完毕。
jenkins+gitlab持续集成环境配置%可用
本文详细介绍了如何配置 Jenkins 和 GitLab 持续集成环境，实现 % 可用性的步骤与注意事项。首先，需确保安装了合适的 JDK 版本，因为 Jenkins 2.3.4 以上版本不再支持 JDK8，最低要求 JDK 或更高版本，建议使用稳定版本。接下来，我们按照以下步骤进行 Jenkins 和 GitLab 的安装与配置。
在安装 Jenkins 时，可以选择从官网下载适合的版本或利用 Docker 方式安装，启动命令为 java -jar xxx.war，默认端口为 ，确保环境具备 JDK。若遇到启动问题或缺少组件，可进行下载安装。此外，对于 Jenkins 的升级，需要特别注意 JDK 以上版本可能需要指定组件。
接下里，对 GitLab 的安装进行介绍。这里以 Docker 安装为例，步骤包括拉取 Git 镜像、创建 Docker 容器、配置 GitLab 服务器的访问地址、修改相关配置（如设置外部 URL、nginx 的重定向端口、SSH 端口）以及重启 Docker 容器。在完成这些步骤后，通过浏览器访问配置好的 GitLab 服务器，使用管理员账户 root 登录并重设密码，确保安装无误。
安装 Git 可以通过两种方式完成，一是下载最新版本的 Git 源码包进行解压、配置、安装，指定安装路径为 /usr/local；二是通过 Docker 安装。安装完成后，记得配置环境变量，通过执行 git --version 命令确认 Git 版本。
在完成 Jenkins 和 GitLab 的安装后，下一步是集成配置。首先需要在 GitLab 系统中配置钩子，将 GitLab 与 Jenkins 进行连接。然后在 GitLab 中配置 Git 地址，建议使用 Git 账号密码进行操作，简化免密配置。在 Jenkins 端进行触发器配置，包括指定 Jenkins 的 job 项目路径和生成的令牌。配置完成后，需要关注权限问题，确保系统钩子只针对全局任务设置，避免误触发所有任务，影响工作效率。
测试环节非常重要，通过在 GitLab 上点击测试功能，可验证 Jenkins 和 GitLab 之间的通信是否顺畅。在测试过程中，可能会遇到不同的状态码，如 （配置文件 token 错误）、（Jenkins 权限问题）、（job 路径问题）、（正常响应），以及确保在 URL 后添加 /build/ 以正确触发 Jenkins 构建。确保 Jenkins 和 GitLab 服务器间可以顺利通信，为持续集成环境的稳定运行打下坚实基础。