public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
* [pve-devel] PVE development environment
@ 2021-01-07 15:17 Gilles Pietri
  2021-01-07 16:01 ` Stefan Reiter
  2021-01-11  7:52 ` aderumier
  0 siblings, 2 replies; 3+ messages in thread
From: Gilles Pietri @ 2021-01-07 15:17 UTC (permalink / raw)
  To: pve-devel


[-- Attachment #1.1: Type: text/plain, Size: 1879 bytes --]

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.

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!

Cheers,

Gilou



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [pve-devel] PVE development environment
  2021-01-07 15:17 [pve-devel] PVE development environment Gilles Pietri
@ 2021-01-07 16:01 ` Stefan Reiter
  2021-01-11  7:52 ` aderumier
  1 sibling, 0 replies; 3+ messages in thread
From: Stefan Reiter @ 2021-01-07 16:01 UTC (permalink / raw)
  To: Proxmox VE development discussion, Gilles Pietri

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
>




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [pve-devel] PVE development environment
  2021-01-07 15:17 [pve-devel] PVE development environment Gilles Pietri
  2021-01-07 16:01 ` Stefan Reiter
@ 2021-01-11  7:52 ` aderumier
  1 sibling, 0 replies; 3+ messages in thread
From: aderumier @ 2021-01-11  7:52 UTC (permalink / raw)
  To: Proxmox VE development discussion

Hi! (Great to see a new French contributor ^_^ )

Personnaly,

I'm coding directly on a remote proxmox dev server with vim through ssh

I'm pulling packages from pvetest repository to try to get the almost
last version without need to build them.

I'm pulling the master branch of the package I want to edit,

make the deb

and if some dependencies need to be updated (because they are too old
in pvetest), I'm rebuilding them. 

I just need time to time rebuild the depend or update them through
pvetest repo, but not so much.


Alexandre


Le jeudi 07 janvier 2021 à 16:17 +0100, Gilles Pietri a écrit :
> 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.
> 
> 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!
> 
> Cheers,
> 
> Gilou
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-01-11  7:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-07 15:17 [pve-devel] PVE development environment Gilles Pietri
2021-01-07 16:01 ` Stefan Reiter
2021-01-11  7:52 ` aderumier

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal