We don't run Jenkins anymore, so can remove the jenkins-slave scripts.
Depends-On: https://review.openstack.org/#/c/514485
Change-Id: I645e3739d29eec17bc3cf5c4367559a71f456be8
This is chowning /opt/cache/files to jenkins, which I believe is
causing issues for non-devstack-gate jobs that want to access
/opt/cache directly as zuul (for d-g jobs, roles/setup-devstack-cache
handles making a copy of it there, which is why we don't see it there).
Make the cache globally accessible
Change-Id: I711bc5643dbc8f2b674cb2a399989643a993a32e
Users may not want to build images with a cache as it significantly
slows down the build process and results in far larger images. Currently
we don't depend on cache-devstack in the jenkins-slave element for this
reason. Unfortunately we assume cache-devstack was run because we
attempt to link to a directory created by this element.
Update jenkins-slave to only make the link if the cache dir exists to
address this. Users can now make cacheless images quickly and cheaply.
Change-Id: I45ec2fcd614d71f1db85cab3c5c3730a96c8fd61
Earlier we placed these files in the jenkins user's homedir. That was
causing a problem so the cache directory was moved into /opt and
symlinked for backwards compatibility[1]. However, the jenkins user
doesn't have write access to directories created by root and will fail
to write files to that directory in devstack-gate[2][3]. This patch
changes the ownership of the cache directory back to the jenkins user so
that it should work the same as it worked when the directory was in the
jenkins user's homedir.
[1] https://review.openstack.org/#/c/460835/
[2] http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n516
[3] http://paste.openstack.org/show/608377
Change-Id: I275f6ac8e5bb71aef904e8b9406a8810dae9bc67
For whatever reason, the source-repositories caching element is
running in the very early extra-data phase of disk-image-builder.
cache-devstack is instructing source-repositories to put the cached
urls into /home/jenkins/cache/files (55-cache-devstack-repos makes up
the list of images to download from devstack; the other two are just
pre-configured URLS).
This causes a problem when trying to add the jenkins user later in
jenkins-slave/install.d/20-jenkins-slave. Since source repositories
has already created /home/jenkins, useradd won't do it again and does
not copy in any of the skeleton files.
This moves the extra-data phase caching into /opt/cache, which is
probably a more logical place for it anyway. To maintain the status
quo, after we create the jenkins user, symlink ~jenkins/cache/files to
this new location.
This was probably going wrong with puppet too. I'm guessing it just
ignored the existing homedir when creating the user. I have tested
this by building trusty and stopping the build before and after the
useradd calls in 20-jenkins-slave. "/home" was empty, the useradd
creates the user, group & directory, the symlink is made correctly and
/opt/cache/files appears populated as usual.
Change-Id: Ibca6867f29b257a5110cb5522a5cca3a97fa9377
Make sure we force /bin/bash for jenkins shell, as not all operating
systems default to bash.
Change-Id: Ic671b7c5344a1e7980bede88bee730b50764e60b
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
This should be the final step needed to stop puppet from running on
our images. This also will be the entry point for 3rd party CI users
still depending on jenkins.
Change-Id: I33a67f980289002618a55f4221dcf195dc4a787f
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Monty Taylor