Skip to content

Migrate unofficial builds to R2 #251

Open

Activity

  1. richardlau commented on Oct 2, 2026

    @richardlau
    Member

    Honestly speaking, unofficial-builds is way down the priority list for the Build WG (it is after all unofficial). Having said that the unofficial-builds machine currently:

    1. Hosts the webpages (i.e. main landing page) for https://unofficial-builds.nodejs.org/.
    2. Runs a webhook to rebuild the containers when this repository is updated.
    3. Runs a scheduled timer to build when Node.js releases come out.
    4. Hosts the downloads.

    I think 2 and 3 could potentially move to GitHub actions. If 1 and 4 can be done in a combination of R2 and the release worker and not require replacement Build WG servers then +1 from me. I think my only concern would be to separate out as much as possible from the official releases (i.e. do not reuse API keys/tokens between unofficial and official builds if possible).

  2. flakey5 commented on Oct 2, 2026

    @flakey5
    MemberAuthor

    I think my only concern would be to separate out as much as possible from the official releases (i.e. do not reuse API keys/tokens between unofficial and official builds if possible).

    +1, I was thinking a dedicated unofficial-builds bucket for them. Also, just making sure, are there any symlinks used when hosting the downloads?

  3. flakey5 commented on Oct 2, 2026

    @flakey5
    MemberAuthor

    Idk if this is worth but given the current setup for the build scripts is rather single server & docker centric + the low priority on this, wdyt of pausing new unofficial builds, copying the current downloads to an r2 bucket, and decommissioning the server to free up credits for www? Then can later work on getting new builds working again through whatever works best

  4. nschonni commented on Oct 2, 2026

    @nschonni
    Member

    Docker Apline has not changed over to the official builds yet. I'd discurage any "temporary" moves without proper planning and understanding the impacts

  5. nschonni commented on Oct 2, 2026

    @nschonni
    Member

    I'll try to push forward nodejs/docker-node#2621 that will hopefully lessen any issues with the cutover, but I think we're still talking about after the next set of Node.js releases

  6. MikeMcC399 commented on Oct 4, 2026

    @MikeMcC399
  7. rvagg commented on Oct 5, 2026

    @rvagg
    Member

    We can retire it too, the only hard dependency that would need to be solved is the docker images, but they can build it themselves. Mostly this is just a convenience service for people with niche architectures, but having had to retire armv6l and x86 it's a poorer version of its once useful self IMO.

  8. flakey5 commented on Oct 5, 2026

    @flakey5
    MemberAuthor

    Could you clarify please if the URL scheme:

    If migrated to the release worker yes, a requirement for it is no breaking changes for the client

  9. MikeMcC399 commented on Oct 6, 2026

    @MikeMcC399
  10. nschonni commented on Oct 25, 2026

    @nschonni
    Member

    All the current release lines are now using the official builds, so there shouldn't be any impact to docker-node by the migration now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions