1. 18 Jul, 2018 3 commits
  2. 10 Jul, 2018 1 commit
  3. 09 Jul, 2018 1 commit
  4. 05 Jul, 2018 1 commit
  5. 04 Jul, 2018 1 commit
  6. 03 Jul, 2018 2 commits
  7. 22 Jun, 2018 1 commit
  8. 19 Jun, 2018 1 commit
  9. 18 Jun, 2018 1 commit
  10. 15 Jun, 2018 5 commits
  11. 06 Jun, 2018 4 commits
  12. 01 Jun, 2018 1 commit
  13. 30 May, 2018 1 commit
  14. 09 May, 2018 1 commit
  15. 01 May, 2018 1 commit
  16. 23 Apr, 2018 1 commit
  17. 09 Apr, 2018 1 commit
    • Jason Plum's avatar
      CI: remove purgeJobs logic from delete() · b16287e9
      Jason Plum authored
      Remove the `purgeJobs()` logic and call from `delete()` function.
      
      It turns out that when `delete(canary)` is called after `deploy()` in `stable`, the jobs of the `production` deployment are deleted, thus losing logs! It is hard to investigate a problem with migrations when the Job and logs are deleted.
      
      With the addition of the appropriate `cleanup()` logic, `purgeJobs()` is made superfluous, and in this case, proved to be erroneous.
      b16287e9
  18. 06 Apr, 2018 1 commit
  19. 05 Apr, 2018 1 commit
  20. 04 Apr, 2018 2 commits
    • Jason Plum's avatar
      Changelog: introduce changelog_manager, with CI · 9e7fc641
      Jason Plum authored
      Bring in a modified flavor of `Changelog::Manager` from [release-tools](https://gitlab.com/gitlab-org/release-tools) as `scripts/changelog_manager.rb`. Add this to CI as `changelog` stage, which only happens on `master` branch.
      
      The major variations from the original are:
      - Run as a script, in place of a Rake task. Simpler to put into place, keeping it small.
      - Versions are now dates, in `%Y-%m-%d` format
      - Operates _only_ on the `master` branch.
      - Remove all logic related to SemVer, RC, distribution, etc.
      
      The script is located at `scripts/changelog_manager.rb` and makes use of the libraries from `scripts/lib/`. I've modified many of these in small to large ways to the reasons mentioned above. The script takes one argument, the path to the Git repository. In our case in CI, this is `.`.
      
      For an individual who wishes to test the functionality of `changelog_manager`, this can be done with a secondary checkout of this repository (e.g. `/tmp/destroy-me`).
      
      Check out a second instance of this repository, so as not to dirty your working copy.
      - In this temporary copy
        - Checkout `master`
        - Ensure there are entries in `changelogs/unreleased/`. If there are none, please manually add one (`bin/changelog` will not work while on `master`).
      - From your working copy, run `scripts/changelog_manager.rb /path/to/tmp/checkout`.
      - From your temporary copy, run `git show HEAD` to see what changes were made by running the script.
      - You can restart this process by running `git reset --hard HEAD~1` in your _temporary_ copy.
      
      - Reworked the format of CHANGELOG.md's Alpha entry to `2018-03-22 Alpha`, and pointed to alpha documentation.
      9e7fc641
    • Jason Plum's avatar
      CI: have `cleanup` function include ConfigMaps, remove Secrets · 4e1e3041
      Jason Plum authored
      Per review, add `ConfigMap` to the list of items handled in `cleanup()`, and remove `Secret` as it is currently shared by multiple deployments.
      
      Replace `kubectl_cleanup()` entirely, by replacing the function call in `cleanup()` with a condensed selector call through kubectl, in place of an iterative approach over individual types. Care of @Ahmadposten
      4e1e3041
  21. 03 Apr, 2018 3 commits
  22. 30 Mar, 2018 1 commit
  23. 29 Mar, 2018 1 commit
  24. 28 Mar, 2018 1 commit
    • DJ Mountney's avatar
      Reduce the cpu requests for CI for some of our charts · 09a23614
      DJ Mountney authored
      In our dev environments, it's unlikely that we will be putting real
      world strain on all our releases at once. So we are wasteing resources
      by having them so high.
      
      Note that I have left the public facing nodes,
      unicorn/registry/minio/gitlab-shell at their higher numbers because we
      are running in Google's IP range, and these nodes, especially shell can
      see high cpu usage, even in our CI, due to bots.
      09a23614
  25. 27 Mar, 2018 1 commit
  26. 23 Mar, 2018 1 commit
  27. 21 Mar, 2018 1 commit