gitlab

起因 业务服务器安全加固不再允许使用个人私有key配置再服务器，为了配置调试方便使用https方式拉取代码，但是发现每次Git pull 、push 都要输入用户和密码，很不方便，特整理此配置。 永久记住密码 会在用户家目录的.gitconfig文件中生成下面的配置。如果没有--global，则在当前项目下的.git/config文件中添加。 git config --global credential.helper store 临时记住密码 默认记住15分钟： git config –global credential.helper cache 下面是自定义配置记住1小时： git config credential.helper ‘cache –timeout=3600’ 进行第一次拉取 cd /workspace/kdeploy git pull 按照提示输入信息： [root@kdeploy]# git pull #输入git用户 Username for 'https://gitlab.com': kevin@pxxxx.com #输入git密码 Password for 'https://kevin@xxxxcom@gitlab.com': 成功首次代码拉取之后，在设置的缓存的时间周期内将不会再要求输入密码！ 来源： 51CTO 作者： 无锋剑 链接： https:/

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> docker 启动脚本添加--privileged=true特权模式 运行脚本之后通过 docker ps 查看当前正在运行的容里面并没有看到 gitlab这个容器，通过 ps -a显示所有容器时发现它的状态一直是 starting 或者 restarting。 这个时候我们可以使用 docker logs 来查看当前容器的运行日志。 Preparing services... Starting services... /opt/gitlab/embedded/bin/runsvdir-start: line 24: ulimit: pending signals: cannot modify limit: Operation not permitted /opt/gitlab/embedded/bin/runsvdir-start: line 37: /proc/sys/fs/file-max: Read-only file system Configuring GitLab package... Configuring GitLab... =============================================================================Error

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 您的位置: Linux系统教程 > Ubuntu系统 > ubuntu15.04上安装gitlab遇到的问题以及解决办法 时间: 2015-06-03 来源: my.oschina.net/u/569039 作者: 这里有一只羊 1.安装脚本执行进入假死状态。 在gitlab官网下载的自动安装脚本执行后进入了假死状态。中断运行后我查看了脚步的内容，发现只是获取系统发行版合成一个 软件源地址添加到apt里。经验告诉我这种外国web地址在我大中华都不怎么好使。于是去查看了apt里添加的软件源地址。 用浏览器打开那个地址直接找不到。然后向上层后退到可以查看的地方，发现gitlab的官方软件源只支持到了ubuntu1404.而自动安装脚本合成的地址是1504的代号所以脚本一直是处于连接超时重试的状态。 问题找到，手动改apt软件源地址里的代号到1404的。update成功。但是apt下载gitlab-ce仍旧速度很慢。于是再次打开刚刚查看的页面，拷贝下载地址放到uget里面下载。分分钟下载好的deb包安装完成。 uGet安装: sudo apt-get install uGet 安装完后，命令行无法启动，到菜单中可以。然后到设置中启用aria2插件。 在gitlab.com的官网下载链接https://packages

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 开源中国代码托管平台 git.oschina.net 就是基于 GitLab 项目搭建。 GitLab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过Web界面进行访问公开的或者私人项目。 它拥有与 Github 类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。 GitLab 5.0以前版本要求服务器端采用 Gitolite 搭建，5.0版本以后不再使用 Gitolite ，采用自己开发的 gitlab-shell 来实现。如果你觉得安装麻烦可以使用 GitLab Installers 一键安装程序。 系统要求： Ubuntu/Debian ruby 1.9.3+ mysql or postgresql git gitlab-shell redis Sidekiq Gitlab 的集群解决方案 gitlabhq / gitlabhq Watch 948 Star 16900 Fork 4584 GitLab is version control for your server — More... https:/

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 参考网址： https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#installation 安装gitlab版：6.9.2 rpm发行文件名： gitlab-6.9.2_omnibus.1-1.el6.x86_64.rpm 安装步骤代码： #sudo yum install openssh-server #sudo yum install postfix # sendmail or exim is also OK #sudo rpm -i gitlab-6.9.2_omnibus.1-1.el6.x86_64.rpm # this is the .rpm you downloaded #sudo gitlab-ctl reconfigure #sudo lokkit -s http -s ssh # open up the firewall for HTTP and SSH requests ok! #sudo gitlab-ctl status; #查看安装后的程序运行情况！输出如下： run: nginx: (pid 3012) 53s; run: log: (pid 3011) 53s run: postgresql:

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1、下载安装包 wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el6/gitlab-ce-8.7.0-ce.0.el6.x86_64.rpm 下载rpm包时，使用清华的镜像 2、rpm升级 rpm -Uvh gitlab-ce-8.7.0-ce.0.el6.x86_64.rpm 降级 rpm -Uvh --oldpackage -Uvh gitlab-ce-8.6.0-ce.0.el6.x86_64.rpm Omnibus packages的一键升级非常简单，停止gitlab、备份数据库、迁移、然后启动gitlab这些操作都可以自动完成。 不论多大或多小的更新，默认的Omnibus packages都会停止gitlab、迁移、然后启动gitlab。 这个行为通过添加一个文件被改变：/etc/gitlab/skip-auto-migrations 在一些很小的升级时，可以直接迁移，无需停止gitlab服务，就可以通过添加上述文件处理，而在迁移完成后，再删掉上述文件。 来源： oschina 链接： https://my.oschina.net/u/1588291/blog/800807

昨天，Gitlab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级错误，不过，因为Gitlab把整个过程的细节都全部暴露出来了，所以，可以看到很多东西，而对于类似这样的事情，我自己以前也干过，而在最近的两公司中我也见过（Amazon中见过一次，阿里中见过至少四次），正好通过这个事来说说一下自己的一些感想和观点吧。我先放个观点：你觉得有备份系统就不会丢数据了吗？ 事件回顾 整个事件的回顾Gitlab.com在第一时间就放到了 Google Doc上 ，事后，又发了 一篇Blog 来说明这个事，在这里，我简单的回顾一下这个事件的过程。 首先，一个叫YP的同学在给gitlab的线上数据库做一些负载均衡的工作，在做这个工作时的时候突发了一个情况，Gitlab被DDoS攻击，数据库的使用飙高，在block完攻击者的IP后，发现有个staging的数据库(db2.staging)已经落后生产库4GB的数据，于是YP同学在Fix这个staging库的同步问题的时候，发现db2.staging有各种问题都和主库无法同步，在这个时候，YP同学已经工作的很晚了，在尝试过多个方法后，发现db2.staging都hang在那里，无法同步，于是他想把db2.staging的数据库删除了，这样全新启动一个新的复制，结果呢，删除数据库的命令错误的敲在了生产环境上（db1.cluster）