forked from toolshed/docs.coopcloud.tech
		
	fixing merge conflict
This commit is contained in:
		| @ -427,6 +427,34 @@ You can pass `--publish` to have `abra` automatically publish those changes. | |||||||
|  |  | ||||||
|     In order to have `abra` publish changes for you automatically, you'll have to have write permissons to the git.coopcloud.tech repository and your account must have a working SSH key configuration. `abra` will use the SSH based URL connection details for Git by automagically creating an `origin-ssh` remote in the repository and pushing to it. |     In order to have `abra` publish changes for you automatically, you'll have to have write permissons to the git.coopcloud.tech repository and your account must have a working SSH key configuration. `abra` will use the SSH based URL connection details for Git by automagically creating an `origin-ssh` remote in the repository and pushing to it. | ||||||
|  |  | ||||||
|  | ## How is I make the catalogue automatically regenerate after new versions are published?  | ||||||
|  |  | ||||||
|  | "I'd like to make it so that whenever I push a new git tag to the | ||||||
|  | [`coop-cloud/rallly` repository](https://git.coopcloud.tech/coop-cloud/rallly) | ||||||
|  | (probably [using `abra recipe | ||||||
|  | release`](#how-do-i-release-a-new-recipe-version)), it automatically does the | ||||||
|  | [recipe catalogue generation steps(#how-do-i-generate-the-recipe-catalogue)" | ||||||
|  |  | ||||||
|  | 1. Check whether tag builds are already trying to run: go to | ||||||
|  |    https://build.coopcloud.tech, search for the recipe name (in this case taking | ||||||
|  |    you to https://build.coopcloud.tech/coop-cloud/rallly/settings). If there are | ||||||
|  |    failing builds, or if you see builds succeeding but catalogue regeneration | ||||||
|  |    doesn't seem to be happening, then either dive in and try and fix it, or ask | ||||||
|  |    for help in [`#coopcloud-tech`](https://matrix.to/#/#coopcloud-tech:autonomic.zone) | ||||||
|  | 2. Otherwise, click "activate repository". You probably want to set the "disable pull | ||||||
|  |    requests" and "disable forks" options; they won't work anyway, but the | ||||||
|  |    failures might be confusing. | ||||||
|  | 3. Make sure there is a `generate recipe catalogue` step in the recipe's | ||||||
|  |    `.drone.yml` -- if there isn't, you can copy [the one from | ||||||
|  |    `coop-cloud/rallly`](https://git.coopcloud.tech/coop-cloud/rallly/src/branch/main/.drone.yml#L24-L38) unchanged. | ||||||
|  | 4. That's it! Now, when you push a new tag, the recipe catalogue will regenerate | ||||||
|  |    automatically. You can test this by re-pushing a tag (e.g. `git push origin | ||||||
|  |    :0.5.0+3.5.1 && git push 0.5.0+3.5.1`) | ||||||
|  |  | ||||||
|  | ## How does automatic catalogue regeneration work? | ||||||
|  |  | ||||||
|  | TODO | ||||||
|  |  | ||||||
| ## How do I enable healthchecks | ## How do I enable healthchecks | ||||||
|  |  | ||||||
| A healthcheck is an important and often overlooked part of the recipe configuration. It is part of the configuration that the runtime uses to figure out if a container is really up-and-running. You can tweak what command to run, how often and how many times to try until you assume the container is not up. | A healthcheck is an important and often overlooked part of the recipe configuration. It is part of the configuration that the runtime uses to figure out if a container is really up-and-running. You can tweak what command to run, how often and how many times to try until you assume the container is not up. | ||||||
|  | |||||||
		Reference in New Issue
	
	Block a user