manifest: add jenkins-stg-agent-base.yaml due to staging limitations

Added jenkins-stg-agent-base.yaml to work around limitations in the
Staging environment.  Also updated documentation to note the
unreliability of the Staging registry and instructed users to use their
own agent image.

Signed-off-by: Renata Ravanelli <[email protected]>

Author: ravanelli

HACKING.md

@@ -532,7 +532,8 @@ using a development cluster, it normally isn't, and you can drop it. For
 the Fedora prod cluster, use `ocs-storagecluster-ceph-rbd` as shown
 above.
 
-If using an additional root CA certificate, then you will also need to
+If using an additional root CA certificate, or working with Fedora staging
+pipeline, then you will also need to
 specify the `AGENT_NAMESPACE` parameter to yours, e.g.:
 
 ```
@@ -594,6 +595,16 @@ oc start-build --follow jenkins-with-cert
 oc start-build --follow jenkins-agent-base-with-cert
 ```
 
+If you're working with the Staging environment, keep in mind that the registry
+is not well maintained. This can lead to issues due to mismatched agent images.
+To avoid problems, let's use our own image instead. Make sure you’re in the
+manifest directory and set the AGENT_NAMESPACE to your current namespace (not
+openshift) when creating the Jenkins instance, as shown above.
+
+```
+oc apply -f jenkins-stg-agent-base.yaml
+```
+
 We can now start an S2I build of the Jenkins controller:
 
 ```

manifests/jenkins-stg-agent-base.yaml

@@ -0,0 +1,16 @@
+kind: ImageStream
+metadata:
+  name: jenkins-agent-base
+spec:
+  lookupPolicy:
+    local: true
+  tags:
+    - name: latest
+      from:
+        kind: DockerImage
+        name: registry.redhat.io/ocp-tools-4/jenkins-agent-base-rhel8:v4.13.0
+      forcePull: true
+      importPolicy:
+        scheduled: true
+      referencePolicy:
+        type: Source