4
4
\styled{index}
5
5
6
6
\splash-intro{
7
- \inline-header{Concourse is an open-source continuous thing-doer .}
7
+ \inline-header{Concourse is an open-source continuous automation platform .}
8
8
9
- Built on the simple mechanics of \reference{resources}{resources},
10
- \reference{tasks}{tasks}, and \reference{jobs}{jobs}, Concourse presents a
11
- general approach to automation that makes it great for
9
+ Centered around the simple mechanics of \reference{resources}{resources},
10
+ \reference{tasks}{tasks}, and \reference{jobs}{jobs}, Concourse delivers a
11
+ versatile approach to automation that excels at
12
12
\link{CI}{https://en.wikipedia.org/wiki/Continuous_integration}/\link{CD}{https://en.wikipedia.org/wiki/Continuous_delivery}.
13
13
14
14
\button{\reference{quick-start}}
15
15
}{
16
16
\download-links
17
17
}
18
18
19
- \page-region{light}{Built in the open}{
20
- Concourse's \link{RFC process}{https://github.com/concourse/rfcs} and
21
- \link{governance model}{https://github.com/concourse/governance} invite
22
- anyone to become a contributor, developing the project roadmap by
23
- collaborating in the open.
24
-
25
- \rfcs-table{10}{ByTotalReactions}
26
-
27
- Help shape Concourse into a tool that fits your needs by \link{submitting
28
- feedback}{https://github.com/concourse/rfcs/#reviewing-rfcs} on the RFCs
29
- listed above!
30
- }
31
-
32
- \page-region{light}{Key features}{
33
- Concourse is designed to be \link{expressive, versatile, and
34
- safe}{https://github.com/concourse/rfcs/blob/master/DESIGN_PRINCIPLES.md},
35
- remaining intuitive as the complexity of your project grows.
19
+ \page-region{light}{Core features}{
20
+ Concourse is engineered to be \link{expressive, versatile, and
21
+ secure}{https://github.com/concourse/rfcs/blob/master/DESIGN_PRINCIPLES.md},
22
+ remaining intuitive even as your project complexity grows.
36
23
37
24
\side-by-side{
38
- \inline-header{Configure as code }
25
+ \inline-header{Code-based configuration }
39
26
40
27
\codeblock{yaml}{{{
41
28
resources:
52
39
file: booklit/ci/test.yml
53
40
}}}
54
41
}{
55
- \inline-header{Visualize to verify }
42
+ \inline-header{Visual verification }
56
43
57
44
\include-template{basic-pipeline-svg}
58
45
}
59
46
60
47
\side-by-side{
61
- A Concourse \reference{pipelines}{pipeline} is like a distributed, continuous
48
+ A Concourse \reference{pipelines}{pipeline} functions like a distributed, continuous
62
49
\code{Makefile}.
63
50
64
- Each \reference{jobs}{job} has a \reference{schema.job.plan}{build plan}
65
- declaring the job's input \reference{resources}{resources} and what to run
66
- with them when they change .
51
+ Each \reference{jobs}{job} contains a \reference{schema.job.plan}{build plan}
52
+ defining the job's input \reference{resources}{resources} and what actions to perform
53
+ with them when changes occur .
67
54
}{
68
- Your pipeline is then visualized in the web UI, taking only one click to get
69
- from a failed job to seeing why it failed .
55
+ Your pipeline appears visualized in the web UI, requiring just one click to move
56
+ from a failed job to understanding the cause of failure .
70
57
71
- The visualization provides a "gut check" feedback loop : if it \italic{looks}
58
+ The visualization provides immediate feedback: if it \italic{looks}
72
59
wrong, it probably \italic{is} wrong.
73
60
}
74
61
75
- \inline-header{A more complicated example...}
62
+ \inline-header{A more complex example...}
76
63
77
- Jobs can depend on other jobs by configuring
78
- \reference{schema.get.passed}{\code{passed}} constraints. The resulting chain
79
- of jobs and resources is a dependency graph that continuously pushes your
80
- project forward, from source code to production.
64
+ Jobs can depend on other jobs through \reference{schema.get.passed}{\code{passed}} constraints.
65
+ The resulting network of jobs and resources creates a dependency graph that continuously
66
+ advances your project forward, from source code to production.
81
67
82
68
\include-template{pipeline-image}
83
69
84
- \italic{This particular pipeline can be found in the \link{Booklit
70
+ \italic{This pipeline example can be found in the \link{Booklit
85
71
repository}{https://github.com/concourse/booklit/blob/8741a4ca3116dcf24c30fedfa78e4aadcaff178a/ci/pipeline.yml}.}
86
72
87
- \splash-example{CI under source control }{
88
- All configuration and administration is done using \reference{fly-cli}{the
73
+ \splash-example{Source-controlled CI }{
74
+ All configuration and management happens through \reference{fly-cli}{the
89
75
\code{fly} CLI}.
90
76
91
- The \reference{fly-set-pipeline} command pushes the config up to Concourse.
92
- Once it looks good , you can then check the file in to source control. This
93
- makes it easy to recover your project if the Concourse server burns down .
77
+ The \reference{fly-set-pipeline} command uploads your configuration to Concourse.
78
+ Once finalized , you can commit the file to source control, making it easy to
79
+ recover your project if you migrate to a new Concourse server .
94
80
}{
95
81
\codeblock{sh}{{{
96
82
$ fly -t ci set-pipeline -p booklit -c pipeline.yml
102
88
}
103
89
104
90
\splash-example{Reproducible, debuggable builds}{
105
- Everything runs in containers, ensuring a clean environment on every run.
91
+ Everything executes in containers, ensuring a clean environment for each run.
106
92
107
- Each \reference{tasks}{task} specifies its own image, giving it full control
108
- over its dependencies, rather than managing packages and state on your
109
- workers.
93
+ Every \reference{tasks}{task} specifies its own image, providing complete control
94
+ over its dependencies, instead of managing packages on your workers.
110
95
111
- The \reference{fly-intercept} command will pop you right into one of your
112
- build's containers, making it easy to troubleshoot flaky builds.
96
+ The \reference{fly-intercept} command lets you access a build's containers directly,
97
+ simplifying troubleshooting of problematic builds.
113
98
}{
114
99
\codeblock{sh}{{{
115
100
$ fly -t ci intercept -j booklit/unit -s unit
123
108
}}}
124
109
}
125
110
126
- \splash-example{Rapid local iteration }{
127
- The \reference{fly-execute} command lets you run a build with local changes .
111
+ \splash-example{Efficient local testing }{
112
+ The \reference{fly-execute} command enables you to run builds with local modifications .
128
113
129
- This build runs in exactly the same way as it would run in your pipeline,
130
- without having to push broken commits until it works .
114
+ These builds execute exactly as they would in your pipeline, eliminating the
115
+ need to push incomplete commits while debugging .
131
116
132
- When a build in the pipeline fails, you can run \reference{fly-execute} with
117
+ When a pipeline build fails, you can use \reference{fly-execute} with
133
118
the \code{-j} flag to run a one-off build with the same inputs as the failed
134
- build. You can then replace an input with your local changes with \code{-i}
135
- to see if your fix is valid .
119
+ build. You can then replace an input with your local changes using \code{-i}
120
+ to test your fix.
136
121
}{
137
122
\codeblock{sh}{{{
138
123
~/booklit $ fly -t ci execute -c ci/test.yml
147
132
}}}
148
133
}
149
134
150
- \inline-header{Bring your own integrations}
135
+ \inline-header{Custom integrations}
151
136
152
137
\side-by-side{
153
138
\codeblock{yaml}{{{
170
155
- # ...
171
156
}}}
172
157
}{
173
- Concourse does not have a complex plugin system. Instead, it focuses on a
174
- single strong abstraction: \reference{resources}{resource}, which are
158
+ Concourse doesn't rely on a complex plugin system. Instead, it focuses on a
159
+ single powerful abstraction: \reference{resources}{resource}, which are
175
160
implemented by \reference{resource-types}{resource types}.
176
161
177
162
The \reference{schema.pipeline.resources} field configures external artifacts
178
- that your pipeline will monitor for changes, fetch from , and push to .
163
+ that your pipeline will monitor for changes, retrieve , and update .
179
164
180
- For example , a resource with type \code{git} refers to a git repository,
165
+ For instance , a resource with type \code{git} refers to a git repository,
181
166
which will be \code{clone}d in a \reference{get-step} and \code{push}ed to
182
- using a \reference{put-step}. Behind the scenes, Concourse will continuously
183
- run \code{git fetch} to look for new commits that jobs may want to trigger
167
+ using a \reference{put-step}. Behind the scenes, Concourse continuously
168
+ runs \code{git fetch} to check for new commits that jobs might want to trigger
184
169
on.
185
170
186
- At its core , Concourse knows nothing about \code{git}. It comes with a
171
+ At its foundation , Concourse has no built-in knowledge of \code{git}. It includes a
187
172
\link{\code{git} resource type}{https://github.com/concourse/git-resource}
188
- out of the box , but you could just as easily bring your own into your
189
- pipeline by setting the \reference{schema.pipeline.resource_types} field.
173
+ by default , but you can easily integrate your own into your pipeline through
174
+ the \reference{schema.pipeline.resource_types} field.
190
175
191
- To see what resource types are available , check out the \link{Resource Types
176
+ To discover available resource types, check out the \link{Resource Types
192
177
catalog}{https://resource-types.concourse-ci.org}!
193
178
}
194
179
}
198
183
\include-section{./docs.lit}
199
184
\include-section{./examples.lit}
200
185
\include-section{./project.lit}
201
- \include-section{./ecosystem.lit}
186
+ \include-section{./ecosystem.lit}
0 commit comments