chore: add some section headings

_posts/2024-08-06-macos-large-runners.markdown

@@ -13,7 +13,8 @@ have a considerable higher amount of processors / memory and disk space allocate
 This advantage comes at a cost though, as billing per minute of executed workflow time is considerably higher as compared to normal runners (see [billing for runners](https://docs.github.com/en/billing/managing-billing-for-github-actions/about-billing-for-github-actions)), 
 on top of the usual minute multiplier for macOS runners (each minute of executed workflow time on a macOS runner counts as 10 minutes for billing purposes).
 
-<br/>
+### Going to speed up
+
 In order to use such a `macOS large runner`, you can simply add a `runs-on: <runner-type>` to your job definition, e.g. using `macos-latest-large` as runner type:
 
 {% highlight yaml %}
@@ -31,18 +32,24 @@ jobs:
 {% endhighlight %}
 
 <br/>
-Additionally, your organization needs to have a `GitHub Team` or `GitHub Enterprise Cloud` plan to be able to use such a `macOS large runner` (which is now the case for all Eclipse projects hosted on GitHub as of 2024), otherwise workflows using such a runner will fail to run. Once your organization is eligible to use large runners, you probably want to control the access to such runners for the repositories in your organization
-to avoid surprises when you receive your next invoice. GitHub offers a convenient way to define [runner groups](https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/controlling-access-to-larger-runners) to control which repositories can access such large runners.
+Additionally, your organization needs to have a `GitHub Team` or `GitHub Enterprise Cloud` plan to be able to use such a `macOS large runner` 
+(which is now the case for all Eclipse projects hosted on GitHub as of 2024), otherwise workflows using such a runner will fail to run. 
+Once your organization is eligible to use large runners, you probably want to control the access to such runners for the repositories in your organization
+to avoid surprises when you receive your next invoice. 
+GitHub offers a convenient way to define [runner groups](https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/controlling-access-to-larger-runners) 
+to control which repositories can access such large runners.
+
+### What the ...
 
-<br/>
 Unfortunately, such runner groups can only be defined for `linux` and `windows` runners, there is simply no way to prevent that `macOS large runners` are being used by any of your repositories once their use is configured in a workflow as described above. 
 This poses a problem for non-profit organizations (like the [Eclipse Foundation](https://www.eclipse.org)) that host a lot of projects and their associated repositories on GitHub as it might result in higher than expected billing expenses as some projects try using such large runners
 to speed up their workflows without realizing the consequences.
 
 <br/>
 While it is possible to monitor the incurred costs of using GitHub Action minutes, this is a tedious and manual task and requires communication with projects to change their workflows if occurrences have been identified.
 
-<br/>
+### Gaming the system
+
 The idea was born to add some automation to prevent the execution of workflows on such `macOS large runners` unless the project / repository is entitled to use such a runner.
 
 <br/>
@@ -55,7 +62,8 @@ After studying the available [GitHub Rest API](https://docs.github.com/en/rest?a
 <br/>
 To receive the necessary webhook events from GitHub in case a workflow is being queued to run, you have to set up an organization or repository webhook, listen for the event and apply the logic. 
 
-<br/>
+### All good
+
 At the [Eclipse Foundation](https://www.eclipse.org) we are operating an open-source project called [Otterdog](https://github.com/eclipse-csi/otterdog) in order to configure our numerous organizations and repositories hosted on GitHub at scale.
 This tool is effectively a GitHub App and is installed for all our projects / organizations on GitHub and already can listen to various events sent from GitHub. So naturally we added the above logic to this tool and allowed to define 
 which organizations are allowed to use such large runners via a configuration file (see [this](https://github.com/eclipse-tractusx/.eclipsefdn/blob/main/otterdog/policies/macos_large_runners.yml) example).