1. 02 Nov, 2018 6 commits
  2. 01 Nov, 2018 2 commits
    • Robert Knight's avatar
      Create qa deployment of the client · 6ae6d731
      Robert Knight authored
      Add a new build stage to Jenkins CI builds of the master branch which
      deploys a "QA" build to S3. This QA build:
      
       - Has a pre-release version number of the form `X.Y.Z-{commit hash}`
       - Has a stable URL at https://cdn.hypothes.is/hypothesis@qa
         (as opposed to https://cdn.hypothes.is/hypothesis for the prod build)
       - Loads the sidebar app from qa-h (https://qa.hypothes.is/app.html)
       - Does not update the changelog or create a Git tag or GitHub release
      
      This build is currently not deployed to npm at all, but we might need to
      do that in future if we were to create a QA deployment of the browser
      extension with it.
      
      ---
      
       - Add a QA deploy step to the Jenkins build.
       - Skip GitHub release creation and changelog updates for pre-release
         versions used for QA deployments.
       - Remove the preversion.sh script, which is no longer needed since the
         builds always run in Jenkins and not on a developer's system.
       - Support specifying the npm tag to check in `wait-for-npm-release.sh`,
         though this is not used in the final version of this commit.
      6ae6d731
    • Robert Knight's avatar
      Add S3 deployment script to replace s3-npm-publish · dc514d39
      Robert Knight authored
      Replace the generic Docker-based s3-npm-publish tool with a JS script in the
      client repo which is tailored more specifically to the needs of client
      deployments:
      
       - Avoid creating the `hypothesis@X.Y` and `hypothesis@X` aliases which we
         never used.
      
       - Support uploading a copy of the entry point under a version-indepenent
         alias, regardless of whether this is a pre-release or not.
      
         This will enable creating a stable URL which points to the current QA
         version of the client.
      
       - Deploy the package directly from the current working directory. This saves
         the need to wait for publication to npm to complete, or the need to
         actually publish the package to npm at all in the case of the QA
         release.
      dc514d39
  3. 31 Oct, 2018 4 commits
  4. 25 Oct, 2018 3 commits
  5. 23 Oct, 2018 7 commits
  6. 22 Oct, 2018 5 commits
  7. 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
  8. 18 Oct, 2018 1 commit
  9. 17 Oct, 2018 5 commits
  10. 09 Oct, 2018 2 commits