summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Pass cluster morphology to release upload script.baserock/michaeldrake/release-upload-clusterMichael Drake2014-08-011-9/+12
| | | | This makes the release-upload script more versatile.
* Update morph in tools.morph, cross-bootstrap.morphLars Wirzenius2014-07-312-2/+2
|
* Merge branch 'baserock/jjardon/gtk3-stratum'Sam Thursfield2014-07-314-93/+73
|\ | | | | | | | | Reviewed-By: Sam Thursfield <sam.thursfield@codethink.co.uk> Reviewed-By: Lars Wirzenius <lars.wirzenius@codethink.co.uk>
| * Add GTK+3 stratumJavier Jardón2014-07-311-0/+13
| |
| * gtk-deps.morph: Upgrade accesibility packagesJavier Jardón2014-07-311-6/+6
| | | | | | | | No morph file is needed in any of them
| * gtk-deps.morph: Update gnome-common to 3.12.0Javier Jardón2014-07-311-2/+2
| | | | | | | | | | No morph file needed thanks to a patch upstreamed by me to use autoreconf to check the automake version
| * gtk2.morph: Remove some build-depsJavier Jardón2014-07-311-2/+0
| | | | | | | | | | GTK+2 doesnt depend on genivi-foundation and x-common is already a dependency of x-x86_64-generic
| * gtk-deps.morph: Remove cairo, pango and deps as they are already in wayland ↵Javier Jardón2014-07-311-29/+1
| | | | | | | | stratum
| * Move GTK+ dependencies to a new 'gtk-deps' stratumJavier Jardón2014-07-312-74/+78
| | | | | | | | As they are shared by GTK+2 and GTK+3
| * gtk2.morph: librsvg is not a GTK+ dependencyJavier Jardón2014-07-312-17/+10
|/ | | | | Move to xfce stratum for now as seems to be the only stratum that requires it
* Merge branch 'baserock/liw/merge-michaels-ci-release-scripts'Lars Wirzenius2014-07-302-39/+129
|\ | | | | | | | | This is a merge of the baserock/michaeldrake/ci-release-scripts branch, but with some cleanups of the code for cleanliness.
| * Add --upload-build-artifacts settingLars Wirzenius2014-07-301-1/+13
| |
| * Join short lines into one line, for readabilityLars Wirzenius2014-07-301-2/+1
| |
| * Avoid running rsync if source file list is emptyLars Wirzenius2014-07-301-1/+4
| |
| * Refactor long method into smaller onesLars Wirzenius2014-07-301-19/+37
| | | | | | | | For comprehensibility.
| * Add markers around list in debug logLars Wirzenius2014-07-301-0/+2
| |
| * Simplify logic and conditionLars Wirzenius2014-07-301-3/+2
| | | | | | | | | | Avoiding a condition that has a negation tends to be a bit simpler for humans to understand.
| * Refactor process_args to be clearerLars Wirzenius2014-07-301-9/+14
| | | | | | | | | | Move stuff into new methods to make overall logic clearer and to avoid stuffing too much into each method.
| * Add --upload-release-artifacts settingLars Wirzenius2014-07-301-13/+9
| |
| * Remove unnecessary leading _ from methodLars Wirzenius2014-07-301-3/+3
| |
| * Allow release deployments with system name ≠ deployment namebaserock/michaeldrake/ci-release-scriptsMichael Drake2014-07-301-24/+21
| | | | | | | | | | There used to be a check that prevented deployments with names different to the system. I don't know why this was, but I don't think we need it.
| * Fix releasing when no changes to the cache are requiredMichael Drake2014-07-301-6/+9
| | | | | | | | | | Without this change the rsync and xargs commands will wait forever for input that will never arrive.
| * Allow release scripts to be configured to only handle a subset of architecturesMichael Drake2014-07-302-1/+33
| | | | | | | | | | | | | | | | | | | | | | We currently build all architectures at once during the release process, however for our CD pipeline we operate with one CD pipeline per architecture. This is not just useful for the CD pipeline work though, as it allows one organisation to handle releases for x86, where the infrastructure may be located in the cloud, and one organisation to handle ARM systems, which may be located in an office.
| * Allow release-upload to be configured not to upload release imagesMichael Drake2014-07-301-3/+21
| | | | | | | | | | | | | | | | | | For continuous artifact cache population, we don't care so much about the large disk images that we make available at release time. This patch allows omitting any of the configuration required to upload the release images to mean that we didn't want to upload them, and continue without doing so.
| * Allow release-build to build subsystems of defined systemsMichael Drake2014-07-301-1/+8
| |
| * Write release images into release subdirectoryMichael Drake2014-07-301-2/+1
|/ | | | | | | | The script used to chdir into the release directory before running morph deploy. Unfortunately, this didn't work because deployments are run from the top of the definitons repository. So now the release directory is included in the path to be deployed.
* Add ci cluster morphology for CD pipeline work.Michael Drake2014-07-301-0/+14
| | | | | Reviews: +2 Richard Maw
* Update morph to get list-artifacts fixAdam Coldrick2014-07-292-2/+2
|
* Update morph to get the symlink bugfixAdam Coldrick2014-07-292-2/+2
|
* Merge branch 'baserock/adamcoldrick/apply-gtk3-patches'Adam Coldrick2014-07-291-4/+4
|\ | | | | | | | | | | | | | | This merges Javier's patch to update glib and gobject-introspection that was sent to the mailing list. Reviewed-by: Richard Maw Reviewed-by: Pedro Alvarez
| * foundation.morph: Update GLib and gobject-introspection to latest stable ↵baserock/adamcoldrick/apply-gtk3-patchesJavier Jardón2014-07-291-4/+4
|/ | | | (2.40 and 1.40)
* Merge branch 'baserock/pedroalvarez/genivi-I0.1'Adam Coldrick2014-07-291-2/+2
|\ | | | | | | | | | | | | | | This merges an update of connman to 1.24 by Pedro Alvarez as required for GENIVI. Reviewed-by: Richard Maw Reviewed-by: Sam Thursfield
| * Update connman to the 1.24 versionPedro Alvarez2014-07-251-2/+2
| |
* | Merge branch 'baserock/liw/x-consolidation'Lars Wirzenius2014-07-2518-430/+21
|\ \ | |/ |/| | | | | This merges changes from Emmet Hikory and Michael Drake to consolidate X strata so they're easier to work with.
| * Update mesa-x ref to use consolidated chunk morphologyLars Wirzenius2014-07-251-1/+1
| | | | | | | | This is the ref for the merged branch from Emmet.
| * Consolidate genivi-specific X definitionsEmmet Hikory2014-07-257-29/+5
| | | | | | | | | | The GENIVI-specific X definitions now only differ in name, so may be consolidated.
| * Consolidate X definitionsEmmet Hikory2014-07-2518-402/+17
|/ | | | | | As the X morphlogies no longer carry significant variation, and maintaining syncronisation becomes a frustrating manual exercise, they are consolidated, based on the x86_64 X, which seems most current.
* Merge remote-tracking branch 'origin/baserock/liw/gitlab-repoless-backups'Lars Wirzenius2014-07-246-14/+88
|\ | | | | | | | | Reviewed-by: Richard Maw Reviewed-by: Adam Coldrick
| * Add remote backup and restoration scripts.Michael Drake2014-07-022-0/+79
| | | | | | | | | | | | | | | | | | - Scripts written by Lars Wirzenius. - Reviewed by Michael Drake. These scripts are to be copied to the system on which the backups are made. They are stored here to keep the related logic in one source location.
| * Add fstab configuration extension to gitlab-server system.Michael Drake2014-07-021-0/+1
| | | | | | | | | | This is useful so that we can deploy a Gitlab system with a separate /home disk.
| * Add systemd units to run backup-gitlab periodicallyLars Wirzenius2014-07-022-3/+3
| |
| * Change backup-gitlab to use database dump instead of Rake scriptLars Wirzenius2014-07-021-11/+5
| | | | | | | | | | | | | | | | | | | | | | The Gitlab Rake script for backing up doesn't backup the database that Gitlab CI uses, and additonally it does a git bundle for each git repository. Our GitLab instance has hundreds of git repositories, making the bundling be a very expensive things. Instead, we use the Postgres tool to dump all databases to a file, and arrange to backup the dump files, the git repositories, and all other relevant files directly.
* | Remove old release scriptsLars Wirzenius2014-07-242-687/+0
| |
* | Merge branch 'baserock/liw/release-upload-script'Lars Wirzenius2014-07-244-0/+564
|\ \ | | | | | | | | | | | | | | | | | | | | | Reviewed-by: Richard Maw Reviewed-by: Sam Thursfield I fixed commit meessages and made some small code changes while merging, as discussed on the mailing list.
| * | Chmod uploaded filesLars Wirzenius2014-07-241-1/+18
| | | | | | | | | | | | Suggested-by: Sam Thursfield
| * | Add new scripts for building, uploading releaseLars Wirzenius2014-07-244-0/+547
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These scripts are a rewrite of scripts/do-release.py and scripts/distbuild-cluster. The biggest difference is that they split the tasks of building the things that are to be released, and uploading them to git.baserock.org / download.baserock.org, where do-release.py combines both (and distbuild-cluster only builds chunk/stratum/system artifacts, not the release images). The new scripts are also configurable using command line options or a configuration file rather than requiring editing of the source. These changes will allow, for example, a CI job that builds a release, but doesn't upload it to download.baserock.org. The new scripts are coupled with a change to the release process, which will be documented as a change to the release process page on wiki.baserock.org. The 14.29 release of Baserock was done with slightly different versions of these scripts to make it feasible to upload things over multiple network connections.
* | | Merge branch 'baserock/pedroalvarez/add-more-openstack-clients3'Pedro Alvarez2014-07-249-37/+61
|\ \ \ | |/ / |/| | | | | Reviewed-by: Richard Maw
| * | Add cloud-init support to some x86 systems (base, devel and Trove)Pedro Alvarez2014-07-245-0/+10
| | | | | | | | | | | | | | | | | | This includes: - Add cloudinit-support stratum to the systems - Add cloud-init configuration extension to the systems
| * | Add cloud-init.configure extensionPedro Alvarez2014-07-241-0/+50
| | |
| * | Use a cloud-init version with the services disabled by defaultPedro Alvarez2014-07-231-1/+1
| | | | | | | | | | | | | | | | | | Now adding cloud-init to a system will be harmless and it can be enabled with a configuration extension during the deployment.