Skip to content

Commit e67377e

Browse files
Merge branch 'main' into formatting-fix-auto-rerun
2 parents d7eaf0f + d905403 commit e67377e

File tree

11 files changed

+204
-82
lines changed

11 files changed

+204
-82
lines changed

docs/guides/modules/integration/pages/github-integration.adoc

Lines changed: 0 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -337,15 +337,6 @@ Until October 2024, the CircleCI GitHub App integration was available exclusivel
337337

338338
The GitHub App and OAuth app can **co-exist side-by-side in the same organization**. You do not need to sacrifice functionality that is xref:version-control-system-integration-overview.adoc#feature-support-for-each-integration-type[not yet available to either integration], or migrate to a new organization.
339339

340-
Key functionality enabled through the GitHub App integration includes the following:
341-
342-
* The option to have **multiple pipelines in the same project**, each defined in its own YAML file.
343-
* The possibility to set up your pipelines so that the **config file and the application code are stored in different repositories**. Refer to the link:https://circleci.com/changelog/unlocking-any-cross-repo-pipeline-and-trigger-setups-including-central/[changelog entry] for more information.
344-
* A **more flexible trigger system**, with each pipeline having any number of VCS or non-VCS triggers. This includes:
345-
** **Non-repo based triggers**: xref:orchestrate:custom-webhooks.adoc[Custom webhooks] enable triggering builds from any system that can emit webhook events. Refer to our link:https://discuss.circleci.com/t/product-update-trigger-pipelines-from-anywhere-custom-webhooks/49864[community forum] for an example and known limitations.
346-
** **Cross-repo triggers**: Events in one repository can trigger builds on one or many other repositories.
347-
** **More GitHub events as triggers**: Pipelines can be set up to run on events other than "push", including pull request events, with more powerful customization of trigger conditions. For full details, see the xref:orchestrate:github-trigger-event-options.adoc[GitHub trigger event options] page.
348-
349340
More information is available on the xref:guides:integration:using-the-circleci-github-app-in-an-oauth-org.adoc[Using the CircleCI GitHub App in an OAuth organization] page.
350341

