Skip to content

Commit 2bccd63

Browse files
authored
Merge pull request #190 from brianwcook/auth-prefetch
added information about prefetching RPMs that require a subscription
2 parents 421e094 + d3c129f commit 2bccd63

File tree

1 file changed

+19
-15
lines changed

1 file changed

+19
-15
lines changed

docs/modules/ROOT/pages/how-tos/configuring/activation-keys-subscription.adoc

Lines changed: 19 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
= Using Red Hat activation keys to access subscription content
22

3-
Most Red Hat software requires a subscripition to access. Activation keys are the preferred method for using Red Hat subscriptions with Konflux builds.
3+
Most Red Hat software requires a subscripition to access. Activation keys are the preferred method for using Red Hat subscriptions with Konflux builds and are supported by the all types of container builds, including hermetic builds using the prefetch-dependencies task.
44

55
NOTE: Previously, mounting entitlement certificates directly as secrets was advocated but this is discouraged by Red Hat since those certificates are intended to be regularly revoked and refreshed by the subscription-manager system. Direct use of entitlement certificates is still supported by Konflux but discouraged. Entitlement certificate docs are xref:./entitlement-subscription.adoc[here].
66

@@ -11,25 +11,22 @@ When your activation key is created, you will need to create a secret with two v
1111

1212
== Adding activation keys to the workspace
1313

14-
You will need to create one or more secrets in your Konflux namespace (one per activation key). First, decide what to name the secrets and the scope they should have.
14+
You will need to create one or more secrets in your Konflux namespace (one per activation key). First, decide what to name the secrets and the scope they should have. You can control the scope of the activation key you add with the name.
1515

16-
=== Adding subscription entitlement for an entire workspace or an individual build
16+
=== Adding subscription entitlement for an entire workspace
1717

18-
You can control the scope of the activation key you add with the name. The `+buildah+` tasks expect an activation key with a default name of `+activation-key+`. If you use this name for your secret, all of the builds in your workspace will automatically use the activation key.
18+
Both the `+buildah+` and `+prefetch-dependencies+` tasks accept an activation key with a default name of `+activation-key+`. If you use this name for your secret, all of the builds in your workspace will automatically use the activation key.
1919

20-
Sometimes, you only want certain builds to have the activation key, particularly when you need to have more than one key with different repository configurations in the same workspace. To do this, just select a different name for the activation key (not `+activation-key+`). Then, add a parameter to your pipeline:
20+
=== Adding subscription entitlement for a specific component build
21+
Sometimes, you only want certain builds to have the activation key, particularly when you need to have more than one key with different repository configurations in the same workspace. To do this, choose a different name for your activation key secret (not `+activation-key+`). Then, add a parameter to your ccomponent's pipeline yaml:
2122

2223
----
2324
- name: ACTIVATION_KEY
24-
value: my-custom-key-name
25+
value: my-secret-name
2526
----
2627

2728
== Create the activation key secrets
2829

29-
. <<Create-activation-key-through-the-UI>>
30-
. <<Create-activation-key-through-console>>
31-
32-
3330
[[Create-activation-key-through-the-UI]]
3431
=== Create activation key secret through the UI
3532

@@ -51,16 +48,23 @@ kubectl create secret generic activation-key -n <your-tenant> --from-literal=org
5148

5249
== Using subscription content in a build
5350

54-
=== Automatic registration
51+
=== Non-hermetic (network connected) builds:
52+
53+
==== Automatic registration
5554

56-
The buildah task will use a provided activation key to register itself with Red Hat subscription manager and moount the necessary credentials so that can be used by the builds.
55+
The buildah task will use a provided activation key to register itself with Red Hat subscription manager and mount the necessary certificates to the build environment. Simply add `+dnf+` or `+yum install+` commands to your Containerfile.
5756

58-
TIP: If your activation key includes more repositories than the defaults add the following command inside your Containerfile in order update repository metadata.
57+
TIP: If your activation key includes more than the default repositories, add the following command inside your Containerfile in order update repository metadata:
5958

6059
----
6160
subscription-manager --refresh
6261
----
6362

64-
=== Explicit registration
63+
==== Explicit registration
64+
65+
If you include a `+subscription-manager register+` command in your Containerfile, automatic registration will be disabled. You can control subscription-manager directly using the normal commands.
66+
67+
=== Hermetic (network isolated) builds:
6568

66-
If you include a `+subscription-manager register+` command in your Containerfile, automatic registration will be disabled. You can control subscription-manager directly using the normal commands.
69+
The prefetch-dependencies task can use an activation key to register and fetch RPMs. All repositories configured for the activation key will be enabled for prefetch.
70+
If the default name was used for the secret (activation-key) no configuration is necessary. Otherwise, provide the ACTIVATION_KEY parameter to the build pipeline as noted above.

0 commit comments

Comments
 (0)