feat(nginx-website): allow setting redirections

[lemeurherveCB]

This PR allows defining redirections (with return, preferable in most cases to rewrite) so we can for example avoid breaking existing (old.)stats.jenkins.io URLs which pointed to files on GitHub but are not served by the new frontend, used by far more than we/I though initially.

Ref:

• To host stats.jenkins.io GSoC 2024 project in jenkins-infra helpdesk#4132 (comment)

Example of usage

values.yaml:

nginx:
  serverName: localhost
  slashLocation:
    root: /usr/share/nginx/html
    index: index.html index.htm
    autoindex: "on"
    ## Uncomment to enable try_files directive
    # tryFiles: $uri /index.html
  redirections: {}
    - location: /jenkins-stats
      returnedCode: 301
      destination: https://raw.githubusercontent.com/jenkins-infra/infra-statistics/gh-pages/
    - location: /plugin-installation-trend
      returnedCode: 301
      destination: https://raw.githubusercontent.com/jenkins-infra/infra-statistics/gh-pages/
    - location: /pluginversions
      returnedCode: 301
      destination: https://raw.githubusercontent.com/jenkins-infra/infra-statistics/gh-pages/

Resulting nginx config:

    server {
      listen       80;
      server_name  localhost;
      location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
        autoindex on;
      }
      location /jenkins-stats {
        return 301 https://raw.githubusercontent.com/jenkins-infra/infra-statistics/gh-pages/$request_uri;
      }
      location /plugin-installation-trend {
        return 301 https://raw.githubusercontent.com/jenkins-infra/infra-statistics/gh-pages/$request_uri;
      }
      location /pluginversions {
        return 301 https://raw.githubusercontent.com/jenkins-infra/infra-statistics/gh-pages/$request_uri;
      }
    }

[timja]

This may work, but the safer option would be new stats app to server these files directly.

If it can't be done quickly then the site should be rolled back (although old should be kept to not breaking people who have migrated there)

[timja]

This isn't the same API and may still cause breaking changes.

1. There's no guarantee that consumers will follow redirects
2. raw.githubusercontent returns a content-type of text/plain which may break consumers

[lemeurherveCB]

the safer option would be new stats app to server these files directly.

I agree with that and the other points you mentioned, but the issue with serving these files directly from our service is that we don't know (and can't AFAIK) how much outbound bandwidth it could represent.
Depending on the external consumers that might be too costly.

[timja]

the safer option would be new stats app to server these files directly.

I agree with that and the other points you mentioned, but the issue with serving these files directly from our service is that we don't know (and can't AFAIK) how much outbound bandwidth it could represent. Depending on the external consumers that might be too costly.

If thats a concern is there any reason we moved off GitHub pages?
its a fully static site isn't it?

[dduportal]

This may work, but the safer option would be new stats app to server these files directly.

If it can't be done quickly then the site should be rolled back (although old should be kept to not breaking people who have migrated there)

+1 with @timja . This should justify a rollback and a re-architecturing of the model used if bandwidth is a problem.

[dduportal]

(although old should be kept to not breaking people who have migrated there)

@timja @lemeurherveCB Just a point about the GitHub Pages: it only accepts a single CNAME.
Looks like it is a problem here as we have to choose between old.stats.jenkins.io or stats.jenkins.io if we rollback.

I'll continue in jenkins-infra/helpdesk#4132

[dduportal]

Closed by jenkins-infra/stats.jenkins.io#168 (not needed anymore)