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
=== 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.
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:
0 commit comments