Skip to content

C
coopwire-hypothesis
Switch branch/tag
  1. 22 Apr, 2020 16 commits
  3. 21 Apr, 2020 4 commits
  5. 20 Apr, 2020 7 commits
  7. 17 Apr, 2020 8 commits
    • Robert Knight's avatar
      Rename two arguments · 5dba8250
      Robert Knight authored 
      Rename two arguments to make it, subjectively, easier to distinguish them at a glance.
      5dba8250
    • Robert Knight's avatar
      Be consistent about comparing by strict equality · 1b677c2f
      Robert Knight authored 
      Previously watched values that were objects or arrays were compared by
shallow equality if only one watcher was passed to `watch` but compared
by strict equality otherwise. Strict equality was supposed to be used in
both cases.
      1b677c2f
    • Robert Knight's avatar
      Use snake case for action types · cec51edc
      Robert Knight authored 
      This is more conventional in our usage of Redux elsewhere in the app.
      cec51edc
    • Robert Knight's avatar
      Merge pull request #2040 from hypothesis/fix-jenkins-wrong-deploy · 68c40dd2
      Robert Knight authored 
      Attempt to fix issue where wrong code was sometimes deployed
      68c40dd2
    • Robert Knight's avatar
      Re-enable QA and prod deployment skips on non-master branches · c2e5d0d6
      Robert Knight authored 
      This check was temporarily removed in the previous commit to test the
changes.
      c2e5d0d6
    • Robert Knight's avatar
      Attempt to fix issue where wrong code was sometimes deployed · a6d0ea34
      Robert Knight authored 
      This commit fixes an issue with the client's Jenkins pipeline that could
cause code for a recent but not-the-latest commit to master to be deployed to QA,
but with the version number corresponding to the latest commit.

---

The client's Jenkins CI/CD build is split into three phases:

 1. Checkout source, build, lint and test
 2. Publish QA release
 3. Publish prod release

Each of these phases was executed in a separate `node` block. Each node
block defines a task and Jenkins allocates a workspace directory for
that task. Workspace directories are named after the project, branch and
concurrent build number (eg. `/data/jenkins/workspace/client_master@2`).

Each workspace directory is "locked" for use by one task at a
time, but workspace directories are re-used when not locked. New
workspace directories are allocated as needed when concurrent builds
happen and all existing directories for a given (project, branch) are
locked.

If there was only one active build of the client's "master" branch,
phases (2) and (3) would re-use the same workspace directory and
everything would work as expected. If however there was a concurrent build,
phase (2) could end up using a different workspace directory than phase (1):

 1. Build A starts phase 1 and uses workspace dir #1
 2. Build B starts phase 1 and uses workspace dir #2
 3. Build A finishes phase 1, freeing workspace #1
 4. Build A starts phase 2, using workspace #1
 5. Build A completes phase 2, freeing workspace #1
 6. Build B completes phase 1 and starts phase 2, using workspace #1

In step (6), build B runs phase 2 (the "Publish QA" step) using the
workspace created by build A and publishes the code checked out by build
A with the version number associated with build B.

The fact that this kind of screw-up is even possible shows a deeper
issue with our current CI setup. Nevertheless, this commit addresses the
immediate issue by:

 1. Putting phases (1) and (2) in the same `node` block so that they are
    guaranteed to use the same workspace directory. There was no benefit
    to making them separate tasks.

 2. Adding a `checkout scm` command at the start of phase (3) so that it
    will definitely deploy the same code that was tested and deployed to
    QA in steps (1) and (2)

[1] https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md#understanding-syntax
      a6d0ea34
    • Robert Knight's avatar
      Merge pull request #2039 from hypothesis/fix-slider-focus-ring-clipping · 53d4d897
      Robert Knight authored 
      Fix visibility of submenu item focus rings
      53d4d897
    • Robert Knight's avatar
      Merge pull request #2036 from hypothesis/increase-highlight-opacity · 540e7373
      Robert Knight authored 
      Increase highlight opacity
      540e7373
  9. 16 Apr, 2020 1 commit
    • Robert Knight's avatar
      Fix visibility of submenu item focus rings · b2887be5
      Robert Knight authored 
      Item submenus inside the `Menu` component are wrappd in a `Slider` to
enable an animated expand/collapse of the submenu. The `Slider` used
`overflow: hidden` to hide any content while collapsed or transitioning.
However this had the unintended effect of clipping focus rings which
extended beyond the bounds of the content.

Fix the issue by changing the `overflow` property to `visible` once the
slider's content is fully visible.
      b2887be5
  11. 15 Apr, 2020 4 commits