1. 02 Nov, 2018 1 commit
  2. 31 Oct, 2018 4 commits
  3. 25 Oct, 2018 3 commits
  4. 23 Oct, 2018 7 commits
  5. 22 Oct, 2018 5 commits
  6. 19 Oct, 2018 5 commits
    • Robert Knight's avatar
      Skip builds of automated commits on Jenkins · 988faa34
      Robert Knight authored
      As part of the deployment process Jenkins creates a new commit on master
      in order to bump the npm package version.
      
      There is no point in creating an automated build of these commits, which
      can be identified by the commiter name.
      988faa34
    • jenkins-hypothesis's avatar
      v1.94.0 · e86fa4a0
      jenkins-hypothesis authored
      e86fa4a0
    • Robert Knight's avatar
      Merge pull request #787 from hypothesis/automate-release-process · 64bad0ad
      Robert Knight authored
      Move remaining client release steps to Jenkins
      64bad0ad
    • Robert Knight's avatar
      Add an example of a prerelease suffix · 61be288d
      Robert Knight authored
      61be288d
    • Robert Knight's avatar
      Semi-automatically publish a client release from Jenkins · e8be244d
      Robert Knight authored
      When performing a Jenkins CI build of the "master" branch, prompt the
      user to deploy and then after they approve, execute the same release
      process that a developer currently executes on their machine, namely:
      
       1. Update the changelog
       2. Run "yarn version" to update the package version, create a tag and GitHub release.
      
      After these steps the release process continues on Jenkins as before,
      with an npm package published and the build deployed to an S3-backed CDN
      using the s3-npm-publish tool.
      
      Enabling publishing the release entirely from Jenkins required some
      additional changes:
      
       - Use a Debian Stretch-based Node container, to get a newer Git
         version which supports "taggerdate", used by the changelog scripts.
       - Disable Git tag signing, since this is not set up on Jenkins.
       - Do not run "make test" from the preversion script, since this has
         already been run by Jenkins earlier in the process.
      
      Additionally to facilitate testing of this branch I added support for
      specifying a prerelease version suffix. This made it possible to test
      the whole deployment process without updating the live version of the
      client. In future this will likely come in useful for doing staging/QA
      releases.
      e8be244d
  7. 18 Oct, 2018 1 commit
  8. 17 Oct, 2018 5 commits
  9. 09 Oct, 2018 7 commits
  10. 08 Oct, 2018 1 commit
    • Robert Knight's avatar
      Support serving the client over SSL in development · 1ba23cce
      Robert Knight authored
      Following the conventions of the "h" project [1], the client's asset
      server (localhost:3001) and demo page server (localhost:3000) will be
      served over SSL if a certificate (".tlscert.pem") and private key
      (".tlskey.pem") are found in the root of the repository.
      
      This can be useful for testing the development client on pages served
      over SSL without having to disable mixed content warnings in the
      browser.
      
      [1] https://h.readthedocs.io/en/latest/developing/ssl/
      1ba23cce
  11. 29 Sep, 2018 1 commit
    • Robert Knight's avatar
      Use custom name for global `require` function · 047a34d0
      Robert Knight authored
      Browserify bundles that make their modules available for other bundles
      to consume define a global `require` function. This is then imported by
      other bundles and used to resolve module lookups.
      
      This `require` name can clash with web pages that use eg. `RequireJS`.
      Most of the time this isn't a problem because all of the page's own code
      has run by the time Hypothesis loads. If however the page loads
      additional scripts after Hypothesis has been loaded, they will end up
      finding Hypothesis's `require` instead of their own.
      
      This commit resolves the issue by renaming the global `require` function
      to `hypothesisRequire` in two steps:
      
       - The `externalRequireName` Browserify option changes the _exported_
         name.
       - A custom transform stream post-processes the Browserify bundle code
         to change the _imported_ name, since Browserify doesn't have an
         option for this itself.
      
      A small fix was needed to the `boot.js` script build to avoid stripping
      lines _after_ the sourcemap URL comment, instead of just that comment.
      
      Fixes #779
      047a34d0