prefetching dependencies refactoring #200
Conversation
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
|
I think we could greatly simplify this page if we changed the structure so we have a single initial section describing how to se the
All the rest, can probably be inferred and is described in Cachi2's README. |
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
slimreaper35
force-pushed
the
prefetching
branch
from
2f00c0e to
01c67f9
Compare
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
slimreaper35
force-pushed
the
prefetching
branch
from
01c67f9 to
6022999
Compare
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
slimreaper35
force-pushed
the
prefetching
branch
from
6022999 to
714e944
Compare
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
slimreaper35
force-pushed
the
prefetching
branch
from
714e944 to
3410739
Compare
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
slimreaper35
force-pushed
the
prefetching
branch
from
3410739 to
f4818a0
Compare
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
Signed-off-by: Michal Šoltis <[email protected]>
Each package manager has its own, but the same section about verification of the pipeline run. Let's make it a separate paragraph at the end of the page. Signed-off-by: Michal Šoltis <[email protected]>
Cachi2 documentation is referenced multiple times in the document. At the beginning [1], there is a link to main README.md file which has all references needed for a user. --- [1]: https://github.com/konflux-ci/docs/blob/main/docs/modules/ROOT/pages/how-tos/configuring/prefetching-dependencies.adoc#prefetching-package-manager-dependencies-for-hermetic-builds Signed-off-by: Michal Šoltis <[email protected]>
Signed-off-by: Michal Šoltis <[email protected]>
Signed-off-by: Michal Šoltis <[email protected]>
slimreaper35
force-pushed
the
prefetching
branch
from
f4818a0 to
476bc30
Compare
|
🚀 Preview is available at https://pr-200--konflux-docs.netlify.app |
| . Configure the hermetic pipeline by adding the following parameters in both `.yaml` files: | ||
|
|
||
| + | ||
| [source,yaml] | ||
| ---- | ||
| pipelineSpec: | ||
| params: | ||
| ... | ||
| - name: hermetic | ||
| type: string | ||
| description: Execute the build with network isolation | ||
| default: "true" | ||
| ---- |
There was a problem hiding this comment.
This belongs on the hermetic page, but we can refer to that page.
This was originally split into two pages because each can be done independently. We can still increase the accuracy of the SBOM by prefetching even if the build isn't done in a hermetic mode, right?
| value: '{"type": "<package_manager>", "path": "."}' <1> | ||
| ---- | ||
| NOTE: The prefetch-input parameter specifies the path to the directory of the project. In this example, the `.` indicates the repository root. If you have multiple directories, you can provide the path to those directories in the JSON array format: `[{"type": "<package_manager>", "path": "."}, {"type": "<package_manager>", "path": "subpath/to/the/other/directory"}]`. |
There was a problem hiding this comment.
You have the inline <1> here but are using a NOTE comment instead.
| value: '{"type": "<package_manager>", "path": "."}' <1> | ||
| ---- | ||
| NOTE: The prefetch-input parameter specifies the path to the directory of the project. In this example, the `.` indicates the repository root. If you have multiple directories, you can provide the path to those directories in the JSON array format: `[{"type": "<package_manager>", "path": "."}, {"type": "<package_manager>", "path": "subpath/to/the/other/directory"}]`. |
There was a problem hiding this comment.
It is also possible to use a tekton array, specifying a different package manager configuration per line. Is that more usable? Should we suggest that or at least mention it (it is definitely harder to give an inline example like you did here)?
| ---- | ||
| NOTE: The prefetch-input parameter specifies the path to the directory of the project. In this example, the `.` indicates the repository root. If you have multiple directories, you can provide the path to those directories in the JSON array format: `[{"type": "<package_manager>", "path": "."}, {"type": "<package_manager>", "path": "subpath/to/the/other/directory"}]`. | ||
|
|
||
| . Additionally, pass an extra parameter to the `prefetch-dependencies` task in the `.spec.pipelineSpec.tasks` section to indicate that "dev package managers" should be enabled. |
There was a problem hiding this comment.
This isn't required for all package managers, right?
| - name: dev-package-managers | ||
| value: "true" | ||
| ---- | ||
| NOTE: You won't find `dev-package-managers` as a param on the `prefetch-dependencies` task. You have to add it, and set it to true. This is because Cachi2 hasn't declared stable support for the feature yet. Use it at your own risk. |
There was a problem hiding this comment.
If we think that many Konflux users will leverage this, should we start exposing it to reduce the amount of manual work that needs to be done?
There was a problem hiding this comment.
I think this section should temporarily be nested under the RPM section only (we only need it for RPMs). And then I think the next step is to remove RPM from dev-package-managers.
|
|
||
| == Verification | ||
| * From the {ProductName} *Applications* view, go to *Activity > Pipeline runs*. | ||
| ** Go to the pipeline run with *Build* in the *Type* column and confirm that the `prefetch-dependencies` stage displays a green checkmark. This indicates that the build process successfully fetched all dependencies. |
There was a problem hiding this comment.
Is it possible for the task to show green if input has been provided but not prefetched (i.e. bad configuration which doesn't correspond to a package manager or skipped fetching)?
|
I still think we should get completely rid of the individual package manager sections, unless they're really necessary. I don't think the "Prerequisites" section adds much valeu, and the rest is essentially repetition. This is a rough suggestion on how I see the sections (note that after "Troubleshooting, all sections are in-depth/specific info)
|
|
I like the idea of having some summary/representation of the prefetch configuration in this document but I don't think that we should repeat everything in the Cachi2 documentation. What would you think about having a table with a sample input to the prefetch dependency task for each package manager. We can then have sections later with specific things that need to be done (like enabling the dev package managers, binary file prefetchign, etc.). The table can then point users to the specific documentation for the prefetch elsewhere (i.e. cachi2 docs) and/or the the sections later on the page. |
No description provided.