ci: debos: upload artifacts to fileserver #4
Conversation
|
This is immediately useful for people that have read access to the fileserver as to download a fresh daily image, or a test image for a pull request. This does beg the question of how we're going to manage the two sector sizes we're trying to support, or rather when. Quick reminder that:
We could:
There's also a side question of generating the other assets needed for flashing, but that is a larger topic. |
.github/workflows/debos.yml
Outdated
| # copy output files | ||
| cp -v disk.img "${dir}" | ||
| # instruct fileserver to publish this directory | ||
| url="${FILESERVER_URL}/${GITHUB_RUN_ID}/" |
There was a problem hiding this comment.
GITHUB_RUN_ID is unique within the repo. We seem to publish builds from this repo at the same level as builds from meta-qcom. that could clash no?
There was a problem hiding this comment.
Ah indeed, I assumed the run ids were globally unique, but the doc says unique per repo.
There's also the case for reruns, so a run id is actually not a unique build id; so we should also use GITHUB_RUN_ATTEMPT to have unique build ids.
There was a problem hiding this comment.
There is no globally unique run id provided by GitHub, so some repo id needs to be used. There is a repository id as a number, and there is the repository name which is the nicest IMO, but it's controller by the submitter of pull request.
I've found some non-official repositories outlining the GitHub user/org naming rules, and these explanations in the GitHub docs about user names:
https://docs.github.com/en/enterprise-cloud@latest/admin/managing-iam/iam-configuration-reference/username-considerations-for-external-authentication
Basically usernames are alphanumeric and can contain hyphens and underscores, but never two hyphens or start with an hyphen, so that should be safe to use in directory names and URLs.
There was a problem hiding this comment.
ugh. i think this is going to wind up forcing a change in backend logic. the code is treating it as unique per github org and not repository. I think we have move to a format:
${FILESERVER_URL}/${GITHUB_REPOSITORY}/${GITHUB_RUN_ID}/
I'll need to deploy something that's temporarily backward compatible while I work through all the places we do uploads.
There was a problem hiding this comment.
n/m - this works well. i like it.
I think we should publish working (and tested) images, so we cannot defer to the user to do the final conversion. We can do either 1 or 2 above, but I would prefer 1. it seems safer, in case debos ends up doing something 'more' with the sector size than what a custom/local script could do. Could debos be split into 2 steps, first to prepare the rootfs, and then to create the image ? so that we 'waste' less?
Right now most of the boot assets , qdl xml files, .. are managed/integrated in meta-qcom, and 'tied' to our Yocto builds, but it's not ideal. We would like to have them in https://github.com/qualcomm-linux/qcom-ptool instead, so that they are managed independently of meta-qcom. |
Yes, if we want to use debos to do the conversion, then it's a good idea to architect it in two steps.
Is there a place where this is discussed/being spec-ed that I can tune into? |
Create an unique id based on repository, workflow run id, and workflow run attempt. Repository name is under the control of the submitter, but GitHub restricts organization and repository names to safe characters. Signed-off-by: Loïc Minier <[email protected]>
Signed-off-by: Loïc Minier <[email protected]>
We have qualcomm-linux/meta-qcom#714. but really not much was done so far. |
3 participants
No description provided.