Project

General

Profile

Actions

Bug #6885

closed

[Deployment] Add meaningful package versions to distro packages

Added by Brett Smith over 8 years ago. Updated about 7 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Deployment
Target version:
Story points:
1.0

Description

As we improve our deployment infrastructure, it's happening more and more that we make improvements to our packages that don't change the underlying code: more accurate dependencies, changes in support scripts like arvados-api-server-upgrade.sh, etc.

Right now these changes don't trigger a new package build. We always use fpm's default iteration setting of 1, and fpm doesn't rebuild packages when it sees a destination package with the correct software version+iteration already on disk.

We need at least a manual process to be able to increment/set the iteration. Engineering to spec a solution.

Actions #1

Updated by Brett Smith over 8 years ago

  • Subject changed from [Deployment] Add meaningful package verisons to distro packages to [Deployment] Add meaningful package versions to distro packages
Actions #2

Updated by Brett Smith over 8 years ago

Current expected solution: arvados-dev includes a configuration file that includes triples of (source package name, source version, package version). Whenever run-build-packages.sh builds source package name+package version, it should set the increment to package version. For any other build, it should not set the increment, or set it to 1 (the default).

Actions #3

Updated by Brett Smith over 8 years ago

  • Description updated (diff)

The fpm-info.sh mechanism recently added to arvados-dev gives us another channel to do this. For packages with source outside the Arvados tree, you can have the corresponding fpm-info.sh say:

fpm_args+=(--iteration 2)

You could also do this with our own Arvados packages… except, of course, that will bump the software version as well. So maybe we want to use empty commits as our package rebuild trigger?

Actions #4

Updated by Brett Smith over 8 years ago

  • Story points set to 1.0

Empty commits don't work to trigger new package builds for our own packages, since they look for commits that affect the specific component. So we still need an out of band mechanism to specify package iterations for those.

We're still agreed on the concept of maintaining a file of triples with package name, source version, and package iteration. Do that.

Actions #5

Updated by Brett Smith over 8 years ago

  • Target version changed from Arvados Future Sprints to Kanban
Actions #6

Updated by Ward Vandewege about 7 years ago

  • Status changed from New to Resolved
  • Assigned To set to Ward Vandewege
  • Target version changed from Kanban to 2017-01-18 sprint

This was fixed as part of #10858

Actions

Also available in: Atom PDF