Jump to content

Wikimedia Release Engineering Team/Deployment pipeline/2018-09-27

From mediawiki.org

Last Time

[edit]

General

[edit]

Zotero

[edit]
  • Marko: is there an ETA for when this can be used for Citoid in production
  • Alex: we need to create a helm chart -- will likely have ready within the next 2 weeks
  • Marko: do we need to add additional packages within the base nodejs10 image?
  • Alex: if you have the packages you need and how they are installed then let's shoot for that.
  • Marko: Can we redo base images and get zotero out in parallel? i.e. write helm charts first to get zotero out and  then modify nodejs base image
  • Alex: sure, but we need to ensure that they are trackable via debmonitor
  • Marko: npm vs debian packages -- there may be problems -- service-runner, as it dockerizes services, it adds a list of packages
  • Thcipriani: we allow you copy a file into the workspace before npm install
  • to generate the dockerfile with the currently added npm packages: server.js --builddockerfile
  • TODO: create task to talk about how to track and install additional npm packages for all services


RelEng

[edit]
  • Q2 Goals posted (graphoid, blubberoid, zotero2)
  • Saw we have a zotero2 repo (thanks Alex!)  https://gerrit.wikimedia.org/g/mediawiki/services/zotero
    • I can get this setup of CI Soon™
    • How does this mirror and in which direction?
      • Doesn't. I just cloned from github and pushed to gerrit
      • Does it need to mirror in some direction?
      • Marko: no, we will need a build repo anyway
      • Dan: could put this kind of thing in the base wikimedia image directly
      • Marko: we do use this for every service, so putting this in the base image might make sense
      • Alex: It sounds like we will need a standard set of things: repo in gerrit, .pipeline
      • Thcipriani: we could mirror from upstream and keep .pipeline as a branch
      • Alex: we're going to likely need to make patches on top of upstream that won't be accepted upstream likely -- example: swagger specs
      • Marko: we could continue manually doing this work for a while, while we come up with a solution that fits
  • Support a literal body for POST requests in `fetch_url`
    • Could use a look -- tested with mathoid, retains existing functionality



SREs

[edit]

Services

[edit]

As Always

[edit]