Diagrams

[javierdelapuente]

Applicable spec:

Overview

C4 Diagrams for github-runner operator.

Rationale

Juju Events Changes

Module Changes

Library Changes

Checklist

• The charm style guide was applied.
• The contributing guide was applied.
• The changes are compliant with ISD054 - Managing Charm Complexity
• The documentation for charmhub is updated.
• The PR is tagged with appropriate label (urgent, trivial, complex).
• The changelog is updated with changes that affects the users of the charm.

[github-actions]

Test coverage for 697fbcc

Name                 Stmts   Miss Branch BrPart  Cover   Missing
----------------------------------------------------------------
src/charm.py           329     78     46      9    72%   266-268, 286-292, 307-308, 327-328, 343, 345, 347, 353-356, 380, 393-395, 417-418, 430-431, 454-455, 465, 514-516, 521-530, 586-619, 633-638, 653-696, 704-705, 727
src/charm_state.py     336     16     62      4    93%   220-232, 432-436, 519-520, 822->exit, 825->828, 832-833, 870-871
src/errors.py           13      0      0      0   100%
src/event_timer.py      52      6      0      0    88%   105-106, 143-144, 160-161
src/logrotate.py        43      0      2      0   100%
src/utilities.py        25      3      4      1    79%   66-69
----------------------------------------------------------------
TOTAL                  798    103    114     14    84%

Static code analysis report

Run started:2025-01-29 15:36:41.156924

Test results:
  No issues identified.

Code scanned:
  Total lines of code: 1602
  Total lines skipped (#nosec): 2
  Total potential issues skipped due to specifically being disabled (e.g., #nosec BXXX): 3

Run metrics:
  Total issues (by severity):
  	Undefined: 0
  	Low: 0
  	Medium: 0
  	High: 0
  Total issues (by confidence):
  	Undefined: 0
  	Low: 0
  	Medium: 0
  	High: 0
Files skipped (0):

[erinecon]

Thanks for adding to the docs! I have a few comments to start with, mostly just to better understand the diagrams.

[erinecon]

I would add a header here, something like ## Overview of the GitHub runner ecosystem. Feel free to change the wording -- I think the heading will set the expectation that this diagram and section will present a high-level overview of the project.

Other options include moving this diagram to the main index.md page, the README, or both. I'd appreciate your thoughts about where is the best place for this diagram!

[erinecon]

Based on this description, my impression that the RunnerManager is the main component of the charm. The RunnerManager seems to coordinate all the other components to create, manage, and scale the runners. Please correct me if my impression is wrong!

However, if this is a correct interpretation, then I would rephrase the text to say something like

The `RunnerManager` is the main component of the charm. The `RunnerManager` interacts
with the other charm components in the following ways:
* `RunnerScaler`: To reconcile the desired number of runners.
* `CloudRunnerManager`: To interact with the compute infrastructure to create and manage
  self-hosted runners. OpenStack is currently the only available cloud implementation. 
* `GithubRunnerManager`: To interact with the GitHub API.

[erinecon]

Suggested change

	will be in charge of consuming events that were created from Github webhooks, and starting GitHub runners in a
	will be in charge of consuming events that were created from GitHub webhooks and starting GitHub runners in a

[erinecon]

Is github-runner-webhook-router a charm? It may be better to refer to it as a charm here, let me know what you think

[erinecon]

For my understanding, are these different components (RunnerManager, RunnerScaler, etc.) components of the charm, or the software components? (If there's a difference between those two categories)

The aesthetics of this diagram are a little wonky. If the different components and arrows refuse to cooperate, feel free to change to a different Mermaid syntax.

[javierdelapuente]

Clarifiy that it is a machine charm