Integrate changes into a release build workspace#68
Open
abinjose-qualcomm wants to merge 3 commits intoqualcomm-linux:mainfrom
Open
Integrate changes into a release build workspace#68abinjose-qualcomm wants to merge 3 commits intoqualcomm-linux:mainfrom
abinjose-qualcomm wants to merge 3 commits intoqualcomm-linux:mainfrom
Conversation
One recommendation to apply PRs in a release build workspace was to pull the changes locally and update the merged commit SHA in the kas lock file. In extended testing, it was found that this approach doesn't always work. kas validates if the commit recorded in the lock file is available on the remote repository, which fails since the merged commits are only available locally. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
When a pull request is integrated into a tagged release using git merge, it may bring in extra commits beyond those intended for the change. To apply only the specific commits associated with the change, use git cherry-pick instead. This ensures that only the intended modifications are included. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
Patches can be applied in a release build workspace and integrated by using the `--skip repos_checkout` flag in the kas commands. This may not be ideal since if the --skip repos_checkout flag is missed, it may mess up the workspace. Instead, we can leverage the concept of forks to integrate changes remotely and follow the same steps as the default workflow. Signed-off-by: Abin Joseph <abinjose@qti.qualcomm.com>
abinjose-qualcomm
force-pushed
the
workspace-setup-with-prs
branch
from
e9c6be4 to
58806b8
Compare
abinjose-qualcomm
requested review from
anshulg-qti,
anujm1,
gkhose-qipl,
ricardosalveti,
sjakki88 and
vkraleti
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem Statement
For every meta-qcom release, a lock file is generated which locks the commits for all the meta layers used in the build. This lock file is used in the build steps to checkout and lock your layers to specific commits. This works well when you need to reproduce a build exactly.
This doesn't work well when you need to apply any changes on top of your release tag.
Applying your changes locally and updating the lock file doesn't work, since the kas lock file validates if the required commit is available on the remote server. One way to circumvent this issue is to apply the
--skip repos_checkoutoption in the kas commands.Proposed Solution
Fork the meta-qcom and meta-qcom-releases repositories and make changes on top of it.
This method is more inline with the standard GitHub fork‑and‑update workflow that most developers are accustomed to.