Conversation
experimentations/api/Makefile
Outdated
| .PHONY: serve | ||
|
|
||
| serve: | ||
| podman run \ |
There was a problem hiding this comment.
python3 -m http.server 8080 does the same thing :-)
mwhudson
left a comment
mwhudson
left a comment
There was a problem hiding this comment.
This looks like a good start to me. I guess tomorrow we come up with a cli UI for a few use cases and try to map them onto this API?
experimentations/api/openapi.yaml
Outdated
| get: | ||
| tags: | ||
| - release | ||
| summary: List serials within range |
There was a problem hiding this comment.
Well OK so this opens a few questions:
- does this imply semantics to the content of the serial string? Or does a serial just get associated with the timestamp of when it was created?
- how are the results ordered?
- do we need to handle pagination or anything like that if the list gets too long?
- what happens if the query parameters are missing?
Also, I'm not really sure of the use case of this, if I'm honest. I can see the value of being able to iterate backwards over the last $N serials in some situations but that's not what this seems to be.
There was a problem hiding this comment.
- Yes, there could be some implied semantics if we decide to define a Serial as date+count (
20260330.2). But I don't think this is a must, as long as we keep it associated with its creation time. - I would order them by the time of their creation.
- Good point. Although I don't expect that list to become very long, as the number of Serials is probably less than ~1000 per year (that would require us to have enough space to keep all attached artifacts). Still, pagination should be considered. 👍
- That's not yet defined. I'd say it would probably make sense to reduce this to a fixed default number of the latest Serials, as those are probably the most interesting ones.
The overall idea is that each Serial is the top-level run ID of a build&test pipeline. So the Serial would be the entry point for navigating to the built images and test reports.
There was a problem hiding this comment.
Yes OK this all makes a bit more sense to me, I think. Although if the representation of a serial in the API is just, well, the serial there is no way to find out its creation date I think? I think returning the last $N serials by default is probably a good default.
experimentations/api/openapi.yaml
Outdated
| - CANCELLED | ||
| commitId: | ||
| type: string | ||
| description: Git commit ID of the 'release definitions' repository at the time the Serial was created. |
There was a problem hiding this comment.
This makes so much sense, but how will we find / know the repo this is in? I guess it's part of the overall configuration of the deployment? (I'm imagining a world where we have a deployment for ubuntu but also maybe one for a partner team and one for the public cloud team...)
There was a problem hiding this comment.
Yes, I would put the repo location/URL as part of the deployment/service configuration. It's a general issue that locations/URLs are basically just names that are prone to change. So I would not necessarily make them part of the internal build records nor present those locations as part of the API. We definitely have to take extra care to ensure the proper archival of the repository that holds those release definitions.
There was a problem hiding this comment.
Yeah I guess we have to have a degree of trust that people are not going to act like complete maniacs here.
experimentations/api/openapi.yaml
Outdated
| description: The list of Serials | ||
| items: | ||
| type: string | ||
| /release/serials/{serial}: |
| description: Serial to rerun all failed tasks (and subsequent tasks) | ||
| taskId: | ||
| type: string | ||
| description: Restrict rerun to only specific failed tasks |
There was a problem hiding this comment.
Thanks! This should be a list...
experimentations/api/openapi.yaml
Outdated
| - release | ||
| summary: Schedule recurring releases | ||
| description: TODO | ||
| /builds/{serial}: |
There was a problem hiding this comment.
I guess i would have expected this to be {serial}/builds somehow but well.
There was a problem hiding this comment.
This can be changed :)
experimentations/api/openapi.yaml
Outdated
| schema: | ||
| type: string | ||
| - name: image | ||
| description: Restrict request to given image |
experimentations/api/openapi.yaml
Outdated
| type: string | ||
| responses: | ||
| "200": | ||
| description: Map of image names to build infos |
There was a problem hiding this comment.
Again I think you mean image ids, not names? I guess I don't quite know what an image id is, if it's like a hash type id, i'm a bit surprised a failed build gets an id. Or is it more (despite what the example says) more like an image configuration name, like ubuntu-server-amd64?
There was a problem hiding this comment.
Yes image ID, basically a combination of "Image configuration" and "Platform", an encoded string as a flat representation of the combined entities discussed in RM009.
There was a problem hiding this comment.
OK, I think you need to fix the example in the schema then!
oreiche
force-pushed
the
oreiche/api-draft
branch
from
32aac46 to
d2dad55
Compare
3 participants
No description provided.