351342
[#next-steps]

docs/guides/modules/orchestrate/pages/pipeline-variables.adoc

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -116,7 +116,7 @@ Refer to the xref:toolkit:api-developers-guide.adoc#getting-started-with-the-api
116116
[#passing-parameters-when-triggering-pipelines-using-the-circleci-web-app]
117117
=== Passing parameters when triggering pipelines using the CircleCI web app
118118

119-
In addition to using the API, you can also trigger a pipeline with parameters from the CircleCI web app. If you pass a parameter when triggering a pipeline from the web app, and the parameter has not been declared in the configuration file, the pipeline will fail with the error `Unexpected argument(s)`.
119+
In addition to using the API, you can also trigger a pipeline with parameters from the CircleCI web app. If you pass a parameter when triggering a pipeline, and the parameter has not been declared in the configuration file, the pipeline will fail with the error `Unexpected argument(s)`.
120120

121121
. Use the project filter to select the desired project.
122122
. Use the branch filter to select the branch on which you want to run the new pipeline.
@@ -140,7 +140,7 @@ The remaining configuration is processed, element parameters are resolved, type-
140140
[#the-scope-of-parameters-in-configuration]
141141
== The scope of parameters in configuration
142142

143-
Pipeline parameters can only be resolved in the `.circleci/config.yml` file in which they are declared. Pipeline parameters are not available in orbs, including orbs declared locally in your `.circleci/config.yml` file. This is because access to pipeline scope in orbs would break encapsulation and create a hard dependency between the orb and the calling configuration. This would potentially create a surface area of vulnerability, increasing security risks.
143+
Pipeline parameters can only be resolved in the `.circleci/config.yml` file in which they are declared. Pipeline parameters are not available in orbs, including orbs declared locally in your `.circleci/config.yml` file. Access to pipeline scope in orbs would break encapsulation and create a hard dependency between the orb and the calling configuration. This would potentially create a surface area of vulnerability, increasing security risks.
144144

145145
[#element-parameter-scope]
146146
=== Element parameter scope
@@ -174,10 +174,10 @@ workflows:
174174
my-workflow:
175175
jobs:
176176
- daily-message:
177-
message: echo << parameters.message >>
177+
message: << parameters.message >>
178178
```
179179

180-
Even though the `print` command is called from the `cat-file` job, the file parameter would not be in scope inside the print job. This ensures that all parameters are always bound to a valid value, and the set of available parameters is always known. Running this would throw a pipeline error of `Arguments referenced without declared parameters: message`.
180+
Even though the `print` command is called from the `daily-message` job, the `message` parameter would not be in scope inside `my-workflow`. This ensures that all parameters are always bound to a valid value, and the set of available parameters is always known. Running this would throw a pipeline error of `Arguments referenced without declared parameters: parameters.message`.
181181

182182
[#pipeline-value-scope]
183183
=== Pipeline value scope

docs/guides/modules/orchestrate/pages/skip-build.adoc

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@ Both methods are described below.
1313
[#skip-jobs]
1414
== Skip CI for a specific push
1515

16-
By default, CircleCI automatically triggers a pipeline whenever you push changes to your project. You can override this behavior by adding one of the following tags within the first 250 characters of the body or title of the **latest commit** you pushed:
16+
If you have a trigger configured to run a pipeline on push events to your repository, you can override this behavior by adding one of the following tags within the first 250 characters of the body or title of the **latest commit** you pushed:
1717

1818
* `[ci skip]`
1919
* `[skip ci]`
@@ -33,6 +33,8 @@ A few points to note regarding the scope of the `ci skip` feature:
3333

3434
* If you push multiple commits at once, and the latest commit includes a `[ci skip]` or `[skip ci]` tag, it will skip the pipeline execution for all commits in that push.
3535
* This feature is not supported for fork PRs. Scheduled workflows will run even if you push a commit with `[ci skip]` message. Changing the config file is the way to upgrade the current schedule.
36+
* For GitHub OAuth and Bitbucket Cloud pipelines, this functionality applies also when the pipeline is triggered via API, manually via the web app, or via schedule.
37+
* GitHub App pipelines triggered via Custom webhook or via schedule are never skipped
3638

3739
=== Example commit title
3840

docs/reference/modules/ROOT/pages/configuration-reference.adoc

Lines changed: 38 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -1667,33 +1667,17 @@ workflows:
16671667
[#checkout]
16681668
=== *`checkout`*
16691669
1670-
****
1671-
*Blobless clones*
1672-
1673-
A "blobless" strategy is being rolled out to help improve the performance of code checkouts from Git source code hosts.
1674-
1675-
Blobless clones reduce the amount of data fetched from the remote, by asking the remote to filter out objects that are not attached to the current commit.
1676-
1677-
While this improves performance in most cases, if a downstream step requires those objects to exist for scanning or comparisons, it can cause failures. To work around these potential problems, a fetch directly after a checkout will ensure the required data is available:
1678-
1679-
[,yml]
1680-
----
1681-
jobs:
1682-
build:
1683-
docker:
1684-
- image: cimg/go:1.24.2
1685-
steps:
1686-
- checkout
1687-
- run: git fetch
1688-
----
1689-
****
1690-
16911670
A special step used to check out source code to the configured `path` (defaults to the `working_directory`). The reason this is a special step is because it is more of a helper function designed to simplify the process of checking out code. If you require doing git over HTTPS you should not use this step as it configures git to checkout over SSH.
16921671
16931672
[cols="1,1,1,2", options="header"]
16941673
|===
16951674
| Key | Required | Type | Description
16961675
1676+
| `method`
1677+
| N
1678+
| String
1679+
| Checkout method. Valid options include `blobless` and `full`. (default: `full`)
1680+
16971681
| `path`
16981682
| N
16991683
| String
@@ -1721,6 +1705,39 @@ jobs:
17211705
17221706
The checkout command automatically adds the required authenticity keys for interacting with GitHub and Bitbucket over SSH. These keys are detailed further in the xref:guides:integration:github-integration.adoc#establish-the-authenticity-of-an-ssh-host[integration guide]. This guide is also helpful if you wish to implement a custom checkout command.
17231707
1708+
You can specify a checkout strategy by using the `method` key. CircleCI supports full clones or blobless clones. Blobless clones reduce the amount of data fetched from the remote by asking the remote to filter out objects that are not attached to the current commit.
1709+
1710+
*Example:*
1711+
1712+
[,yml]
1713+
----
1714+
jobs:
1715+
build:
1716+
docker:
1717+
- image: cimg/go:1.24.2
1718+
steps:
1719+
- checkout:
1720+
method: blobless
1721+
----
1722+
1723+
[NOTE]
1724+
====
1725+
In certain cases, we will fall back to a full checkout even though blobless was specified. This will occur if Git and SSH clients are not available in the current environment, or if Git version 2.41.0 is installed which contained a link:https://lore.kernel.org/git/[email protected]/[known issue] for blobless clones.
1726+
====
1727+
1728+
If a downstream step requires those objects to exist for scanning or comparisons, a blobless clone can cause failures. In that case, you can specify a full checkout as shown in the following example:
1729+
1730+
[,yml]
1731+
----
1732+
jobs:
1733+
build:
1734+
docker:
1735+
- image: cimg/go:1.24.2
1736+
steps:
1737+
- checkout:
1738+
method: full
1739+
----
1740+
17241741
CircleCI does not check out submodules. If your project requires submodules, add `run` steps with appropriate commands as shown in the following example:
17251742
17261743
[,yml]

docs/server-admin-4.2/modules/operator/pages/circleci-server-security-features.adoc

Lines changed: 22 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -10,17 +10,25 @@ This document outlines security features built into CircleCI and related integra
1010

1111
[#security-overview]
1212
== Overview
13-
Security is our top priority at CircleCI. We are proactive and we act on security issues immediately. Report security issues to [email protected] with an encrypted message using our security team's GPG key (ID: 0x4013DDA7, fingerprint: 3CD2 A48F 2071 61C0 B9B7 1AE2 6170 15B8 4013 DDA7).
13+
Security is our top priority at CircleCI. We are proactive and we act on security issues immediately. Report security issues to mailto:[email protected][] with an encrypted message using our security team's GPG key (ID: `0x4013DDA7`, fingerprint: `3CD2 A48F 2071 61C0 B9B7 1AE2 6170 15B8 4013 DDA7`).
1414

1515
[#encryption]
1616
== Encryption
17-
CircleCI uses HTTPS or SSH for all networking in and out of our service, including from the browser to our services application, from the services application to your builder fleet, from our builder fleet to your source control system, and all other points of communication. None of your code or data travels to or from CircleCI without being encrypted, unless you have code in your builds that does so at your discretion. Operators may also choose to bypass our SSL configuration or not use TLS for communicating with underlying systems.
17+
CircleCI uses HTTPS or SSH for all networking in and out of our service, including:
1818

19-
The nature of CircleCI is that our software has access to your code and whatever data that code interacts with. All jobs on CircleCI run in a sandbox (specifically, a Docker container or an ephemeral VM) that stands alone from all other builds and is not accessible from the Internet or from your own network. The build agent pulls code via git over SSH. Your particular test suite or job configurations may call out to external services or integration points within your network, and the response from such calls will be pulled into your jobs and used by your code at your discretion. After a job is complete, the container that ran the job is destroyed and rebuilt. All environment variables are encrypted using link:https://www.vaultproject.io/[HashiCorp Vault]. Environment variables are encrypted using AES256-GCM96 and are unavailable to CircleCI employees.
19+
* From the browser to our services application.
20+
* From the services application to your builder fleet.
21+
* From our builder fleet to your source control system, and all other points of communication.
22+
23+
None of your code or data travels to or from CircleCI without being encrypted, unless you have code in your builds that does so at your discretion. Operators may also choose to bypass our SSL configuration or not use TLS for communicating with underlying systems.
24+
25+
The nature of CircleCI is that our software has access to your code and whatever data that code interacts with. With the exception of self-hosted runner, all jobs on CircleCI run in a sandbox (specifically, a container or an ephemeral VM). THe sandbox stands alone from all other builds and is not accessible from the Internet or from your own network.
26+
27+
The build agent pulls code via git over SSH. Your test suite or job configurations may call out to external services or integration points within your network. The response from such calls will be pulled into your jobs and used at your discretion. After a job is complete, the container that ran the job is destroyed and rebuilt. All environment variables are encrypted using link:https://www.vaultproject.io/[HashiCorp Vault]. Environment variables are encrypted using AES256-GCM96 and are unavailable to CircleCI employees.
2028

2129
[#sandboxing]
2230
== Sandboxing
23-
With CircleCI, you control the resources allocated to run the builds of your code. This will be done through instances of our builder boxes that set up the containers in which your builds will run. By their nature, build containers will pull down source code and run whatever test and deployment scripts are part of the codebase or your configuration. The containers are sandboxed, each created and destroyed for one build only (or one slice of a parallel build), and they are not available from outside themselves. The CircleCI service provides the ability to SSH directly to a particular build container. When accessing a container this way, a user will have complete access to any files or processes being run inside that build container. Only provide CircleCI access to those also trusted with your source code.
31+
With CircleCI, you control the resources allocated to run the builds of your code. With the exception of self-hosted runner, this will be done through instances of our builder boxes that set up the containers in which your builds will run. By their nature, build containers will pull down source code and run whatever test and deployment scripts are part of the codebase or your configuration. The containers are sandboxed, each created and destroyed for one build only (or one slice of a parallel build), and they are not available from outside themselves. The CircleCI service provides the ability to SSH directly to a particular build container. When accessing a container this way, a user will have complete access to any files or processes being run inside that build container. Only provide CircleCI access to those also trusted with your source code.
2432

2533
[#integrations]
2634
== Integrations
@@ -29,12 +37,20 @@ A few different external services and technology integration points touch Circle
2937
[#web-sockets]
3038
=== Web sockets
3139

32-
CircleCI uses link:https://pusher.com/[Pusher] client libraries for WebSocket communication between the server and the browser. However, for installs CircleCI uses an internal server called Slanger, so Pusher servers have no access to your instance of CircleCI, nor your source control system. This is how CircleCI, for instance, updates the builds list dynamically, or show the output of a build line-by-line as it occurs. CircleCI sends build status and lines of your build output through the web socket server (which unless you have configured your installation to run without SSL is done using the same certs over SSL), so it is encrypted in transit.
40+
CircleCI uses link:https://pusher.com/[Pusher] client libraries for WebSocket communication between the server and the browser for jobs such as:
41+
42+
* Updating builds lists dynamically.
43+
* Displaying the output of a build line-by-line as it occurs.
44+
45+
For CircleCI server installations, we use an internal server called Slanger, so Pusher servers have no access to your instance of CircleCI, nor your source control system. CircleCI sends build status and build output through the web socket server. Unless you have configured your installation to run without SSL, this is done using the same certs over SSL, so it is encrypted in transit.
3346

3447
[#source-control-systems]
3548
=== Source control systems
3649

37-
To use CircleCI you will set up a direct connection with your instance of GitHub Enterprise or GitHub.com. When you set up CircleCI, you authorize the system to check out your private repositories. You may revoke this permission at any time through your GitHub application settings page and by removing Circle's Deploy Keys and Service Hooks from your repositories' Admin pages. While CircleCI allows you to selectively build your projects, GitHub's permissions model is "all or nothing" — CircleCI gets permission to access all of a user's repositories or none of them. Your instance of CircleCI will have access to anything hosted in those git repositories and will create webhooks for a variety of events (for example, when code is pushed, when a user is added, etc.) that will call back to CircleCI, triggering one or more git commands that will pull down code to your build fleet.
50+
To use CircleCI you will set up a direct connection with your instance of GitHub Enterprise or GitHub.com. When you set up CircleCI, you authorize the system to check out your private repositories. You may revoke this permission at any time through your GitHub application settings page and by removing CircleCI's Deploy Keys and Service Hooks from your repositories' Admin pages. CircleCI allows you to selectively build your projects but GitHub's permissions model is "all or nothing". That is, CircleCI gets permission to access all of a user's repositories or none of them. Your instance of CircleCI has access to anything hosted in your git repositories and will create webhooks for a variety of events. These webhooks call back to CircleCI, triggering one or more git commands that will pull down code to your build fleet. For example:
51+
52+
* When code is pushed.
53+
* When a user is added.
3854
3955
[#dependency-and-cource-caches]
4056
=== Dependency and source caches

0 commit comments

Comments
 (0)