add hub-dashboard as a poster #3
Conversation
project-posters/hub-dashboard.md
Outdated
| - be customizable wrt to theme | ||
| - automatically be built when a modeling round closes | ||
| - be built on demand | ||
| - does not require knowledge of anything more than Markdown or YAML |
There was a problem hiding this comment.
I think this aspect of scoping is still an open question for me. Would we be ok with requiring the ability to run and update github actions? This is something that we ask hub admins to do elsewhere in the hubverse, so the question may be a broader one than just this project.
There was a problem hiding this comment.
Executive Summary
I think that's a fair assessment, and the discussion is a bit broader scope than this particular project. The app and the distributed workflows are not mutually exclusive options. The way we currently operate still requires a fair bit of effort. The app was designed as a kind of stretch goal to satisfy the fact that the CDC folks did not have the capacity to maintain yet another site.
Broader Description
My take on this is that providing a standard set of GitHub actions still requires maintenance on our part and it really depends on the service level hub admins will expect from the core developers.
There are a few models that exist for this, each with decreasing technical expertise required for users:
- GitHub actions or reusable workflows and require admins to build their own workflows.
- GitHub workflows and require admins to be aware of updates and update accordingly.
- GitHub workflows and provide help to admins who need it.
- GitHub app that triggers centralized workflow.
For example, r-lib/actions is primarily strategy 1 and secondarily strategy 2.
Our current strategy with the hubs is pretty firmly in strategy 3, but not everyone gets the message to update (think about how many emails you and Nick must field per day) which causes problems that require extra effort on everyone's part (e.g. the recent ubuntu kerfuffle leading to cdcepi/FluSight-forecast-hub#1251). I've had plenty of experience with this strategy and I find it even more taxing than any of the other strategies because it's so hard to make sure that everyone is up-to-date. I actually continue to get notifications from The Carpentries that workflows have failed because I was the last one to update them.
I still haven't been able to describe it well enough, but the way I am envisioning the hub dashboard orchestration working is that an app and a workflow are not mutually exclusive. If we provide re-usable workflows (strategy 1) AND provide example workflows (strategy 2), then hub admins who are comfortable with GitHub workflows can use those to build their dashboard websites.
However, given the desire to not require yet another set of workflows to maintain, the app can be an optional step in to fill that role (as long as we label that as beta).
Co-authored-by: Evan Ray <[email protected]>
This is in response to Evan's comment https://github.com/reichlab/decisions/pull/3/files#r1884044684
| ```mermaid | ||
| sequenceDiagram | ||
| participant GitHub | ||
|
|
||
| create participant dash as dashboard repository | ||
| GitHub-->>dash: fetch dashboard repoisotry | ||
| Note over GitHub: Builds static site to site/ | ||
| GitHub-->>dash: Read hub repository name from config | ||
| dash->>GitHub: Hub Repository: "hub-repo" | ||
| create participant hub as hub repository | ||
| GitHub-->>hub: fetch "hub-repo" | ||
| Note over GitHub: Builds Predtimechart data to data/ | ||
| GitHub->>dash: Push site/ to gh-pages | ||
| GitHub->>dash: Push data/ to ptc/data | ||
| ``` |
There was a problem hiding this comment.
I'm not an expert on how to build diagrams, but should the dashed arrows that are pointing right be pointing left to indicate they are pulling resources from the "dashboard repository" to GitHub?
There was a problem hiding this comment.
I'm honestly not sure the best way to do this either. I want to indicate that GitHub is issuing the request to fetch the repository.
zkamvar
dismissed
elray1’s stale review
This has been discussed at length and is required for the other PRs to go through.
Since this is a project poster, it can continue to be edited.
No description provided.