search

AMDESE / AMDSEV

AMD Secure Encrypted Virtualization
272 stars 84 forks source link

`stable-commits` are not stable #194

Open dreemkiller opened 8 months ago

dreemkiller commented 8 months ago

This repo works with a number of other repos (https://github.com/AMDESE/qemu/, https://github.com/AMDESE/linux, https://github.com/AMDESE/sev-guest) in order to complete a build.

You seem to have set up a system using the stable-commits file to mark the commits to use for a consistent build. However, those stable-commits are not commits, but branches, and those branches are changing. This is creating considerable problems for me when attempting to duplicate my work in any consistent fashion.

As an example of some of the problems I'm seeing, the sev-guest repo currently seems to be out of date in respect to snp-latest on https://github.com/AMDESE/linux, meaning that I cannot build it against that branch (I have to use a specific commit from the branch).

Additionally, even if I were to "set a flag in the ground" and modify the build scripts to use a specific commit (which I have been trying to do), some of the repos (apparently https://github.com/AMDESE/qemu/ at least) seem to be rebasing and pushing with --force, erasing the history that I'm relying on.

Am I doing something wrong? Is there a technique that your team uses to solve these problems that I am missing?

dreemkiller commented 8 months ago

One thing I left out: I am working on SEV-SNP, so I am referring to how to use the snp-latest branch effectively.

mdroth commented 8 months ago

For snp-latest build scripts, there was a recent addition to log the stable-commits and git hashes that were used to build a particular package. They are located in the top-level of the tarball:

~/AMDSEV/snp-release-2023-10-15$ ls source-* source-commit.kernel.guest source-commit.kernel.host source-commit.ovmf source-commit.qemu source-config

In general, providing a simple way to build the latest dev branches, test, and report failures back through this repo's issue tracker is the main intended flow. If you're want more control over what branches/commits a particular build should correspond to, then you should create a local clone of the repositories in stable-commits, and modify stable-commits to point to those repos / branches instead. This is what we do internally.