New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug:1727727] Build+Packaging Automation #46
Comments
Time: 20190710T06:18:28 |
Time: 20190710T06:18:51 |
Time: 20190710T06:19:14 |
Time: 20190725T11:41:34 The requirements from the infra side are:
The scripts are available at: Will send the package.sh script as a patch to build-jobs once the keys to login are available. |
Time: 20190725T12:42:08
They are not reachable. You probably need four new build machines in Jenkins: Debian stretch/9, buster/10, and bullseye/11; and Ubuntu bionic/18.04. The debian boxes need lots of disk space, the ubuntu needs slightly less as packages aren't actually built on it, it sends them to Launchpad to build. The machines must be secure as they will, by necessity, have to have gpg private keys that are used to sign the packages installed on them. The machines should be apt update + apt upgraded periodically. There's a small amount of pbuilder setup (see the ~glusterpackager/HOWTO file on the current builders in the lab) that should be updated periodically as well. |
Time: 20190725T13:32:25 Also, I would prefer a separate step to sign, so we can run that on a separate server that the one where stuff are being built. And yes, we are not going to build stuff in the lab, we can't ssh there. |
Time: 20190729T06:57:50 About signing, is it fine if we get the password to the machines as a parameter from the person who triggers the jenkins' job and proceed with it to sign in? @kaleb, I wanted to ask about the steps for the initial environment setup. Thanks for informing about it, will look into it once the machines are available. Thanks, |
Time: 20190729T07:54:17 About the password, we can also just store the key on a emulated smartcard on the builder side, and use a password stored on the builder. Therefore, no one will have to type it or share it, and it can't be copied. And that permit automated setup. |
Time: 20190806T10:38:09 Can you please create the machines as mentioned above, so we can setup them up? |
Time: 20190820T12:27:26 I do expect the setup be done with ansible, using our playbooks, and not give direct access to people (because experience showed that when people have a way to bypass automation, they do bypass it sooner or later, causing us trouble later). So far, the only patch I found is https://review.gluster.org/#/c/build-jobs/+/23172/ which is not exactly something that should be merged, since that's a job that do replicate the work of jenkins. I kinda do expect a job that just run generic-package.sh on the builder, and that's it. |
Time: 20190822T09:24:54 these two steps are the ones necessary as of now:
And for the first time we need to do this: First time create the /var/cache/pbuilder/base.tgzon debian: sudo pbuilder create --distribution wheezy --mirrorftp://ftp.us.debian.org/debian/ --debootstrapopts on raspbian: sudo pbuilder create --distribution wheezy --mirrorhttp://archive.raspbian.org/raspbian/ --debootstrapopts NOTE: The reason to go for the above two level implementation was, I wasn't aware of how to make the Like stretch has to be run on rhs-vm-16.storage-dev.lab.eng.bOS.redhat.com(which will be one of the jenkins debian slaves) |
Time: 20190822T10:17:30 As for running different job running on specific machine, that's indeed pretty annoying on jenkins. I do not have enough experience with jjb, but JobTemplate is likely something that would help for that: But afaik, gluster is not dependent on the kernel, so building that with pbuilder in a chroot should be sufficient no matter what Debian, as long as it is a up to date one, no ? |
Time: 20190822T10:30:41
Forgot to mention that this script file is also necessary:
Will look into it. I'm new to writing jobs for jenkins.
Yes, gluster is not dependent on kernel, but I'm unaware of using chroot |
Time: 20190822T10:42:48 |
Time: 20190822T13:03:06 And for the pbuilder cache, I would need to know the exact matrix of distribution we want to build and how. That part seems not too hard: And if we aim to build on unstable, we also may need to do some work to keep the chroot updated (same for stable in fact). |
Time: 20190822T13:14:29 We are currently building for stretch/9, buster/10, and bullseye/unstable/11. AFAIK the buildroot should be updated periodically for all of them; bullseye/unstable should probably be updated more frequently than the others. I don't know anything about pbuilder apart from what I mentioned above, and specifically I don't know anything about how to use pbuilder to build for different distributions on a single machine. I've been using separate stretch, buster, and bullseye installs on dedicated boxes to build the packages for that release of Debian. |
Time: 20190822T13:25:49
The keys that we've been using were generated on an internal machine and distributed to the build machines, which are all internal as well. We were using a new, different key for every major version through 4.1, but some people complained about that, so for 5.x, 6.x, and now 7.x we have been using the same key. As 4.1 is about to reach EOL that essentially means we are only using a single key now for all the packages we build. AFAIK people expect the packages to be signed. And best practices suggests to me that they must be signed. Given that 7.0rc0 is now out and packages will be signed with the current key, that suggests to me that we must keep using that key for the life of 7.x. We can certainly create a new key for 8.x, when that rolls around. And yes, we need a secure way to get the private key onto the jenkins build machines somehow. |
Time: 20190822T13:57:49
The above mentioned file is sent as a patch at: https://review.gluster.org/#/c/build-jobs/+/23289
|
Time: 20200127T16:28:55
That's for infra team, we will add that on https://github.com/gluster/gluster.org_ansible_configuration/tree/master/roles/debian_package_builder/tasks |
Time: 20200219T10:12:21 |
URL: https://bugzilla.redhat.com/1727727
Creator: spamecha at redhat
Time: 20190708T04:40:25
Description of problem:
Currently for every release, packages for Debian(9 & 10) and Ubuntu(bionic,cosmic,eoan,disco,xenial) need to be built manually. To automate this process in the same way as fedora and centos are triggered.
The text was updated successfully, but these errors were encountered: