This project is mirrored from https://gitlab.com/gitlab-org/gitlab-runner.git. Pull mirroring updated .
  1. 12 Oct, 2020 1 commit
  2. 18 Jun, 2020 4 commits
  3. 17 Jun, 2020 1 commit
  4. 06 Mar, 2020 1 commit
  5. 05 Feb, 2020 1 commit
    • Steve Azzopardi's avatar
      Revert 9e1d0676 · 0b4538cc
      Steve Azzopardi authored
      After discussing this a bit more with fabiopitino there seems like
      there was a bit of miscommunication. We want to have the 422 error not
      retry the job but still consider it a valid response that the artifact
      was uploaded. From an API perspective, this is not the best solution
      since a 4xx status code is an error and should be treated as such.
      
      In light of recent events such as
      https://gitlab.com/gitlab-org/gitlab/issues/199764 we've seen spikes of
      similar behavior as https://gitlab.com/gitlab-org/gitlab/issues/36516
      (which was what this issue was trying to solve). We decided that the
      following should happen:
      
      1. Implement https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24165
         which will handle the scenario where rails actually upload the artifact
         but fail to save the metadata or any other part. If there is a failure
         Rails would respond with a 4xx/5xx error accordingly and the Runner will
         retry to upload (this is already done) on the second try of uploading
         the artifact rails will check if artifact is already uploaded if it is,
         it will pick up from where it fails (for example storing the metadata)
      1. Revert
      https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1794
      because of two things
          - It does not implement the original behavior we wanted. We wanted
            to have 422 act as a valid response and not to fail the build.
          - We don't want to have any special behavior for 422, if rails
            return 422 we still want to retry the upload.
      
      This is not a full revert of 9e1d0676
      because it included some refactoring. This just removes the knowledge of
      the `422` error.
      0b4538cc
  6. 30 Jan, 2020 1 commit
  7. 16 Mar, 2019 1 commit
  8. 16 Oct, 2018 1 commit
  9. 15 Oct, 2018 1 commit
  10. 03 Oct, 2018 1 commit
  11. 30 Jul, 2018 2 commits
  12. 19 Jul, 2018 1 commit
  13. 18 Jul, 2018 2 commits
  14. 05 Jul, 2018 1 commit
  15. 28 Jun, 2018 1 commit
  16. 25 Jun, 2018 1 commit
  17. 07 Jun, 2018 1 commit
  18. 23 Feb, 2018 1 commit
  19. 11 Sep, 2017 1 commit
  20. 22 Aug, 2017 1 commit
  21. 13 Jun, 2017 2 commits
  22. 15 Mar, 2017 1 commit
  23. 14 Mar, 2017 1 commit
  24. 06 Jun, 2016 1 commit
  25. 11 Mar, 2016 1 commit
  26. 06 Feb, 2016 3 commits