mirror of https://github.com/thesofproject/sof.git
README.md: explain how to run SOF tests on new rimage code
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
This commit is contained in:
parent
a9faf85fe5
commit
6e22944e05
74
README.md
74
README.md
|
@ -15,3 +15,77 @@ $ make -C build/ help # lists all targets
|
|||
$ make -C build/
|
||||
$ sudo make -C build/ install # optional
|
||||
```
|
||||
|
||||
## Testing rimage changes with SOF Continuous Integration
|
||||
|
||||
This section is about leveraging SOF validation to test rimage changes
|
||||
_before_ submitting them to the rimage repository.
|
||||
|
||||
Nothing here is actually specific to SOF and rimage; you can apply the
|
||||
same test logic to any submodule and parent on Github. In fact the same
|
||||
logic applies to submodule alternatives. Github is the only requirement.
|
||||
|
||||
### Get familiar with git submodules
|
||||
|
||||
This is unfortunately not optional for SOF and rimage.
|
||||
|
||||
For various reasons submodules seem to confuse many git users. Maybe
|
||||
because the versions of the submodules are not directly visible in some
|
||||
configuration file like with most alternatives? Either way, an
|
||||
unfortunate prerequisite before doing any rimage work is to get familiar
|
||||
with git submodules in general. As submodules are built-in there are
|
||||
many resources about them on the Internet. One possible starting point
|
||||
is https://git-scm.com/book/en/v2/Git-Tools-Submodules but feel free
|
||||
to use any other good tutorial instead. Make sure you actually practice
|
||||
a tutorial; don't just read it. Practicing on a temporary and throw-away
|
||||
copy of SOF + rimage is a great idea.
|
||||
|
||||
Obviously, you also need to be familiar with regular Github pull
|
||||
requests.
|
||||
|
||||
### Run SOF tests on unmerged rimage commits
|
||||
|
||||
First, push the rimage commits you want to be tested to any branch of
|
||||
your rimage fork on Github. Do _not_ submit an rimage pull request yet.
|
||||
|
||||
Then, **pretend** these rimage commits have already been accepted and
|
||||
merged (they have been neither) and submit to SOF a draft pull request
|
||||
that updates the main SOF branch with your brand new rimage commits to
|
||||
test. The only SOF commit in this SOF TEST pull request is an SOF commit
|
||||
that updates the rimage pointer to the SHA of your last rimage
|
||||
commit. If you're not sure how to do this then you must go back to the
|
||||
previous section and practice submodules more.
|
||||
|
||||
Submit this SOF pull request as a Github _draft_ so reviewers are _not_
|
||||
notified. Starting every pull request as a draft is always a good idea
|
||||
but in this case this particular SOF pull request can be especially
|
||||
confusing because it points at commits in a different repo and commits
|
||||
that are not merged yet. So you _really_ don't want to bother busy
|
||||
reviewers (here's a secret: some of the reviewers don't like submodules
|
||||
either). You can freely switch back and forth between draft and ready
|
||||
status and should indeed switch to draft if you forgot at submission
|
||||
time but you can never "un-notify" reviewers.
|
||||
|
||||
Github has very good support for submodules and will display your SOF
|
||||
TEST pull request better than what the git command line can show. For
|
||||
instance Github will list your rimage changes directly in the SOF Pull
|
||||
Request. So if something looks unexpected on Github then it means you
|
||||
did something wrong. Stop immediately (except for switching to draft if
|
||||
you forgot) and ask the closest git guru for help.
|
||||
|
||||
Search for "Submodule" in the build logs and make sure the last of your
|
||||
new rimage commits has been checked out.
|
||||
|
||||
Iterate and force-push your rimage branch and your SOF TEST pull request
|
||||
until all the SOF tests pass. Then you can submit your rimage pull
|
||||
request as usual. In the comments section of the rimage pull request,
|
||||
point at your test results on the SOF side to impress the rimage
|
||||
reviewers and get your rimage changes merged faster.
|
||||
|
||||
Finally, after your rimage changes have been merged, you can if you want
|
||||
submit one final SOF pull request that points to the final rimage
|
||||
SHA. Or, if your rimage change is not urgently needed, you can just wait
|
||||
for someone else to do it later. If you do it, copy the rimage git log
|
||||
--oneline in the SOF commit message. Find some good (and less good)
|
||||
rimage commit message examples at
|
||||
https://github.com/thesofproject/sof/commits/main/rimage
|
||||
|
|
Loading…
Reference in New Issue