Uploaded image for project: 'Infrastructure'
  1. Infrastructure
  2. INFRA-2942

Setup and Add surge.sh credentials to ci

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I want to setup plugins-site and eventually jenkins.io to deploy a test version of the site for every PR. The easiest solution for now is to use surge.sh. Its a free static site host.

      I'd prefer it to be added to ci.jenkins.io as its just test infra, and that way people can easily see and debug it.

      My plan is to essentially do something like https://github.com/cognitedata/griff-react/blob/master/Jenkinsfile#L108-L112 and either let it pick random domains for every build, or like they do, a static domain per PR.

      So surge.sh token (you get by running surge token) and the ability to have pipeline comment on a PR.

        Attachments

          Activity

          Hide
          olblak Olivier Vernin added a comment -

          Since we have access to a kubernetes cluster from ci.jenkins.io and we have a helm chart, wouldn't it be better to just build a docker image and update the helm chart, I mean we have most of the component for that

          Show
          olblak Olivier Vernin added a comment - Since we have access to a kubernetes cluster from ci.jenkins.io and we have a helm chart, wouldn't it be better to just build a docker image and update the helm chart, I mean we have most of the component for that
          Hide
          halkeye Gavin Mogan added a comment -

          well the helm chart just reads files off azure. We can totally do that, make a new upload directory for every for each PR. I'm not sure/if how we'd clean it up though.

          Also I'm unsure I want people's random code being run on jenkins.io, which could potentially steal any badly configured cookie.

          Open to suggestions.

          Gavin

          Show
          halkeye Gavin Mogan added a comment - well the helm chart just reads files off azure. We can totally do that, make a new upload directory for every for each PR. I'm not sure/if how we'd clean it up though. Also I'm unsure I want people's random code being run on jenkins.io, which could potentially steal any badly configured cookie. Open to suggestions. Gavin
          Hide
          halkeye Gavin Mogan added a comment -

          oooh! maybe use azure static sites, we don't need the docker image or k8s or anything, just create a sub directory

          https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website

          plus it would be on its own azurewebsites style domain so no worry about people posting to jenkins.io

          Show
          halkeye Gavin Mogan added a comment - oooh! maybe use azure static sites, we don't need the docker image or k8s or anything, just create a sub directory https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website plus it would be on its own azurewebsites style domain so no worry about people posting to jenkins.io
          Hide
          olblak Olivier Vernin added a comment -

          I have also been evaluating how easy it would be to improve the current workflow as it's in place for around 4years and a lot of things changed since then. You can look at this document to understand the context when I put everything in place jenkins-infra/iep-006

           

          Also, at the moment, the azure file storage cost is around +-70$ per month. On top of that, you must consider the Fastly cost and resources used on the Kubernetes cluster which IMHO is marginal for the Kubernetes part and covered by the sponsoring program for Fastly.

           

          I tend to avoid relying on the free tier of third services as you have no guarantee of how long those remain free, neither if you'll have someone available to change the workflow when the third service forces us to adapt.

          I prefer long-term stable solutions, as we must keep in mind the engineering effort to modify things.

           

          The reason why I started thinking to improve the process is that using infra.ci, updatecli, and the EKS cluster for ci.jenkins.io, we have tooling that I didn't have when I initially worked on jenkins.io 4 years ago

           

          What I have been thinking so far.

          1) Only build jenkins.io docker image when changing something

          Using infra.ci, we could build a docker image only based on webhooks instead of every 30min so we would drastically reduce the amount of docker image generated to only build one when something changes.

           

          2)  Rely on jenkins.io helm chart

          Using updatecli from infra.ci we could automatically bump the jenkins.io docker image used by the jenkins.io helm chart using something like this That updatecli configuration could be executed from jenkins-infra/jenkins.io so a change on jenkins-infra/jenkins.io master branch would automatically trigger a commit on jenkins-infra/charts master branch or a pull request on jenkins-infra/charts if we prefer the pull request workflow.

           

          3) Deploy short-lived environment

          This would be the final improvement.

          On Kubernetes, we can easily deploy short-lived services from ci.jenkins.io reachable using <PR_ID>.jenkins.io.ci.jenkins.io

          Obviously, this will require some improvement in the Jenkinsfile, as we will have to delete the resources and secure the workflow, and also probably deploy a docker registry on the EKS cluster

           

          Remark: My suggestions are just the results are recent thinking, considering that the current workflow is stable and the azure file storage only cost us 70$, I don't think it's worthwhile to work on that at the moment.

           

           

          Show
          olblak Olivier Vernin added a comment - I have also been evaluating how easy it would be to improve the current workflow as it's in place for around 4years and a lot of things changed since then. You can look at this document to understand the context when I put everything in place  jenkins-infra/iep-006   Also, at the moment, the azure file storage cost is around +-70$ per month. On top of that, you must consider the Fastly cost and resources used on the Kubernetes cluster which IMHO is marginal for the Kubernetes part and covered by the sponsoring program for Fastly.   I tend to avoid relying on the free tier of third services as you have no guarantee of how long those remain free, neither if you'll have someone available to change the workflow when the third service forces us to adapt. I prefer long-term stable solutions, as we must keep in mind the engineering effort to modify things.   The reason why I started thinking to improve the process is that using infra.ci, updatecli, and the EKS cluster for ci.jenkins.io, we have tooling that I didn't have when I initially worked on jenkins.io 4 years ago   What I have been thinking so far. 1) Only build jenkins.io docker image when changing something Using infra.ci, we could build a docker image only based on webhooks instead of every 30min so we would drastically reduce the amount of docker image generated to only build one when something changes.   2)  Rely on jenkins.io helm chart Using updatecli from infra.ci we could automatically bump the jenkins.io docker image used by the jenkins.io helm chart using something like this That updatecli configuration could be executed from jenkins-infra/jenkins.io so a change on jenkins-infra/jenkins.io master branch would automatically trigger a commit on jenkins-infra/charts master branch or a pull request on jenkins-infra/charts if we prefer the pull request workflow.   3) Deploy short-lived environment This would be the final improvement. On Kubernetes, we can easily deploy short-lived services from ci.jenkins.io reachable using <PR_ID>.jenkins.io.ci.jenkins.io Obviously, this will require some improvement in the Jenkinsfile, as we will have to delete the resources and secure the workflow, and also probably deploy a docker registry on the EKS cluster   Remark: My suggestions are just the results are recent thinking, considering that the current workflow is stable and the azure file storage only cost us 70$, I don't think it's worthwhile to work on that at the moment.    
          Hide
          halkeye Gavin Mogan added a comment -

          I'm on board with all of that except 2 issues

          1) I really really really don't like the fastly+nginx+azure thing, caching is weird a lot of the time, we get a bunch of sentry errors for people trying to download json files that don't exist on the cache
          I would like to see fastly => azure direclty, and each deploy we clear out fastly cache as needed

          2) I'm not trying to solve the big thing. I'm trying to make it so we can review PRs easily. Frontend PRs going back and forth asking contributors to post screenshots of specific things, or finding time to run a local instance, etc. Its doable, but ideally would love a temp copy.
          The easiest solution is to use surge (which has been around like 10 years) or azure websites. I forgot about azure websites. So ideally, create a new bucket in azure storage for PRs (we don't want anything to mess with the live install), and we just upload to a new PR directory each time. Make the entire bucket public, as there's no sensitive data, then https://plugins-jenkins-io-prs.web.core.windows.net/pr123/index.html gets commented on the pr, and done.

          If the PR deploy code breaks, lets say azure decides to shut down public websites, we are no worse off than we are now, which works. Infra isn't depending on it, its just something helpful for PRs

          Show
          halkeye Gavin Mogan added a comment - I'm on board with all of that except 2 issues 1) I really really really don't like the fastly+nginx+azure thing, caching is weird a lot of the time, we get a bunch of sentry errors for people trying to download json files that don't exist on the cache I would like to see fastly => azure direclty, and each deploy we clear out fastly cache as needed 2) I'm not trying to solve the big thing. I'm trying to make it so we can review PRs easily. Frontend PRs going back and forth asking contributors to post screenshots of specific things, or finding time to run a local instance, etc. Its doable, but ideally would love a temp copy. The easiest solution is to use surge (which has been around like 10 years) or azure websites. I forgot about azure websites. So ideally, create a new bucket in azure storage for PRs (we don't want anything to mess with the live install), and we just upload to a new PR directory each time. Make the entire bucket public, as there's no sensitive data, then https://plugins-jenkins-io-prs.web.core.windows.net/pr123/index.html gets commented on the pr, and done. If the PR deploy code breaks, lets say azure decides to shut down public websites, we are no worse off than we are now, which works. Infra isn't depending on it, its just something helpful for PRs
          Hide
          olblak Olivier Vernin added a comment -

          1) I really really really don't like the fastly+nginx+azure thing, caching is weird a lot of the time, we get a bunch of sentry errors for people trying to download json files that don't exist on the cache
          I would like to see fastly => azure direclty, and each deploy we clear out fastly cache as needed

           

          It sounds that your problem is invalidating Fastly cache more the nginx+azure, the nginx is only there to handle all the different redirection, the azure file storage is just a network storage mounted into the Nginx container.

           

          If we stopped building the jenkins.io website every 30min we could invalidate the cache each the website is built or if we build a docker image then we could invalidate the cache each time the "main" jenkins.io containers is restarted

          Show
          olblak Olivier Vernin added a comment - 1) I really really really don't like the fastly+nginx+azure thing, caching is weird a lot of the time, we get a bunch of sentry errors for people trying to download json files that don't exist on the cache I would like to see fastly => azure direclty, and each deploy we clear out fastly cache as needed   It sounds that your problem is invalidating Fastly cache more the nginx+azure, the nginx is only there to handle all the different redirection , the azure file storage is just a network storage mounted into the Nginx container.   If we stopped building the jenkins.io website every 30min we could invalidate the cache each the website is built or if we build a docker image then we could invalidate the cache each time the "main" jenkins.io containers is restarted

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            halkeye Gavin Mogan
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: