Replace flex-server by hosting recipe info on GitHub#803
Conversation
|
... and that removes a SPoF, which is always nice :) |
e509dcc to
3f5d583
Compare
|
While I always appreciate the technological economization of any ecosystem by removing weak technological dependencies, such as one operated by a company, and moving to community-accepted conventions, such as foundations or any other kind of common place, how is this PR removing a single point of failure if all it does is replacing |
|
SPoF == servers as you mention, but it's also about the number of people maintaining the server/code. |
|
Does this make sense to have something similar to composer repositories? Where I can add a certain in-house hosted flex recipe server which holds proprietary recipes before looking into the default one? Or is this change exactly this? |
|
@icanhazstring yep, that's what the code does already: define |
|
Nice. Good solution. Thank you 💪 |
ce11020 to
c46af2d
Compare
c46af2d to
c1d2897
Compare
918b166 to
f772c70
Compare
f772c70 to
9c1a3f8
Compare
| private static $DEFAULT_ENDPOINT = 'https://flex.symfony.com'; | ||
| private static $MAX_LENGTH = 1000; | ||
| private const DEFAULT_ENDPOINTS = [ | ||
| 'https://api.github.com/repos/symfony/recipes/contents/index.json?ref=flex/main' => [], |
There was a problem hiding this comment.
@nicolas-grekas would it make sense for backwards compatibility to rename the current main and master branches to 1.x so if there is in future a 2.x release which maybe use another .json format which will not break?
There was a problem hiding this comment.
We're talking about the branch name of recipes. There will be no v2 as there is no v1 either :)
There was a problem hiding this comment.
What @alexander-schranz means I think is: what if we refactor the JSON api in the future? (e.g. another json format to support cool new things)
If we don't version the URL, it means we force all apps to directly upgrade to the latest Flex version or to make all JSON format changes backwards compatible.
There was a problem hiding this comment.
the version would then belong to what's inside the json, not to the URL
I think all is future proof already:
- different format of recipes (eg php-dsl) = new endpoint, eg flex/main replaced by flex/main-php
- new API payloads = new keys in index.json, possibly with a version, but only the day we actually need it imho
There was a problem hiding this comment.
If you are sure there will be no issue with ref to main/master then its good :)
|
If learning this wasn't confusing enough, you now take away the server that made sense? - nice :( |
|
✔️ The service's usage didn't change I can fully understand why this change was made :) |
This PR replaces the
flex.symfony.comendpoint that flex currently uses by a new endpoint made of static JSONs hosted on GitHub.Said JSONs are here:
https://github.com/symfony/recipes/tree/flex/main
And are generated by GHA:
https://github.com/symfony/recipes/blob/master/.github/workflows/flex-endpoint.yml
With the help of this tool:
https://github.com/symfony-tools/recipes-checker
The target is to retire
flex.symfony.comat some point in the future and free us from maintaining and hosting it.As a nice side effect, this should make it easier for ppl to host their own flex endpoint overlay.
It should also enable contributions for the community to innovate at the Flex API layer.
The default endpoints can be changed by setting the
extra.symfony.endpointentry in the rootcomposer.jsonfile. The specialflex://defaultsendpoint can be used in that list to reference the default endpoints.On top of that, the
SYMFONY_ENDPOINTenv var can be defined to a single endpoint. This endpoint will be used on top of (with higher priority than) the default endpoints of the app.