Docker-node: automate deployment

[MylesBorins]

How can we automate deployment of the docker images?

What steps are we currently doing manually?

Could we do this with actions?

/cc @mmarchini for her actions expertise

[mmarchini]

I think _some_ of it is automated already? Yesterday I logged into the bot account and saw some activity where the bot sends PRs to the official Docker image library. Seems like we could also automate bumping the Node.js versions when there's a new release.

Funny enough I wrote a script a couple weeks ago to fetch the latest versions of all maintained release lines:

'use strict'

import { default as nv} from '@pkgjs/nv';
import { default as semver } from "semver";
import { writeFile } from 'fs/promises';

const versions = (await nv('maintained')).map(obj => obj.version)
  .sort(semver.compare)

console.log(versions.join('\n'))

Could be adapted to whatever we need for this repository.

[mmarchini]

Actually, looks like the repository already has a script to update all images? https://github.com/nodejs/docker-node/blob/master/update.sh

If so, we could have a daily Action that runs the script, and if the repository has any changes pushes it and creates a PR (or just pushes to the default branch, whichever works best).

[SimenB]

Yeah, an action running the update script should be fine. One snag is that we need to wait for the musl builds to complete so we can get them from https://unofficial-builds.nodejs.org/download/release/. Usually they are available not long after the official builds (I think about an hour?). We should probably just make the update script fail if it's not available while official builds are.

At that point, the bot could auto merge green PRs and the usual build from master would open a PR (the last part is implemented today)

[SimenB]

Semi-related is #1194 which converts much of our CI from Travis to GH Actions

[SimenB]

Oh, and /cc @nodejs/docker

[mmarchini]

Just pointing out that adding a scheduler Action should be possible without #1194, especially since that's a long PR and the scheduler Action would probably be short.

[SimenB]

For sure, I just assume the action (or whatever) for auto-merging PRs would work better if it just checked that all other workflows passed successfully rather than pinging travis. I guess we can just check the status tho, so maybe there's no difference 🙂

[nschonni]

Took a quick kick at the cron action in https://github.com/nodejs/docker-node/pull/1314

[tianon]

Very much related to this, the current downstream automation periodically makes very poor PRs, and we'd like to see it either fixed or disabled before it makes any more.

See https://github.com/docker-library/official-images/pull/8281#issuecomment-651986085, https://github.com/docker-library/official-images/pull/8403#issuecomment-662160713, and https://github.com/docker-library/official-images/pull/8727#issuecomment-693461941 for notes, and https://github.com/docker-library/official-images/pull/7947 + https://github.com/docker-library/official-images/pull/7898 for further examples.

[SimenB]

We should probably go for squash merges, then we can make sure the commit message and commit body makes during merge and just re-use that as is for the upstream PR. Currently squash merges are disabled in this repo since they mess up the script (it looks for merge commits IIRC)

[nschonni]

@tianon is it just the PR titles, or is there something else about the PRs as well?

Was sketching out an action to use the pull_request closed event instead of push to master, so it can use the PR title

name: Create official images PR

on:
  pull_request_target:
    types:
      - closed
    paths:
      - "generate-stackbrew-*.sh"
      - "**/Dockerfile"
      - "**/architectures"

jobs:
  on_merged:
    if: github.event.pull_request.merged_by != ''
    runs-on: ubuntu-latest

    steps:
      - name: Checkout the docker-node repo
        uses: actions/checkout@v2
        with:
          path: docker-node

      - name: Checkout the official-images repo
        uses: actions/checkout@v2
        with:
          path: official-images
          repository: docker-library/official-images

      - name: Generate Stackbrew for diff
        run: |
          cd docker-node
          ./generate-stackbrew-library.sh > ../official-images/library/node

      - name: Generate Stackbrew
        run: echo ${{ github.event.pull_request.title}}

[tianon]

It's just the PR/commit titles -- otherwise the PRs are fine.

[ttshivers]

I might also investigate writing an cronjob action that auto creates PRs for new nodejs, yarn, and alpine versions.

[nschonni]

There are some pending PRs for that https://github.com/nodejs/docker-node/pull/1317 https://github.com/nodejs/docker-node/pull/1314, but for Yarn, it's only bumped during a non-security Node release https://github.com/nodejs/docker-node/blob/master/CONTRIBUTING.md#version-updates

A nice thing for syncing would be to parse the official images upstream to match the supported architectures

[ttshivers]

There are some pending PRs for that #1317 #1314, but for Yarn, it's only bumped during a non-security Node release https://github.com/nodejs/docker-node/blob/master/CONTRIBUTING.md#version-updates

I nice syncing with be to parse the official images upstream to match the supported architectures

Understood about the versioning of the yarn and npm and see the existing PR for alpine.

I don't quite understand what you mean by the last sentence.

[nschonni]

Sorry, didn't proof that obviously. Fixed it up, but I mean grabbing the architectures from the base image values like https://github.com/docker-library/official-images/blob/master/library/debian#L48

[ttshivers]

Sorry, didn't proof that obviously. Fixed it up, but I mean grabbing the architectures from the base image values like https://github.com/docker-library/official-images/blob/master/library/debian#L48

Is that what the architecture files are sourced from now? Are any arches filtered out based on node support?