Age | Commit message (Collapse) | Author |
|
|
|
As part of https://gitlab.com/gitlab-org/gitlab-pages/-/issues/385
we have introduced the use of a custom `.golangci.yml` file with some
custom rules for linting.
This replaces the need of downloading and using `golint`, `gofmt`
`go vet` and `gocyclo` manually. We take advantage of the custom
`golangci-lint` docker image as stated in the [Automatic lintinb]
(https://docs.gitlab.com/ee/development/go_guide/#automatic-linting)
section of the Go standards and style guidelines.
This iteration enables a subset of linters, with the remaining
of them enabled on a separate MR as described in the issue above.
The main changes introduced by this linter include:
- gosec: potential hardcoded credentials
- goconst: DRY by declaring and using constants
- gosimple: reduce statements complexity and improve return statements
|
|
Use filename from closure
|
|
|
|
Passing secrets via command line is not allowed anymore.
A config file should be used instead. The default filename is
`gitlab-pages-config`. The following command line options will
throw an error and prevent pages from running if set explicitly:
- `-auth-client-id`
- `-auth-client-secret`
- `-auth-secret`
|
|
guide
|
|
(cherry picked from commit c4da6ef61d338c19832b99574eaf2dce383be70e)
|
|
Instead of passing domains once in an ENV variable we now watcn a config
file (specified with `GITLAB_SOURCE_CONFIG_FILE`, defaults to
`.gitlab-source-config.yml` and update ednabled/broken domains when it's
content change.
This way we can control this without having to restart Pages.
Related to https://gitlab.com/gitlab-org/gitlab-pages/issues/266.
|
|
* master:
Add support for the port component in the Host header
Base64 decode GitLab API secret
|
|
|
|
before using it.
|
|
|
|
|
|
|
|
We can't rely on r.TLS when pages are served behind proxy
So we save https flag to a context for later usage
Right now I'm trying to keep changes to a minimum since
I'm planning to backport this to older versions
That's why https flag is not refactored throughout the codebase
The alternative way would be to use gorilla's proxy headers
I'm planning to refactor to that version later
|
|
Introduce two new configuration options -tls-min-version and
-tls-max-version to control which TLS versions will be supported by the
server. Accepted values are ssl3, tls1.0, tls1.1, tls1.2, and tls1.3.
Closing https://gitlab.com/gitlab-org/gitlab-pages/issues/187
|
|
Supported cipher suites:
tls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
Closes https://gitlab.com/gitlab-org/gitlab-pages/issues/150.
|
|
|
|
where root pages domain is not handled with pages daemon
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This will help us to find more failures.
In addition, this commit fixes an intermittent test failure - if a HTTP
request to pages was taking > 100ms to return any headers, it would be
failed. Two scenarios exist where we might take > 100ms:
* The "artifacts server timeout" test case, where we hang on for a whole second
* Loading and parsing SSL_CERT_FILE on first request in the artifacts server
proxy was slowing down the initial request enough to trigger this in some
environments
|
|
These processes weren't actually zombies at all, they were still running fine -
just outliving their parents as they were never given an interrupt signal in
the timeout case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
redirect-http seemed to suggest the Pages daemon would redirect from HTTPS to
HTTP, but it seems that the opposite was implied.
Fixes issue manifested by https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1348
|
|
|
|
Also fixed the dependencies, moved metrics to its own package and
updated the tests
|
|
This starts of the prometheus monitoring for GitLab Pages, and
resolves gitlab-org/gitlab-pages#42
Point to check:
- Are the metric names good, keeping Prometheus' conventions in mind?
- Golang, general style etc
- Shouldn't I do some voodoo magic to import this in the library?
|
|
|
|
|