This is pretty terrible but I wanted to see how it might work.

Reject unknown HTTP methods

See merge request gitlab-org/security/gitlab-workhorse!17

Run CI against Go 1.15 NO CHANGELOG

See merge request gitlab-org/gitlab-workhorse!674

too long method name results in too long
prometheus label name, which can crash prometheus

Makefile: remove find NO CHANGELOG

See merge request gitlab-org/gitlab-workhorse!669

Refactor logging helpers to reduce signature creep

See merge request gitlab-org/gitlab-workhorse!662

Document scripts/update-workhorse for releasing NO CHANGELOG

See merge request gitlab-org/gitlab-workhorse!668

[ci skip]

Add notice about canonical source NO CHANGELOG

See merge request gitlab-org/gitlab-workhorse!667

Support alternate document root directory

See merge request gitlab-org/gitlab-workhorse!626

Do not resize when image is less than 8 bytes, add comments

See merge request gitlab-org/gitlab-workhorse!666

Auto-register Prometheus metrics

Closes #326

See merge request gitlab-org/gitlab-workhorse!660

* Update to latest upstream Prometheus library.
* Update to latest upstream Prometheus gRPC library.
* Switch to `promauto` package to avoid missing metrics.

Closes: https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/326Signed-off-by: Ben Kochie <bjk@gitlab.com>

This will be useful for supporting no-downtime upgrades. Admins
attempting to upgrade GitLab via our no-downtime upgrade procedure have
found that CSS and JavaScript often don't load while the upgrade is in
progress. This is because in a mixed deployment scenario with a load
balancer, this can happen:

1. User accesses node version N+1, which then makes a CSS/JS request on
version N.
2. User accesses node version N, which then makes a CSS/JS requests on
version N+1.

In both scenarios, the user gets a 404 since only one version of the
assets exist on a given server.

To fix this, we provide an alternate path where previous and future
assets can be stored.

Relates to https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/304

Fix uploader not returning 413 when artifact too large

Closes #328

See merge request gitlab-org/gitlab-workhorse!663

[ci skip]

Add upload acceleration for Requirements import

See merge request gitlab-org/gitlab-workhorse!664

- Add spec

When an upload exceeds the maximum limit, `ErrEntityTooLarge` gets
returned but is wrapped in multiple layers of errors when it is
checked. As a result, when Google Cloud Storage were used to upload
files, artifacts exceeding the maximum size would report a "500 Internal
Server Error" instead of the correct "413 Request Entity Too Large"
error message.

To fix this, we check the state of `hardLimitReader` and set the error
to `ErrEntityTooLarge` at the end of the `SaveFileFromReader` to ensure
that this error will be returned.

Closes https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/328

[ci skip]

Consistent logging in image resizer module

Closes #320

See merge request gitlab-org/gitlab-workhorse!652

This allows us to consistently log these errors with all labels applied

Add Patrick Bajao as code owner NO CHANGELOG

See merge request gitlab-org/gitlab-workhorse!661

Fix EXIF cleaning for S3 compatible Object Storage

See merge request gitlab-org/gitlab-workhorse!658

Update LabKit library to v1.0.0

See merge request gitlab-org/gitlab-workhorse!659

LabKit has reached a 1.0.0 milestone 🎉

See https://gitlab.com/gitlab-org/labkit/-/releases/v1.0.0

When exiftool is already terminated, we no longer attempt to read from its stdout.

Related to: https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/233

Exif cleaner do not support additional reads after the underling process is completed.

When the Object Storage configuration requires a MultipartUpload,
workhorse loops over the input with a LimitReader,
such loop will call Read one extra time to make
sure the input was consumed entirely.

Related to: https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/233