git, nagios và hook, git repo bị hỏng


14

Lý lịch

Chúng tôi đang sử dụng nagios để giám sát cơ sở hạ tầng của chúng tôi. Hiện tại chúng tôi không có cấu hình nagios dưới sự kiểm soát phiên bản và có hai chúng tôi quản lý cấu hình nagios. Như vậy, tôi đang làm việc để đưa cấu hình nagios của chúng tôi vào một repo trung tâm, sử dụng một số hook để kiểm tra cú pháp và sau đó nếu cấu hình trông ổn, hãy làm cho chúng "hoạt động". Tôi đang sử dụng bài viết của anh chàng này như một điểm khởi đầu.

Quy trình công việc chung mà tôi đang cố gắng thực hiện là:

  1. Chỉnh sửa repo git cục bộ của nagios config. Thêm tập tin chỉnh sửa, cam kết cục bộ.
  2. git push origin master đến repo từ xa.
  3. Push bị chặn bởi hook nhận trước, nó lấy các tệp, di chuyển chúng đến một thư mục tạm thời trên máy chủ và chạy chúng thông qua trình kiểm tra cú pháp nagios.
  4. Nếu trình kiểm tra cú pháp vượt qua, chấp nhận đẩy, sau đó sử dụng hook post-commit để git pullmã mới vào thư mục cấu hình nagios trực tiếp và sau đó khởi động lại nagios.
  5. Nếu trình kiểm tra cú pháp không thành công, hãy từ chối việc đẩy, hiển thị lỗi cú pháp nagios cho người dùng.

Tuy nhiên, tôi đang gặp phải một hành vi kỳ quặc khi tôi từ chối một cú đẩy git do lỗi cú pháp trong cấu hình nagios. Những gì tôi mong đợi sẽ xảy ra là nếu tôi từ chối hook, nỗ lực đẩy sẽ rời khỏi kho lưu trữ như thế nào, không bị ảnh hưởng. Điều đó dường như không phải là trường hợp, mặc dù. Dưới đây là chi tiết về những gì tôi đang thấy:

Vấn đề

Tôi chỉnh sửa cấu hình nagios cục bộ, cố ý bao gồm lỗi cú pháp, thêm, sau đó cam kết cục bộ:

host:nagios erik$ vi nagios.cfg
host:nagios erik$ git add nagios.cfg
host:nagios erik$ git commit -m "syntax error"
[master da71aed] syntax error
 1 files changed, 1 insertions(+), 0 deletions(-)

Bây giờ tôi đẩy những thay đổi đó đến repo chính. Điều này sẽ bị từ chối do lỗi cú pháp:

host:nagios erik$ git push origin master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 12.74 KiB, done.
Total 3 (delta 1), reused 2 (delta 1)
remote: Previous HEAD position was 3ddc880... removed syntax error
remote: HEAD is now at da71aed... syntax error
remote: Nagios Config Check Exit Status: 254
remote: Your configs did not parse correctly, there was an error. Output follows.
remote:
remote: Nagios Core 3.2.3
remote: Copyright (c) 2009-2010 Nagios Core Development Team and Community Contributors
remote: Copyright (c) 1999-2009 Ethan Galstad
remote: Last Modified: 10-03-2010
remote: License: GPL
remote:
remote: Website: http://www.nagios.org
remote: Reading configuration data...
remote: Error in configuration file '/tmp/nagiosworkdir/nagios.cfg' - Line 23 (NULL value)
remote:    Error processing main config file!
remote:
remote:
remote:
remote: ***> One or more problems was encountered while processing the config files...
remote:
remote:      Check your configuration file(s) to ensure that they contain valid
remote:      directives and data defintions.  If you are upgrading from a previous
remote:      version of Nagios, you should be aware that some variables/definitions
remote:      may have been removed or modified in this version.  Make sure to read
remote:      the HTML documentation regarding the config files, as well as the
remote:      'Whats New' section to find out what has changed.
remote:
To git@remote-server.example.com:nagios
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@remote-server.example.com:nagios'

Điều này không nên chạm vào repo từ xa, nhưng nó đã làm. Nếu tôi đổi sang thư mục tạm thời cục bộ khác và cố gắng sao chép repo, tôi nhận được:

host:temp erik$ git clone git@remote-server.example.com:nagios
Cloning into nagios...
remote: Counting objects: 30, done.
remote: Compressing objects: 100% (29/29), done.
remote: Total 30 (delta 12), reused 0 (delta 0)
Receiving objects: 100% (30/30), 29.81 KiB, done.
Resolving deltas: 100% (12/12), done.
error: Trying to write ref HEAD with nonexistant object da71aedfde2e0469288acd9e45bb8b57a6e5a7b3
fatal: Cannot update the ref 'HEAD'.

Bây giờ tôi quay lại thư mục công việc ban đầu, sửa lỗi cú pháp, thêm, cam kết và đẩy:

host:nagios erik$ vi nagios.cfg
host:nagios erik$ git add nagios.cfg
host:nagios erik$ git commit -m "removing syntax error, push should succeed this time"
[master f147ded] removing syntax error, push should succeed this time
 1 files changed, 0 insertions(+), 2 deletions(-)
