diff options
Diffstat (limited to 'tutorials/builds.sr.ht')
| -rw-r--r-- | tutorials/builds.sr.ht/github-integration.md | 34 | ||||
| -rw-r--r-- | tutorials/builds.sr.ht/using-build-secrets.md | 3 |
2 files changed, 3 insertions, 34 deletions
diff --git a/tutorials/builds.sr.ht/github-integration.md b/tutorials/builds.sr.ht/github-integration.md index a26806f..c5f4056 100644 --- a/tutorials/builds.sr.ht/github-integration.md +++ b/tutorials/builds.sr.ht/github-integration.md @@ -100,38 +100,9 @@ different names for packages, different distributions of coreutils, and so on. ## Adding these builds to your GitHub repository -Try making a new "mrsh" repository on your GitHub account. Note that forks won't -work — so make sure you make a *new* repository and push the mrsh code to it. -Take a look at the `.builds` directory in mrsh: each of these build manifests -can be submitted on push or pull request by rigging up a dispatch.sr.ht task. +Since 2022-10-01, dispatch.sr.ht is now deprecated. -Go to [dispatch.sr.ht](https://dispatch.sr.ht) and "Configure new task". Pick -"GitHub commits > builds.sr.ht jobs" and click "Add task" for your new mrsh -repository. That's all you have to do! Now let's make a dummy commit and push it -to GitHub to test it out: - - git commit --allow-empty -m "Testing builds.sr.ht" - git push - -Head over to your [builds.sr.ht dashboard](https://builds.sr.ht) and you should -see your build begin momentarily! - -## Testing pull requests on GitHub - -If you want to run your CI against pull requests on GitHub, follow a similar -procedure, but select "GitHub pull requests > builds.sr.ht jobs" instead. Then, -each new pull request that comes into your repo will be built on builds.sr.ht -and the pull request status updated with the build results. - -## Why doesn't my GitHub repo show up? - -There are a couple of limitations: - -- Forks are not supported -- You must have admin access to the repo (test this by trying to add a webhook - through the GitHub UI manually) - -If neither of these are the issue, [write us an email](mailto:sir@cmpwn.com). +See [hottub](https://sr.ht/~emersion/hottub) for third-party integration. --- @@ -144,4 +115,3 @@ Other resources: - [builds.sr.ht user manual](/builds.sr.ht) - [Build manifest reference](/builds.sr.ht/manifest.md) -- [dispatch.sr.ht](/dispatch.sr.ht) diff --git a/tutorials/builds.sr.ht/using-build-secrets.md b/tutorials/builds.sr.ht/using-build-secrets.md index 47e74e8..1907be6 100644 --- a/tutorials/builds.sr.ht/using-build-secrets.md +++ b/tutorials/builds.sr.ht/using-build-secrets.md @@ -89,8 +89,7 @@ The easiest way to control whether or not secrets work in your build is by turning them off via the API: if you set secrets=false in [POST /api/jobs](/builds.sr.ht/api.md#post-apijobs), the secrets will not be resolved. This is automatically done in many places where the build manifest could be -modified by an untrusted party — for example, dispatch.sr.ht disables secrets -when submitting build manifests from GitHub pull requests. +modified by an untrusted party. However, some degree of responsibility lies with you for keeping your secrets secure. Avoid writing build manifests that would print your secrets to the logs, |