根据https://docs.gitlab.com/runner/install/linux-repository.html#upgrading-to-gitlab-runner-10,repos改变了,所以我们尝试更新所有节点的gitlab运行程序。我们需要删除旧的回购并添加新的,然后更新包.
在我们的傀儡manifest1上,我们更新回购,确保包的最新版本,在此更新之后,我们必须在确保服务运行之前运行一个脚本。我们的问题是,我们应该只在更新之后运行这个脚本。
现在,即使更新了回购,包也不是。只有当distro_sync运行或我们运行“”时,包才会更新,而不是通过傀儡运行。看起来这个包从来没有更新过,好像它是在检查旧回购的最新版本,而不是与最近增加的回购进行比较。
1
# Installs a GitLab-CI runner for CERN GitLab
class gitlab::gitlab_ci_runner (
String $ensure = 'latest', # passed to the gitlab-runner package. Can be used to force a version
) {
ensure_resource('yumrepo', 'gitlab-runner', {
descr => 'gitlab-runner for EL6/7',
baseurl => "http://packages.gitlab.com/runner/gitlab-runner/el/${::operatingsystemmajorrelease}/${::architecture}",
gpgcheck => 0,
enabled => 1,
exclude => absent,
})
ensure_packages(['gitlab-runner'], {
ensure => $ensure,
require => Yumrepo['gitlab-runner'],
})
exec {"post-install":
command => 'sudo /usr/share/gitlab-runner/post-install',
provider => shell,
onlyif => 'test -e /usr/share/gitlab-runner/post-install',
refreshonly => true,
subscribe => Package['gitlab-runner'],
}
service { 'gitlab-runner':
ensure => running,
enable => true,
require => [Package['gitlab-runner'], Exec["post-install"]]
}
}发布于 2018-10-10 13:54:12
您之所以会遇到这种行为,是因为傀儡在资源目录应用程序之前预先获取包资源的存储库元数据。请注意源代码这里用于yum的当前状态和通用提供程序的这里的相关源代码。请注意,链接代码的广泛功能并没有随着时间的推移而改变,所以虽然微妙之处可能会改变,但总体行为已经/不会改变。
因此,在应用资源之前就会确定包的latest版本。因此,在您的情况下,在目录编译时订阅的存储库将确定包的latest版本。目录应用程序期间的存储库订阅更改不会影响ensure => latest的行为。
正如您可能猜到的那样,确保特定版本仍然具有所需的效果,因为它将利用新的存储库,并且不会发生有关latest的资源预取(其他预取仍然会发生)。或者,一个连续的目录应用程序将对ensure => latest产生所需的效果。总之,您在这里的解决方案如下:
ensure => <version>,其中您指定了确切的版本或版本发布,例如10.0.5-el7。可以预见,有关资源预取的另一个重要信息来源是Gary的博客文章这里。向下滚动到以“预取、刷新、缓存和其他”开头的标题。请注意,对于Gary的博客有“很强的语言”,这是非常谨慎的。它的正式文件基本上是无用的。
https://stackoverflow.com/questions/52741054
复制相似问题