From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 6EACD6664F for ; Thu, 7 Jan 2021 17:01:45 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5CD441F011 for ; Thu, 7 Jan 2021 17:01:15 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 7E2A11F006 for ; Thu, 7 Jan 2021 17:01:14 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4327745774; Thu, 7 Jan 2021 17:01:14 +0100 (CET) To: Proxmox VE development discussion , Gilles Pietri References: <1ceff1ea-4a30-1412-695f-0ae908908aa0@gilouweb.com> From: Stefan Reiter Message-ID: <439a7035-dd1a-5b1f-499a-b48623d10454@proxmox.com> Date: Thu, 7 Jan 2021 17:01:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1ceff1ea-4a30-1412-695f-0ae908908aa0@gilouweb.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.093 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.267 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] PVE development environment X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 16:01:45 -0000 On 07/01/2021 16:17, Gilles Pietri wrote: > Hi, > > Sorry if this doesn't belong here, point me in the right direction if > there is one ;) > > I read extensively what's there, and that is very helpful: > https://pve.proxmox.com/wiki/Developer_Documentation > I also read the thread here: I read also > https://lists.proxmox.com/pipermail/pve-devel/2018-August/033448.html > but that deals more with the repos than the actual dev env. > That mail seems to a bit misguided in general... You do need these packages, but not the source, you just have to have them installed via APT. You only need the code for the package(s) you want to edit. > Now I wonder, this all assumes you work directly on the test setup, > patch and code from there, and I'm not a big fan of this, for many reasons… > > I usually do write code on my own station, that can access various test > setups that I can spawn, be it in virtualbox, test installs of proxmox > or nested ones for actual qemu tests. My question is, how do you guys do > it, if there are any consensual setups? > > I wondered about different possibilities, tested some: > - coding, versionning on a test environment: I don't like that: I need > to maintain a test environment that includes the coding tools, and it > will break, again and again, and not be in a reliable state, should I > need to debug something. > - compiling locally, having the debian and proxmox tooling, but that is > not a happy solution, as I don't run Debian 10 or proxmox on my machine > - using a set of hooks in git, mirroring stuff to a test instance, and > compiling the packages there, rebooting as needed, that is easy enough, > but I need to factor the dev environment > - using a CI system to handle that on my branches/remotes, namely > gitlab-ci with a runner on a pvetest instance, assetting the .debs, > deploying them… that feels a bit overkill, but… well, I might like that > more, but maybe we could have a lighter way there. > > So, if I'm dumb and there's an obvious choice, just tell me ;) > If not, I'd love to hear about how you guys do it, and if we could make > suggestions for that! > No obvious choice, everyone here also mostly has their own way of doing things. The "usual" workflow is having a PVE installed locally with a desktop environment and using that to work and build packages. Our build system is designed to run on a PVE install, there's not really a way around that (that's debian packaging in general) - i.e. your second option. On non-PVE workstations I personally like to set up a VM (or use a different machine via SSH) and either edit files directly in there or work on the host and have the folder mounted in via virtiofs, sshfs or what have you, so I can build inside the VM. If you need a clean test environment separate from that: Second VM, copy the deb files generated by 'make deb' over and test there. Easily scriptable as well :) Hope that helped somewhat, ~ Stefan > Cheers, > > Gilou >