如何部署Gitlab项目分公司目录 [英] How to deploy Gitlab project branch to directory

问题描述

我有一个Gitlab服务器（Ubuntu的14.04），其中我想用它作为既是为我的仓库主人，以及为我的PHP项目测试服务器。理想情况下，我想有Gitlab /混帐出口释放分支 /无功/网络/的git /＆LT;项目名称＆gt; 时，该分支更新

I have a Gitlab server (Ubuntu 14.04) where I am trying use it as both a host for my repositories as well as a testing server for my PHP projects. Ideally, I would like to have Gitlab/Git export the "release" branch to /var/www/git/<project-name> when that branch is updated.

我的提问：如何在Gitlab导出一个特定的分支，以本地主机上的特定目录，当分支更新

My Question: How can I export a specific branch in Gitlab, to a specific directory on the localhost, when the branch is updated?

据我所知，有在Gitlab提供网络挂接，但它似乎没有必要和浪费，使服务器POST到自身的本地操作。

I am aware that there are webhooks available in Gitlab, but it seems unnecessary and wasteful to have the server POST to itself for a local operation.

推荐答案

我想你正在运行gitlab的社区版。

I suppose you are running the community edition of gitlab.

这样，只有服务器管理员可以通过复制所需的脚本到受影响的库配置钩子脚本。

Then, only the server administrator can configure hook scripts by copying the required scripts into the affected repositories.

gitlab本身是使用 $ GIT_DIR /钩目录为自己的脚本了。幸运的是，他们将控制权交给任何钩子脚本在gitlab具体 $ GIT_DIR / custom_hooks 目录。另请参见有关如何与gitlab 同一类型运行多个挂钩这个问题。

gitlab itself is using the $GIT_DIR/hooks directory for its own scripts already. Fortunately they forward control to any hook script in the gitlab specific $GIT_DIR/custom_hooks directory. See also this question about how to run multiple hooks with the same type on gitlab.

脚本本身看起来是这样的：

The script itself could look like this:

#!/bin/bash
#
# Hook script to export current state of repo to a release area
#
# Always hardcode release area - if configured in the repo this might incur data loss
# or security issues

echo "Git hook: $0 running"

. $(dirname $0)/functions

git=git
release_root=/gitlab/release
# The above release directory must be accessible from the gitlab server
# and any client machines that want to access the exports. Please configure.


if [ $(git rev-parse --is-bare-repository) = true ]; then
    group_name=$(basename $(dirname "$PWD"))
    repo_name=$(basename "$PWD")
else
    cd $(git rev-parse --show-toplevel)
    group_name=$(basename $(readlink -nf "$PWD"/../..))
    repo_name=$(basename $(readlink -nf "$PWD"/..))
fi



function do_release {
    ref=$1
    branch=$2

    # Decide on name for release
    release_date=$(git show -s --format=format:%ci $ref -- | cut -d' ' -f1-2 | tr -d -- -: | tr ' ' -)
    if [[ !  "$release_date" =~ [0-9]{8}-[0-9]{6} ]]; then
        echo "Could not determine release date for ref '$ref': '$release_date'"
        exit 1
    fi

    dest_root="$release_root/$group_name/$repo_name"
    dated_dir="dated/$release_date"
    export_dir="$dest_root/$dated_dir"
    # Protect against multiple releases in the same second
    if [[ -e "$export_dir" ]]; then
        export_dir="$export_dir-02"
        dated_dir="$dated_dir-02"
        while [[ -e "$export_dir" ]]; do
            export_dir=$(echo $export_dir | perl -pe 'chomp; print ++$_')
            dated_dir=$(echo $dated_dir | perl -pe 'chomp; print ++$_')
        done
    fi
    # Create release area
    if ! mkdir -pv "$export_dir"; then
        echo 'Failed to create export directory: ' "$export_dir"
        exit 1
    fi
    # Release
    if ! git archive $branch | tar -x -C "$export_dir"; then
        echo 'Failed to export!'
        exit 1
    fi
    chmod a-w -R "$export_dir"      # Not even me should change this dir after release
    echo "Exported $branch to $export_dir"

    ( cd "$dest_root" && rm -f latest && ln -s "$dated_dir" latest )
    echo "Adjusted $dest_root/latest pointer"
}


process_ref() {
    oldrev=$(git rev-parse $1)
    newrev=$(git rev-parse $2)
    refname="$3"

    set_change_type
    set_rev_types
    set_describe_tags

    echo "  Ref: $refname","$rev_type"

    case "$refname","$rev_type" in
        refs/heads/*,commit)
            # branch
            refname_type="branch"
            function="branch"
            short_refname=${refname##refs/heads/}
            if [[ $short_refname == release ]]; then
                echo "    Push accepted. Releasing export for $group_name/$repo_name $short_refname"
                do_release "$refname" "$short_refname"
            else
                echo "    Push accepted. No releases done for $group_name/$repo_name $short_refname"
            fi
        ;;
        refs/tags/*,tag)
          # annotated tag
          refname_type="annotated tag"
          function="atag"
          short_refname=${refname##refs/tags/}
        ;;
    esac
}

while read REF; do process_ref $REF; done

exit 0

剧本是根据此启动后收到.send_email脚本这已经是引述SO多次。

The script was started based on this post-receive.send_email script which is already quoted on SO multiple times.

在脚本中的变量硬codeD配置发布区，或如添加一个机制来读取一个回购的配置文件。也许你想给在这个区域内的用户控制。取决于你的安全情况。

Configure a release area in the variable hardcoded in the script, or e.g. add a mechanism to read a config file in the repo. Maybe you want to give users control over this area. Depends on your security circumstances.

发布区域必须是git的@ gitlab用户可访问的，当然，任何客户期望的出口。

The release area must be accessible by the git@gitlab user, and of course by any client expecting the export.

出口分支是在脚本中硬codeD。

The branch to export is hardcoded in the script.

发布区域将被填充是这样的：

The release area will be populated like this:

$release_root/$group_name/$repo_name/dated/$release_date

另外一个符号链接最新的指向最新的 $ RELEASE_DATE 。我们的想法是，这是可扩展的，以后还可以还出口标签。如果您希望导出不同的分支，一个 $分支应作为一个路径组件了。

Plus a symbolic link latest pointing to the latest $release_date. The idea is that this is extensible to later be able to also export tags. If you expect to export different branches, a $branch should be included as a path component, too.

在gitlab服务器的访问控制是不传下来的目录结构。目前，我手动做到这一点，这就是为什么我不自动填充与此挂钩的所有新库。我宁愿手动配置，然后相应地调整上的 $ release_root / $组名路径UNIX组权限（和/或访问控制列表）。这需要每个组只有一次完成，工作，因为没有人被允许在我gitlab实例创建新组。这是从默认非常不同的

Access control of the gitlab server is not passed down to the directory structure. Currently I do this manually, and that is why I do not auto-populate all new repositories with this hook. I'd rather configure manually, and then adjust unix group permissions (and/or ACLs) on the $release_root/$groupname paths accordingly. This needs to be done only once per group and works because no one else is allowed to create new groups on my gitlab instance. This is very different from the default.

还有什么我们能为您做什么？ ; - ）

Anything else we can do for you? ;-)

这篇关于如何部署Gitlab项目分公司目录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！