Tag: gitlab
-
如何设置git使用自己的私钥
以连接github.com为例，新建配置文件： ~/.ssh/config 内容如下： host github.com HostName github.com IdentityFile ~/.ssh/id_rsa_github User git 文件权限设置： chmod 600 ~/.ssh/config 现在可以用git命令进行clone了，如下： git clone git@github.com:{ORG_NAME}/{REPO_NAME}.git 以上，{ORG_NAME} 是账号名称，{REPO_NAME}是项目名称。 特别注意，在Linux 或者 macOS 下，最好做如下操作： chmod 400 ~/.ssh/id_rsa_github 如果git版本是 2.3.0，可以使用环境变量 GIT_SSH_COMMAND GIT_SSH_COMMAND=”ssh -i ~/.ssh/id_rsa_example” git clone example 如果git版本是2.10.0 ,就需要配置 core.sshCommand，命令如下： git config core.sshCommand “ssh -i ~/.ssh/id_rsa_example -F /dev/null” git pull git push 没有绝对完美的方法告诉git去使用哪个私钥文件，因为它依赖ssh的认证，所以可以用ssh的方法来临时进行私钥的认证，比如： $ ssh-agent…
-
gitlab forbidden 解决办法(gitlab的rack::attack机制)
版本：GitLab Community Edition 10.8.7 现象：小部分用户web访问gitlab显示403 forbidden。 原因：gitlab有rack::attack模块，来防治恶意ip刷机，其详细文档：https://docs.gitlab.com/ee/security/rack_attack.html 确定是否是这个原因： 1、查日志 # cd /var/log/gitlab/gitlab-rails/ # grep ‘Rack_Attack’ production.log|more Rack_Attack: blacklist 192.130.160.212 GET /xxx Rack_Attack: blacklist 192.130.160.212 GET /xxxxxx Rack_Attack: blacklist 192.130.160.212 GET /xxxxxxxx 确认这个ip是否是访问者的ip 2、进入redis： # /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket redis /var/opt/gitlab/redis/redis.socket> keys *rack::attack* 1) “cache:gitlab:rack::attack:26176509:allow2ban:count:192.130.160.212” 2) “cache:gitlab:rack::attack:allow2ban:ban:192.130.160.212” 通过两步即可确认，就是这个原因。在redis里清除该条即可： del cache:gitlab:rack::attack:allow2ban:ban:192.130.160.212 总结：从11版本开始，官方默认不开启这个功能： Note: Starting with GitLab 11.2, Rack…
-
Gitlab用户在组中有五种权限：Guest、Reporter、Developer、Master、Owner区别
Gitlab权限管理Gitlab用户在组中有五种权限：Guest、Reporter、Developer、Master、Owner Guest：可以创建issue、发表评论，不能读写版本库Reporter：可以克隆代码，不能提交，QA、PM可以赋予这个权限Developer：可以克隆代码、开发、提交、push，RD可以赋予这个权限Master：可以创建项目、添加tag、保护分支、添加项目成员、编辑项目，核心RD负责人可以赋予这个权限Owner：可以设置项目访问权限 – Visibility Level、删除项目、迁移项目、管理组成员，开发组leader可以赋予这个权限Gitlab中的组和项目有三种访问权限：Private、Internal、Public Private：只有组成员才能看到Internal：只要登录的用户就能看到Public：所有人都能看到开源项目和组设置的是Internal 后期，不知道从什么时候开始，改为：Guest Reporter Developer Maintainer Owner 是的，你没看错 ，Master 改为了 Maintainer
-
gitlab-ci 和 jenkins 的区别
转自：https://blog.csdn.net/xinluke/article/details/53982150 Jenkins Jenkins作为老牌的持续集成框架，在这么多年的发展中，积累很多优秀的plugin工具，对进行持续集成工作带来很大的便利。 gitlab-ci gitlab-ci作为gitlab提供的一个持续集成的套件，完美和gitlab进行集成，gitlab-ci已经集成进gitlab服务器中，在使用的时候只需要安装配置gitlab-runner即可。 gitlab-runner基本上提供了一个可以进行编译的环境，负责从gitlab中拉取代码，根据工程中配置的gitlab-ci.yml，执行相应的命令进行编译。 jenkins VS gitlab-runner gitlab-runner配置简单，很容易与gitlab集成。当新建一个项目的时候，不需要配置webhook回调地址，也不需要同时在jenkins新建这个项目的编译配置，只需在工程中配置gitlab-ci.yml文件，就可以让这个工程可以进行编译。 gitlab-runner没有web页面，但编译的过程直接就在gitlab中可以看到，不需要像jenkins进入web控制台查看编译过程。 gitlab-runner仅仅是提供了一个编译的环境而已，全部的编译都通过shell脚本命令进行。当然，jenkins也可以是全部的编译都通过shell脚本命令进行。 jenkins的好处就是编译服务和代码仓库分离，而且编译配置文件不需要在工程中配置，如果团队有开发、测试、配置管理员、运维、实施等完整的人员配置，那就采用jenkins，这样职责分明。不仅仅如此，jenkins依靠它丰富的插件，可以配置很多gitlab-ci不存在的功能，比如说看编译状况统计等。如果团队是互联网类型，讲究的是敏捷开发，那么开发=devOps，肯定是采用最便捷的开发方式，推荐gitlab-ci。 如果有些敏感的配置文件不方便存放在工程中（例如nexus上传jar的账户和密码或者是其他配置的账户密码）,都可以在服务器中配置即可。 gitlab-ci对于编译需要的环境，比如jdk，maven都需要自行配置。在jenkins中，对于编译需要的环境，比如jdk，maven都可以在Web控制台安装即可。当然，jenkins也是可以自行配置的（有时候通过控制台配置下载不下来）。 – 总结 在使用过两者后，个人觉得gitlab-ci更简单易用，如果有gitlab-ci达不到的要求，可以考虑使用jenkins。