Release branches tips and tricks

amercader edited this page Oct 3, 2014 · 5 revisions
Clone this wiki locally

General tips

  • should always run the latest beta version of CKAN (either the latest patch release of the last released minor version of CKAN or the beta branch of an upcoming CKAN minor version). It is automatically updated every night, so it is useful to test the changes that are being picked. To change the version run log into the server (currently and update the following entry in the okfn user crontab:

    05 00  *   *   *  /usr/local/bin/ansible-playbook /home/okfn/update_source/update_source.yml -s --extra-vars="site=beta version=release-v2.2.1" >>
  • git am for merging several commits

    The usual workflow for getting stuff into the release branches is to cherry-pick them with git cherry-pick. This is usually fine as fixes consist of one or few commits, but if there are more commits to be merged (like in #1505 below) this can be tedious. Another option is to use git am on the patch files that Github will generate for you on a Pull Request. git am will parse the patch file and apply each individual commit to the current branch. To get the patch for a particular pull request just add .patch to its URL, eg:

    If you run git am on this file, the issue tags ([#1505]) will get stripped from the commit messages, as git will consider them part of the [PATCH X/Y] tags used in the patch file. In order to keep these you need to run git am -k, but this will also keep the [PATCH X/Y] tags added to the patch file:

    [PATCH 03/13] [#1505] Fix bug when non-sysadmins invited users to organizations

    To avoid it, I remove these before running git am:

    sed 's/\[PATCH \([0-9]*\)\/\([0-9]*\)\] //' 1505.patch | git am -k

    For convenience you can wrap the whole thing in a function on your bashrc or zshrc file:

    gam () {
    sed 's/\[PATCH \([0-9]*\)\/\([0-9]*\)\] //' $1 | git am -k

    And then run the following on the release branch:

    gam 1505.patch

Real world examples

Some practical examples of reviewing and merging issues that should be backported to a patch release branch or picked into a new release branch.

  • Invite to organization causes Internal Server error #1505

    This one is a fairly typical case of a small, straight-forward fix (the one on this commit) accompanied with several test related commits. I always try to merge tests if there aren't massive merge conflicts, as they ensure that the fix also works on the release branch apart from master. If the tests require other patches or the merge is too complicated I use my own judgement (and double test things manually) to decide if I can add a new commit to the release branch with just the relevant fixes.

    (Note that the original submitter could have noticed that this needed backporting and aggregate the fix + relevant tests in a single commit to make things easier).

  • Oversized Forgot Password button and field #1508

    There are changes in the translation strings used by the templates. If this was a more severe issue I'd ping the original submitters and ask them to provide a patch that just fixed the issue without changing the strings. As this is not terribly important, we just won't merge it.

  • Dataset tags autocomplete doesn't work #1512

    60 Javascripts files changed? I think I'll pass... Except in this case is just an upgrade of a particular library (select2). It is unlikely that anyone will be relying on a particular version of select2 and we are upgrading it because it has bug fixes anyway. There are a couple of conflicts during the merge, but we just pick whatever is on the newest version. Manual testing shows that the issue is fixed on both debug and production mode (ie minified and unminified).

  • Activity Stream from: Organization Error group not found #1519

    This patch involves the logic layer, so we should be extra careful. Firstly we need to decide if backporting is worth at all. This patch is fixing a 500 in the frontend, so seems worth it. When logic or auth are involved there are no shortcuts to actually look into the code and understand what's going on to make sure it won't introduce backwards incompatible changes. In this case we are adding new actions and the modifications in the existing ones look fine, so we cherry-pick the commits.

  • [#1594] Fix breakage in package groups page #1603

    This patch has a good description and the fix seems sensible, so we cherry-pick it. But we will get merge conflicts:

    {% set type = group.type or 'group' %}
    {% set url = h.url_for(type ~ '_read', action='read', %}
    <<<<<<< HEAD
    {% block item %}
    >>>>>>> 1492632... [#1594] Fix breakage in package groups page
    <li class="media-item">
     {% block image %}

    The block {% block item %} seems to have been added at a later stage than when 2.2 was branched (and we confirm that with git blame, git log etc). We shouldn't mess with the templates on patch releases unless to fix something, so we ignore it and only add the relevant lines when solving the merge conflict:

    {% set type = group.type or 'group' %}
    {% set url = h.url_for(type ~ '_read', action='read', %}