Add documentation on how to enable and interact with the in-cluster gitea server #232
Conversation
jordigilh
force-pushed
the
add_gitea_incluster
branch
from
1ea2ca4 to
b824a20
Compare
…itea server in-cluster
jordigilh
force-pushed
the
add_gitea_incluster
branch
from
b824a20 to
1200064
Compare
|
Hi @jordigilh, thank you for this PR. I looked at the PR preview and observed that the code blocks are a bit off (text is running out of the the block). I'll take a look at it later today. |
Hi @jordigilh , I cloned your PR and built the preview locally and seems to be building fine i.e without the text in codeblocks running out of the block. I think the issue might be with the PR preview, which can sometimes mess rendering. |
There was a problem hiding this comment.
Hi @jordigilh,
I added a few comments based on Red Hat style and consistency guidelines.
For now, this seems good to merge, but expect more changes to the content when we convert to Asciidoc and review it more closely.
Let me know if you have questions.
Thanks,
Avani
|
|
||
| [](/images/operator/enable-in-cluster-fork.png)) | ||
|
|
||
| To enable the in cluster fork, extend the `gitSpec` section in the pattern and tick the `useInClusterFork` checkbox. During the reconciliation loop, the operator will deploy a Gitea server, if none exists already, and fork the repository defined in the `target Repo` and `target Revision` onto the Gitea instance. Then it will use the newly forked repository as the source URL in the argoCD application. The URL of the newly created repository will be captured in the `Pattern` Status section, under the `inClusterRepo` field. |
There was a problem hiding this comment.
Just FYI, we are in the process of converting all our content from Markdown to Asciidoc. When I convert the content for the Validated Patterns Opeartor, this section will become a procedure with steps to complete the procedure and with a step to verify if it was successful.
| To enable the in cluster fork, extend the `gitSpec` section in the pattern and tick the `useInClusterFork` checkbox. During the reconciliation loop, the operator will deploy a Gitea server, if none exists already, and fork the repository defined in the `target Repo` and `target Revision` onto the Gitea instance. Then it will use the newly forked repository as the source URL in the argoCD application. The URL of the newly created repository will be captured in the `Pattern` Status section, under the `inClusterRepo` field. | |
| To enable the in-cluster fork, extend the `gitSpec` section in the pattern and select the `useInClusterFork` checkbox. During the reconciliation loop, the operator deploys a Gitea server, if none exists already, and fork the repository that is defined in the `target Repo` and `target Revision` onto the Gitea instance. Then it will use the newly forked repository as the source URL in the Argo CD application. The URL of the newly created repository will be captured in the `Pattern` Status section, under the `inClusterRepo` field. |
|
|
||
| ## Using the in-cluster Gitea server | ||
|
|
||
| The operator supports the ability to host a forked version of the pattern inside the cluster. This means you don't need to fork the pattern repository before deploying it in your cluster to be able to tweak while you work on it. This can be useful if you don't want to host the forked repository outside the cluster, or for a quick demo. |
There was a problem hiding this comment.
| The operator supports the ability to host a forked version of the pattern inside the cluster. This means you don't need to fork the pattern repository before deploying it in your cluster to be able to tweak while you work on it. This can be useful if you don't want to host the forked repository outside the cluster, or for a quick demo. | |
| The operator supports the ability to host a forked version of the pattern inside the cluster. This means you do not need to fork the pattern repository before deploying it in your cluster to be able to tweak while you work on it. This can be useful if you do not want to host the forked repository outside the cluster, or for a quick demo. |
| ... | ||
| ``` | ||
|
|
||
| At this point we're ready to clone the repository locally: |
There was a problem hiding this comment.
| At this point we're ready to clone the repository locally: | |
| At this point, we are ready to clone the repository locally: |
| Resolving deltas: 100% (3658/3658), done. | ||
| ``` | ||
|
|
||
| Before pushing changes to the repository, we'll need to extract the user credentials that are found in the `gitea` namespace, under the `gitea-user-credentials` secret: |
There was a problem hiding this comment.
| Before pushing changes to the repository, we'll need to extract the user credentials that are found in the `gitea` namespace, under the `gitea-user-credentials` secret: | |
| Before pushing changes to the repository, we must extract the user credentials that are found in the `gitea` namespace, under the `gitea-user-credentials` secret: |
| 0a4e3bf..ff79b6b main -> main | ||
| ``` | ||
|
|
||
| The gitops server will detect the newly applied changes and reconcile the pattern accordingly. |
There was a problem hiding this comment.
| The gitops server will detect the newly applied changes and reconcile the pattern accordingly. | |
| The GitOps server will detect the newly applied changes and reconcile the pattern accordingly. |
|
@abhatt-rh you going to merge this? |
Hi @ipbabble Thank you for checking on this one. Once the review comments are implemented, we can get this merged. @jordigilh Can you PTAL? |
|
We cannot merge this before validatedpatterns/patterns-operator#50 lands |
Thank you for the context, @mbaldessari . In that case, I'll add the |
Extend the operator documentation to detail how to enable and interact with the in-cluster Gitea server.
@abhatt-rh PTAL