Skip to content

Commit 8fd052f

Browse files
authored
Add files via upload
1 parent f74b2e1 commit 8fd052f

1 file changed

Lines changed: 188 additions & 0 deletions

File tree

week4/concepts.po

Lines changed: 188 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,188 @@
1+
# SOME DESCRIPTIVE TITLE.
2+
# Copyright (C) 2012-2026, Zuul project contributors
3+
# This file is distributed under the same license as the Zuul package.
4+
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
5+
#
6+
#, fuzzy
7+
msgid ""
8+
msgstr ""
9+
"Project-Id-Version: Zuul latest\n"
10+
"Report-Msgid-Bugs-To: \n"
11+
"POT-Creation-Date: 2026-02-02 09:55+0900\n"
12+
"PO-Revision-Date: 2026-02-12 10:55+0900\n"
13+
"Last-Translator: \n"
14+
"Language-Team: \n"
15+
"Language: ko_KR\n"
16+
"MIME-Version: 1.0\n"
17+
"Content-Type: text/plain; charset=UTF-8\n"
18+
"Content-Transfer-Encoding: 8bit\n"
19+
"X-Generator: Poedit 3.8\n"
20+
21+
#: ../../source/concepts.rst:4
22+
msgid "Zuul Concepts"
23+
msgstr "Zuul 주요 개념"
24+
25+
#: ../../source/concepts.rst:6
26+
msgid ""
27+
"Zuul is organized around the concept of a *pipeline*. In Zuul, a pipeline "
28+
"encompasses a workflow process which can be applied to one or more "
29+
"projects. For instance, a \"check\" pipeline might describe the actions "
30+
"which should cause newly proposed changes to projects to be tested. A "
31+
"\"gate\" pipeline might implement :ref:`project_gating` to automate merging "
32+
"changes to projects only if their tests pass. A \"post\" pipeline might "
33+
"update published documentation for a project when changes land."
34+
msgstr ""
35+
"Zuul은 *파이프라인*이라는 개념을 중심으로 설계됩니다. Zuul에서, 파이프라인"
36+
"은 하나 이상의 프로젝트들에 적용될 수 있는 워크플로우 프로세스를 포함합니"
37+
"다. 예시로, \"check\" 파이프라인은 프로젝트에 새로 제안된 변경 사항들을 테스"
38+
"트하는 작업들을 정의할 수 있습니다 \"gate\" 파이프라인은 \":ref. "
39+
"'projct_gating'을 구현하여 테스트를 통과한 경우에만 프로젝트에 변경 사항을 자"
40+
"동으로 병합할 수 있습니다. \"post\" 파이프라인은 변경 사항이 반영되었을 때 "
41+
"프로젝트의 공개 문서를 갱신할 수 있습니다."
42+
43+
#: ../../source/concepts.rst:15
44+
msgid ""
45+
"The names \"check\", \"gate\", and \"post\" are arbitrary -- these are not "
46+
"concepts built into Zuul, but rather they are just a few common examples of "
47+
"workflow processes that can be described to Zuul and implemented as "
48+
"pipelines."
49+
msgstr ""
50+
"\"check\", \"gate\", \"post\"라는 이름은 임의로 명명된 것입니다. -- 이 이름들"
51+
"은 Zuul에 고정된 개념들이 아니라, Zuul에서 정의되고 파이프라인에서 구현될 수 "
52+
"있는 워크플로우 프로세스들의 흔한 예시들일 뿐입니다."
53+
54+
#: ../../source/concepts.rst:20
55+
msgid ""
56+
"Once a pipeline has been defined, any number of projects may be associated "
57+
"with it, each one specifying what jobs should be run for that project in a "
58+
"given pipeline."
59+
msgstr ""
60+
"일단 파이프라인이 정의되면, 많은 프로젝트들을 해당 파이프라인에 연결할 수 있"
61+
"으며, 프로젝트들은 각자 연결된 파이프라인에서 실행할 잡(job)을 정하게 됩니다."
62+
63+
#: ../../source/concepts.rst:24
64+
msgid ""
65+
"Pipelines have associated *triggers* which are descriptions of events which "
66+
"should cause something to be enqueued into a pipeline. For example, when a "
67+
"patchset is uploaded to Gerrit, a Gerrit *patchset-created* event is "
68+
"emitted. A pipeline configured to trigger on *patchset-created* events "
69+
"would then enqueue the associated change when Zuul receives that event. If "
70+
"there are jobs associated with that project and pipeline, they will be run. "
71+
"In addition to Gerrit, other triggers are available, including GitHub, "
72+
"timer, and zuul. See :ref:`drivers` for a full list of available triggers."
73+
msgstr ""
74+
"파이프라인에는 특정 이벤트들을 파이프라인 대기열에 넣도록 정의된 *트리거"
75+
"(trigger)*가 연결되어 있습니다. 예를 들어, 패치셋을 Gerrit에 업로드할 때, "
76+
"Gerrit *patchset-created* 이벤트가 발생됩니다. *patchset-created* 이벤트 트"
77+
"리거가 설정된 파이프라인은 Zuul이 그 이벤트를 수신할 때 관련 변경 사항을 대기"
78+
"열에 넣습니다. 만약 해당 프로젝트와 파이프라인에 연결된 작업들이 있다면, 그 "
79+
"작업들이 실행됩니다. Gerrit 외에도 GitHub, 타이머, Zuul등 다른 트리거들을 사"
80+
"용할 수 있습니다. 사용할 수 있는 트리거의 전체 목록은 :ref:'drivers'에 있습니"
81+
"다."
82+
83+
#: ../../source/concepts.rst:34
84+
msgid ""
85+
"Once all of the jobs for an item in a pipeline have been run, the pipeline's "
86+
"*reporters* are responsible for reporting the results of all of the jobs. "
87+
"Continuing the example from earlier, if a pipeline were configured with a "
88+
"Gerrit reporter, it would leave a review comment on the change and set any "
89+
"approval votes that are configured. There are several reporting phases "
90+
"available; each of which may be configured with any number of reporters. "
91+
"See :ref:`drivers` for a full list of available reporters."
92+
msgstr ""
93+
"파이프라인에 있는 어느 아이템의 모든 작업들이 실행 완료되면, 해당 파이프라인"
94+
"의 *리포터(reporter)*가 모든 작업의 결과를 보고하는 역할을 합니다. 앞선 예"
95+
"시를 이어가자면, 파이프라인에 Gerrit 리포터가 설정된 경우, 리포터는 변경사항"
96+
"에 리뷰 댓글을 남기고, 설정돤 승인 투표를 실행합니다. 리포팅 단계는 여러 단"
97+
"계들로 이루어져 있고 각 단계마다 원하는 수의 리포터를 설정할 수 있습니다. 사"
98+
"용 가능한 리포터들의 전체 목록은 :ref:`drivers`을 참조하세요."
99+
100+
#: ../../source/concepts.rst:43
101+
msgid ""
102+
"The items enqueued into a pipeline are each associated with a `git ref "
103+
"<https://git-scm.com/book/en/v2/Git-Internals-Git-References>`_. That ref "
104+
"may point to a proposed change, or it may be the tip of a branch or a tag. "
105+
"The triggering event determines the ref, and whether it represents a "
106+
"proposed or merged commit. Zuul prepares the ref for an item before running "
107+
"jobs. In the case of a proposed change, that means speculatively merging "
108+
"the change into its target branch. This means that any jobs that operate on "
109+
"the change will run with the git repo in the state it will be in after the "
110+
"change merges (which may be substantially different than the git repo state "
111+
"of the change itself since the repo may have merged other changes since the "
112+
"change was originally authored). Items in a pipeline may depend on other "
113+
"items, and if they do, all of their dependent changes will be included in "
114+
"the git repo state that Zuul prepares. Zuul attempts to maximize throughput "
115+
"by running jobs for multiple changes in parallel. Jobs may also specify "
116+
"that they require additional git repos, and if so, the repo state (as of the "
117+
"time when the item was enqueued in the pipeline) for those repos will also "
118+
"be included. For more detail on this process, "
119+
"see :ref:`project_gating`, :ref:`dependencies`, and :ref:`global_repo_state`."
120+
msgstr ""
121+
"파이프라인 대기열에 들어가는 아이템은 각각 `git ref <https://git-scm.com/"
122+
"book/en/v2/Git-Internals-Git-References>`_에 연결됩니다. 해당 ref는 제안된 변"
123+
"경 사항을 가리키거나, 브랜치의 끝 혹은 태그를 나타낼 수도 있습니다. 트리거 이"
124+
"벤트에 따라 해당 ref가 결정되며, 이것이 제안된 커밋인지 병합된 커밋인지도 결"
125+
"정합니다. Zuul은 작업을 실행하기 전에 해당 아이템을 위한 ref를 준비합니다. "
126+
"제안된 변경 사항의 경우, 해당 변경사항을 대상 브렌치에 추측성으로 병합하는 것"
127+
"을 의미합니다. 즉, 이는 변경 사항을 처리하는 모든 작업은 해당 변경 사항이 병"
128+
"합 완료된 상태의 git 저장소에서 실행된다는 걸 의미합니다(변경사항이 처음 작성"
129+
"된 시점 이후로 저장소에 다른 변경사항이 병합되었을 수 있으므로, 원래의 변경사"
130+
"항 상태와 상당히 다를 수 있습니다 ). 파이프라인의 아이템들은 또 다른 아이템"
131+
"에 의존할 수 있으며, 이 경우 Zuul이 준비한 git 저장소에 의존하는 모든 변경 사"
132+
"항들이 포함됩니다. Zuul은 여러 변경사항에 대한 작업을 병렬로 실행하여 처리량"
133+
"을 극대화합니다. 작업은 추가 git 저장소를 요구할 수 있으며 이 경우, 그 저장"
134+
"소 상태도(아이템의 파이프라인에 들어온 시점 기준) 포함됩니다. 이 과정의 상세"
135+
"한 내용은 :ref:`project_gating`, :ref:`dependencies`,"
136+
"와 :ref:`global_repo_state`.에 있습니다."
137+
138+
#: ../../source/concepts.rst:64
139+
msgid ""
140+
"The configuration for nearly everything described above is held in files "
141+
"inside of the git repos upon which Zuul operates. Zuul's configuration is "
142+
"global, but distributed. Jobs which are defined in one project might be "
143+
"used in another project while pipelines are available to all projects. When "
144+
"Zuul starts, it reads its configuration from all of the projects it knows "
145+
"about, and when changes to its configuration are proposed, those changes may "
146+
"take effect temporarily as part of the proposed change, or immediately after "
147+
"the change merges, depending on the type of project in which the change "
148+
"appears."
149+
msgstr ""
150+
"위에서 설명한 거의 모든 설정은 Zuul이 관리하는 git 저장소 내부 파일에 저장되"
151+
"어 있습니다. Zuul의 설정은 전역적인 동시에 분산되어 있습니다. 한 프로젝트에"
152+
"서 정의된 작업은 다른 프로젝트에서 사용될 수 있으며, 파이프라인은 모든 프로젝"
153+
"트에서 사용가능 합니다. Zuul은 시작될 때, 자신이 알고 있는 모든 프로젝트들"
154+
"의 설정을 읽습니다. 그리고, 그 설정의 변경사항이 제안될 때, 프로젝트의 유형"
155+
"에 따라 해당 변경사항을 검증하는 동안만 임시로 적용되거나 병합된 후 즉시 반영"
156+
"됩니다."
157+
158+
#: ../../source/concepts.rst:75
159+
msgid ""
160+
"Jobs specify the type and quantity of nodes which they require. Zuul may be "
161+
"configured to supply static nodes or contact cloud providers to create or "
162+
"delete nodes as necessary."
163+
msgstr ""
164+
"잡(job)은 자신이 필요한 노드의 타입과 개수를 명시합니다. Zuul은 정적 노드를 "
165+
"제공하거나 필요에 따라 노드를 생성, 삭제하기 위해 클라우드 제공자와 통신하도"
166+
"록 설정될 수 있습니다."
167+
168+
#: ../../source/concepts.rst:79
169+
msgid ""
170+
"The executable contents of jobs themselves are Ansible playbooks. Ansible's "
171+
"support for orchestrating tasks on remote nodes is particularly suited to "
172+
"Zuul's support for multi-node testing. Ansible is also easy to use for "
173+
"simple tasks (such as executing a shell script) or sophisticated deployment "
174+
"scenarios. When Zuul runs Ansible, it attempts to do so in a manner most "
175+
"similar to the way that Ansible might be used to orchestrate remote "
176+
"systems. Ansible itself is run on the :ref:`executor <executor>` and acts "
177+
"remotely upon the test nodes supplied to a job. This facilitates continuous "
178+
"delivery by making it possible to use the same Ansible playbooks in testing "
179+
"and production."
180+
msgstr ""
181+
"잡(job)에서 실행되는 내용은 Ansible 플레이북입니다. 원격 노드에서 작업을 조율"
182+
"하는 Ansible의 방식은 특히 Zuul의 멀티 노드 테스팅 지원에 적합합니다. 또한 "
183+
"Ansible은 쉘 스크립트 실행 같은 간단한 일부터 복잡한 배포 시나리오에 사용하"
184+
"기 쉽습니다. Zuul이 Ansible을 실행할 때, Zuul은 Ansible이 원격 시스템을 조율"
185+
"하는 방식과 비슷하게 하려고 시도합니다. Ansible 그자체는 :ref:`executor "
186+
"<executor>에서 실행되며, 잡(job)에 할당된 테스트 노드에 대해 원격으로 동작합"
187+
"니다. 이는 테스트와 운영환경에서 동일한 Ansible 플레이북을 사용하는 것을 가"
188+
"능하게 함으로써 지속적 인도를 용이하게 합니다."

0 commit comments

Comments
 (0)