You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guides/modules/integration/pages/github-integration.adoc
-9Lines changed: 0 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -337,15 +337,6 @@ Until October 2024, the CircleCI GitHub App integration was available exclusivel
337
337
338
338
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.
339
339
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
-
349
340
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.
=== Passing parameters when triggering pipelines using the CircleCI web app
118
118
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)`.
120
120
121
121
. Use the project filter to select the desired project.
122
122
. 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-
140
140
[#the-scope-of-parameters-in-configuration]
141
141
== The scope of parameters in configuration
142
142
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.
144
144
145
145
[#element-parameter-scope]
146
146
=== Element parameter scope
@@ -174,10 +174,10 @@ workflows:
174
174
my-workflow:
175
175
jobs:
176
176
- daily-message:
177
-
message: echo << parameters.message >>
177
+
message: << parameters.message >>
178
178
```
179
179
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`.
Copy file name to clipboardExpand all lines: docs/guides/modules/orchestrate/pages/skip-build.adoc
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ Both methods are described below.
13
13
[#skip-jobs]
14
14
== Skip CI for a specific push
15
15
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:
17
17
18
18
* `[ci skip]`
19
19
* `[skip ci]`
@@ -33,6 +33,8 @@ A few points to note regarding the scope of the `ci skip` feature:
33
33
34
34
* 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.
35
35
* 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
Copy file name to clipboardExpand all lines: docs/reference/modules/ROOT/pages/configuration-reference.adoc
+38-21Lines changed: 38 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1667,33 +1667,17 @@ workflows:
1667
1667
[#checkout]
1668
1668
=== *`checkout`*
1669
1669
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
-
1691
1670
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.
1692
1671
1693
1672
[cols="1,1,1,2", options="header"]
1694
1673
|===
1695
1674
| Key | Required | Type | Description
1696
1675
1676
+
| `method`
1677
+
| N
1678
+
| String
1679
+
| Checkout method. Valid options include `blobless` and `full`. (default: `full`)
1680
+
1697
1681
| `path`
1698
1682
| N
1699
1683
| String
@@ -1721,6 +1705,39 @@ jobs:
1721
1705
1722
1706
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.
1723
1707
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
+
1724
1741
CircleCI does not check out submodules. If your project requires submodules, add `run` steps with appropriate commands as shown in the following example:
Copy file name to clipboardExpand all lines: docs/server-admin-4.2/modules/operator/pages/circleci-server-security-features.adoc
+22-6Lines changed: 22 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,17 +10,25 @@ This document outlines security features built into CircleCI and related integra
10
10
11
11
[#security-overview]
12
12
== 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`).
14
14
15
15
[#encryption]
16
16
== 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:
18
18
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.
20
28
21
29
[#sandboxing]
22
30
== 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.
24
32
25
33
[#integrations]
26
34
== Integrations
@@ -29,12 +37,20 @@ A few different external services and technology integration points touch Circle
29
37
[#web-sockets]
30
38
=== Web sockets
31
39
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.
33
46
34
47
[#source-control-systems]
35
48
=== Source control systems
36
49
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:
0 commit comments