host:nagios erik$ git push origin master
Counting objects: 6, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 487 bytes, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Previous HEAD position was 4c80d45... syntax error
remote: HEAD is now at f147ded... removing syntax error, push should succeed this time
remote: Nagios Config Check Exit Status: 0
remote: Your configs look good and parsed correctly.
To git@remote-server.example.com:nagios
   3ddc880..f147ded  master -> master

Tại thời điểm này, kho lưu trữ vẫn ổn và tôi có thể thay đổi thư mục tạm thời và sao chép lại repo:

host:temp erik$ git clone git@remote-server.example.com:nagios
Cloning into nagios...
remote: Counting objects: 34, done.
remote: Compressing objects: 100% (33/33), done.
remote: Total 34 (delta 14), reused 0 (delta 0)
Receiving objects: 100% (34/34), 30.22 KiB, done.
Resolving deltas: 100% (14/14), done.

Đây là cái móc nhận trước tôi đang sử dụng.

Tôi đang sử dụng git v1.7.5.4 trên máy khách và v1.7.2.3 trên máy chủ.

Vì vậy, với câu hỏi : tại sao kho lưu trữ bị bỏ lại trong trạng thái không nhất quán khi tôi từ chối đẩy? Là một cái gì đó không ổn với móc git của tôi hoặc có lẽ sự hiểu biết của tôi về git là thiếu?


Bạn đang sử dụng phiên bản nào của git?
cướp

@robbyt - 1.7.5.4trên máy khách, 1.7.2.3trên máy chủ.
EEAA

Câu trả lời:


7

Bạn đang làm:

export GIT_WORK_TREE=/tmp/nagiosworkdir
/usr/bin/git checkout -f $NEW_SHA1

trong cái móc của bạn. Mặc dù nó không chạm vào bản sao làm việc thông thường của bạn nhưng nó đang cập nhật các tài liệu tham khảo trong git-dir (cụ thể là HEADtài liệu tham khảo), như thể hiện trong lỗi của bạn:

...
remote: HEAD is now at da71aed... syntax error
...

Móc của bạn đang thực hiện exit 1để từ chối cập nhật, nhưng nó không (đặt lại) HEADtham chiếu sau khi thất bại.

Tôi nghĩ bạn cần cập nhật nhánh thất bại trong hook của mình như vậy:

...
if [ "$NAGIOS_CHECK_STATUS" -ne 0 ]
   then
   echo "Your configs did not parse correctly, there was an error. Output follows."
   cat $GIT_WORK_TREE/check.out
   /usr/bin/git reset --hard $OLD_SHA1    # <-- Add This
   exit 1
else
   ...

Điều này có vẻ tuyệt vời, nickgrim. Tôi sẽ thử một chút sau hôm nay. Cảm ơn bạn!
EEAA

0

Các git checkoutlệnh trong móc của bạn được tạo / cập nhật các ref HEAD trong kho lưu trữ của bạn.

Nếu kho lưu trữ của bạn là một kho lưu trữ trần, nó có thể sống mà không cần một ref ref (bản sao mới sẽ mặc định kiểm tra nhánh chính của nó , nếu nó có một); chỉ cần xóa các tham chiếu CHÍNH trước khi thoát (có thể trong một trapđể bạn không phải sắp xếp để làm điều đó trước mỗi exitcá nhân). Bất cứ nơi nào, trước đây, trước đây, kịch bản của bạn:

trap 'git update-ref -m "removing HEAD after temporary checkout to alternate workdir" -d HEAD "$NEW_SHA1"' 0

Nếu kho lưu trữ của bạn không trống hoặc bạn muốn duy trì một ref ref (theo mặc định, bản sao sẽ kiểm tra một số nhánh khác), thì bạn sẽ phải lưu lại ref ref và khôi phục nó trước khi thoát.

Đầu tiên, trong kho lưu trữ của máy chủ, đặt lại tham chiếu CHÍNH để trỏ đến nhánh mà bạn muốn được kiểm tra theo mặc định trong các bản sao mới:

git symbolic-ref -m 'setting default branch for new clones' HEAD refs/heads/master

Sau đó, trong tập lệnh hook của bạn (bất cứ nơi nào trước khi thanh toán):

# Restore HEAD symref when exiting
saved_HEAD=$(git symbolic-ref HEAD)
trap 'git symbolic-ref -m "restoring HEAD after temporary checkout to alternate workdir" HEAD "$saved_HEAD"' 0

Nhân tiện, pre-receivehook nên đảm bảo rằng họ đọc đầy đủ stdin và xử lý tất cả các dòng họ được cho ăn. Thoát ra trước khi tiêu thụ tất cả các đầu vào đôi khi có thể kích hoạt SIGPIPE trong git-receive-packquy trình; điều này có thể không xuất hiện trong trường hợp của bạn nếu bạn chỉ đẩy một ref mỗi lần (vì bạn đã đọc ít nhất một dòng), nhưng đó là điều cần lưu ý. Có lẽ dễ dàng hơn để thực hiện móc này như một updatecái móc trong đó bạn chỉ cần quan tâm đến một lần giới thiệu một lần và có thể từ chối từng lần đẩy của từng người (có thể bạn chỉ quan tâm đến việc giữ cho đầu của chủ sạch sạch trong khi bạn kiểm tra và báo cáo về các mẹo của các chi nhánh khác, nhưng không bao giờ từ chối chúng để chúng có thể được sử dụng để cộng tác trong công việc chưa hoàn thành).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.