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
title:"How To: Acquire webhook information after agit triggerhas been created"
2
+
title:"How To: Acquire webhook information after aGit triggeris created"
3
3
description:
4
4
group:kb
5
5
sub-group:articles
@@ -11,12 +11,18 @@ categories: [Pipelines, CLI]
11
11
support-reviewed:2023-04-18 LG
12
12
---
13
13
14
-
##Overview
15
14
16
-
Currently, there is no way to gather this information via the Codefresh Web Interface. This information can be acquired via the CLI / API call to get the pipeline spec.
17
15
18
-
##Details
16
+
This article describes how to get webhook information for a Git trigger through the Codefresh CLI or API.
17
+
Currently, you cannot get webhook information through the user interface.
19
18
20
-
1.`codefresh get pipeline Project/Pipeline -o yaml`
21
-
2. Under spec.triggers you can see the information about each git trigger.
22
-
3. Information you will need is the**endpoint** and**secret** fields
19
+
##How to
20
+
21
+
* Run:
22
+
`codefresh get pipeline Project/Pipeline -o yaml`
23
+
24
+
The`spec.triggers` displays information about each Git trigger.
25
+
Look at the`endpoint` and`secret` fields.
26
+
27
+
##Related articles
28
+
[Git triggers in pipelines]({{site.baseurl}}/docs/pipelines/triggers/git-triggers/)
Copy file name to clipboardExpand all lines: _docs/kb/articles/automating-shared-secrets-creation.md
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
---
2
-
title:"How To: Automate creation of Shared Secrets"
2
+
title:"How To: Automate creation of Shared Secrets for pipelines"
3
3
description:
4
4
group:kb
5
5
sub-group:articles
@@ -11,18 +11,18 @@ categories: [Pipelines, CLI]
11
11
support-reviewed:2024-01-17 MB
12
12
---
13
13
14
-
##Overview
14
+
This articles describes how to manage secrets across different pipelines in an efficient manner.
15
15
16
-
You have numerous secrets to manage across different pipelines and want to make the process more efficient.
17
16
18
-
##Details
17
+
##Script for create secret context
19
18
20
-
The script reads each line from the provided file and appends it to the Codefresh`create context secret` command. This results in a single command that creates a secret context with all the specified secrets.
19
+
The script reads each line from the provided file and appends it to the Codefresh`create context secret` command.
20
+
This results in a single command that creates a secret context with all the specified secrets.
21
21
22
22
>**NOTE**
23
23
Ensure you have the necessary permissions to create contexts in Codefresh.
24
24
25
-
**Script**
25
+
#####Script
26
26
27
27
```bash
28
28
#!/bin/bash
@@ -38,22 +38,22 @@ done < "$1"
38
38
echo"$CMD"
39
39
```
40
40
41
-
**How to use the script**
41
+
##How to use the script
42
42
43
-
1. Prepare your secrets list
44
-
Start by preparing a file containing your secrets. Each line in the file should contain one secret in the format KEY=VALUE.
43
+
1. Prepare the list of your secrets.
44
+
Start by preparing a file containing your secrets.
45
+
Each line in the file should contain one secret in the format KEY=VALUE.
45
46
46
-
2. Set execution permissions
47
+
2. Set execution permissions.
47
48
Make the script executable by running:
48
49
`chmod +x script_name.sh`
49
50
50
-
3. Run the script
51
-
Execute the script with the command:
51
+
3. Run the script with the command:
52
52
`./script_name.sh secret_list.txt`
53
53
where:
54
54
`secret_list.txt` is the file containing your secrets
55
55
56
-
4. Verify creation
56
+
4. Verify creation.
57
57
After executing the script, verify that the secret context has been created in Codefresh with the specified secrets.
Copy file name to clipboardExpand all lines: _docs/kb/articles/docker-daemon-access.md
+42-37Lines changed: 42 additions & 37 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,38 +11,35 @@ categories: [Pipelines]
11
11
support-reviewed:2023-04-18 LG
12
12
---
13
13
14
-
##Overview
15
14
16
-
The general and most common uses-cases that require access to the Docker Daemon are covered by[Codefresh-provided native steps]({{site.baseurl}}/docs/pipelines/steps/):
17
15
18
-
* To build a Docker image:[Build step]({{site.baseurl}}/docs/pipelines/steps/build/)
19
-
* To push a Docker image:[Push step]({{site.baseurl}}/docs/pipelines/steps/push/)
20
-
* To run a Docker Composition:[Composition step]({{site.baseurl}}/docs/pipelines/steps/composition/) and[Service Containers]({{site.baseurl}}/docs/pipelines/service-containers/)
16
+
This article describes how to access the Docker Daemon within a pipeline step for custom use cases.
21
17
22
-
But there are still cases when you need direct access to the Docker Daemon in
23
-
your steps, for example:
18
+
##Docker Daemon access support
19
+
Codefresh's built-in steps cover the most common uses-cases for access to the Docker Daemon:
20
+
* Build a Docker image:[Build step]({{site.baseurl}}/docs/pipelines/steps/build/)
21
+
* Push a Docker image:[Push step]({{site.baseurl}}/docs/pipelines/steps/push/)
22
+
* Run a Docker Composition:[Composition step]({{site.baseurl}}/docs/pipelines/steps/composition/) and[Service Containers]({{site.baseurl}}/docs/pipelines/service-containers/)
24
23
25
-
* As part of your test-step you need to dynamically create new containers (e.g.:[Testcontainers](https://www.testcontainers.org/) library)
24
+
You may have custom use-cases when you need direct access to the Docker Daemon in your steps.
25
+
For example:
26
+
* As part of your test-step you need to dynamically create new containers ([Testcontainers](https://www.testcontainers.org/) library)
26
27
* You need to run a composition and dynamically add to that composition a new container you'll create
27
28
* You need to send specific flags to your docker-build process
28
29
29
-
For all those cases (and any others), you're still able to access the Docker
30
-
Daemon on a step of your build, by providing the correct configuration (and
31
-
under certain circumstances).
30
+
For all custom cases, you can access the Docker Daemon in your pipeline step by providing the correct configuration in`freestyle` and`composition` steps.<!--- and under certain circumstances-->.
32
31
33
-
##Details
32
+
##Direct access to Docker Daemon options
34
33
35
34
There are two main options to access the Docker Daemon in a pipeline step:
35
+
***In a[`freestyle`]({{site.baseurl}}/docs/pipelines/steps/freestyle/) step**: By using an image with Docker installed, and mounting the required volumes (the Docker socket). In Hybrid Runtime Environments, these volumes are already mounted. You don't need to specify anything else.
36
+
***In a[`composition`]({{site.baseurl}}/docs/pipelines/steps/composition/) step**: Similar to the`freestyle` step option, you'll need to use an image with Docker installed in one of the composition-services. And mount the corresponding volumes to that composition-service.
36
37
37
-
***In a[freestyle]({{site.baseurl}}/docs/pipelines/steps/freestyle/) step**: using an image with Docker installed, and mounting the required volumes (the Docker socket). In Hybrid REs, these volumes are already mounted. You don't need to specify anything else.
38
-
***In a[composition]({{site.baseurl}}/docs/pipelines/steps/composition/) step**: same as with the freestyle option, you'll need to use an image with Docker installed in one of the composition-services. Also, you'll need to mount the corresponding volumes to that composition-service
38
+
The following sections provide details on how to use each of the options.
39
39
40
-
In the following sections, we'll provide details on how to use each of the
41
-
options described above.
40
+
###Accessing the Docker Daemon in a`freestyle` step
42
41
43
-
###Accessing the Docker Daemon in a freestyle step
44
-
45
-
The following snippet shows a step using this approach:
42
+
The following snippet shows an example of how to access the Docker Daemon in a`freestyle` step:
46
43
47
44
```yaml
48
45
docker_daemon_access:
@@ -54,15 +51,18 @@ docker_daemon_access:
54
51
-docker build -t your/image -f yourDockerfile .
55
52
```
56
53
57
-
> **Note 1** : By default, and for security reasons, the Docker Daemon is not exposed to freestyle steps running on our SaaS environments. In other words, this approach **cannot** be used in our SaaS Runtime Environments.
58
-
>
59
-
> **Note 2** : There's still a way to use this approach in a RE **hosted by Codefresh**. For this option, you'll need a **dedicated Runtime Environment**.
60
-
>
61
-
> **Note 3** : This approach is **usable by default in Hybrid REs** (i.e.: Codefresh Runner REs). Since the REs is running in your infrastructure, access to the Docker Daemon in a freestyle step is enabled by default
54
+
* Hybrid Runtime Environments (REs)
55
+
In Hybrid REs with the Codefresh Runner, this is the default approach to access the Docker Daemon.
56
+
Since the REs run in your infrastructure, access to the Docker Daemon in a`freestyle` step is enabled by default.
57
+
* SaaS REs
58
+
SaaS REs do not support this approach as the Docker Daemon is not exposed to `freestyle` steps by default for security reasons.
59
+
You can still use the RE **hosted by Codefresh**. For this option, you'll need a **dedicated Runtime Environment**.
60
+
61
+
62
62
63
63
### Accessing the Docker Daemon in a composition step
64
64
65
-
The following snippet showsa step using this approach:
65
+
The following snippet showsan example of how to access the Docker Daemon in a `composition` step:
66
66
67
67
{% raw %}
68
68
@@ -92,9 +92,13 @@ docker_daemon_access:
92
92
93
93
{% endraw %}
94
94
95
-
> **Note 1** : This approach can be used in On-Prem out-of-the-box
96
-
>
97
-
> **Note 2** : Docker socket mapping in composition can only be provided to customers that have **all** concurrency in **Hybrid REs** , or, in a **dedicated cluster** (provided by Codefresh)
95
+
* On-premises
96
+
This approach is supported out-of-the-box in on-premises environments.
97
+
98
+
99
+
* Hybrid REs
100
+
Docker socket mapping in `composition` is supported only when the concurrency is set to **all**, or in a **dedicated cluster** provided by Codefresh.
101
+
98
102
99
103
A similar implementation can be achieved using **[Service Containers]({{site.baseurl}}/docs/pipelines/service-containers/)**:
> As mentioned at the beginning of this article, Codefresh covers the general cases where access to the Docker Daemon is required (building a Docker image, pushing a Docker image, etc). For all these common cases **we encourage you to keep using our native steps**. Since they'll provide different levels of optimization (e.g.: Codefresh-cache mechanism), also their usage is directly related to the level of traceability you will get (e.g.: the images you build in Codefresh using our docker-build step will be reflected in the images view and other dashboards we provide).
124
-
>
125
-
> This way of directly accessing the Docker Dameon should be **exclusively used for very specific use-cases.**
125
+
{{site.data.callout.callout_tip}}
126
+
We encourage you to keep using our built-in steps as they cover almost all common use cases for access to the Docker Daemon.
127
+
128
+
Because the built-in steps support different levels of optimization, such as the Codefresh caching mechanism, their usage is directly related to the level of traceability. For example, the images you build in Codefresh using the `build` step are reflected in the images view and other dashboards we provide.
129
+
130
+
Reserve directly accessing the Docker Dameon **for very specific use-cases.**
131
+
132
+
126
133
127
134
## Related Items
135
+
[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/)
136
+
[Caching in pipelines]({{site.baseurl}}/docs/pipelines/pipeline-caching/)