-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding Enabling hermetic builds #23
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,65 @@ | ||
= Enabling hermetic builds | ||
= Enabling hermetic builds | ||
|
||
A hermetic build is a secure, self-contained build process that doesn't depend on anything outside of the build environment. This means that it does not have network access, is not vulnerable to external influences, and cannot fetch dependencies at run time. Instead, you must declare all required resources and dependencies in your build definition. | ||
|
||
In {ProductName}, you can block network access to the build process and run a hermetic build by setting the `*hermetic*` parameter in your pipeline definition file to `true`. This means that you must fetch all dependencies _before_ the build can start. The following is an example code snippet: | ||
|
||
[source,yaml] | ||
---- | ||
kind: PipelineRun | ||
spec: | ||
params: | ||
... | ||
- name: hermetic | ||
value: "true" | ||
... | ||
---- | ||
|
||
[IMPORTANT] | ||
==== | ||
* Hermetic builds disable network access, so a build with dependencies outside of its Git repository--including supported languages--might fail. To prevent this, or to pull in dependencies from a package manager for one of the xref:how-tos/configuring/prefetching-dependencies.adoc#supported-languages[supported languages], follow the instructions in link:https://konflux-ci.dev/docs/how-tos/configuring/prefetching-dependencies/[Prefetching the package manager dependencies for the hermetic build]. | ||
+ | ||
Similarly, with a link:https://github.com/redhat-appstudio/build-definitions/blob/main/task/buildah/0.1/buildah.yaml[Buildah] task for a non-Java application, when you set the `*hermetic*` parameter to `true`, you’re isolating the build from the network, which restricts it to building only from dependencies listed in your Git repository. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This link is fine for now. |
||
|
||
* Do not add these parameters to the link:https://github.com/burrsutter/partner-catalog-stage/blob/e2ebb05ba8b4e842010710898d555ed3ba687329/.tekton/partner-catalog-stage-wgxd-pull-request.yaml#L87[`**pipelineSpec.params**`] section, as it should always display the default values for hermetic builds. | ||
==== | ||
|
||
.Procedure | ||
|
||
To create a hermetic build for a component, complete the following steps: | ||
|
||
. Go to the `.tekton` directory in your component's repository and find the `.yaml` files related to your `*pull request*` and `*push*` processes. | ||
|
||
. To configure the hermetic pipeline in both the `.yaml` files, add the following hermetic pipeline parameters to the `spec.params` section: | ||
|
||
+ | ||
[source,yaml] | ||
---- | ||
spec: | ||
params: | ||
- ... | ||
- name: hermetic | ||
value: "true" | ||
---- | ||
|
||
+ | ||
. Commit your changes to the component repository and create a pull request. | ||
|
||
. Verify that your build was successful, then merge your pull request. | ||
|
||
.Verification | ||
* From the {ProductName} *Applications* view, go to *Activity > Pipeline runs*. | ||
** Look at the pipeline run with *Build* in the *Type* column and confirm that the `build-container` stage displays a green checkmark. This indicates that the build process successfully fetched all dependencies. | ||
* From the {ProductName} *Applications* view, go to *Activity > Latest commits*. | ||
|
||
.Troubleshooting | ||
If your build fails, be sure to look at your logs: | ||
|
||
In {ProductName}, from the *Applications* view, select the application build you want to troubleshoot, then from the resulting *Overview* page, select the *Activity* tab. From there, under *Activity By*, select *Pipeline runs*. From the *Name* column, select the build whose logs you want to check, then from the resulting *Pipeline run details* view, do one of the following: | ||
|
||
* Select the *Logs* tab. | ||
* Alternatively, you can click *build-container*. When the right panel opens, select the *Logs* tab to see a partial view of the log for that build. | ||
Comment on lines
+55
to
+61
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: This feels like more of a generic troubleshooting help. What would be the best way to organize the troubleshooting? A single place for the entire page? Distributed across pages? "General" guides for each topic section or subsection (i.e. how-to or configuring)? |
||
|
||
== Additional resources | ||
|
||
For more information about the importance of provenance, see link:https://konflux-ci.dev/docs/discover/slsa-conformity/[Supply chain security through SLSA conformity]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Can you add a TODO (even if an href comment that isn't rendered visibly) for the supported languages section or a reminder on the Jira so that we have some reminder of the work needed ?