v3 roadmap

[axetroy]

In these iterations

In addition to the BUG fix, there is another point is to getting versions information

Github Apis has a rate limit, So we can't get version information via it.

~v1~:

In this version, we created a release.json to mark which versions of deno

But its shortcomings are obvious

This file needs to be updated whenever Deno releases a new version

It is not automated

v1 has been deprecated

v2:

Currently reading https://raw.githubusercontent.com/denoland/deno/master/Releases.md file

Because Deno updates this file every time it is released

So you can get all Deno versions

But this is not a solution

Because you don't know when this file will change rules or rename or delete

v3:

So we need a more stable way to get versions information

EDIT:

We will use the version file provided by the dneoland official, and the minimum supported Deno version is v1.0.0.

This version will be released on June 1, 2021, at the latest

[cj81499]

Is there a way to make GitHub API requests based on the user's API key, rather than our own?

If not, perhaps it is worth reaching out to the Deno team and asking if they have any suggestions.

[cj81499]

Would it be a problem for setup-deno to use this query? I'd expect the rate limit to not be a concern, since the queries will be made by users, and exceeding the limit of 5000 would be difficult. Plus, maybe we could cache the results for some duration?

query denoReleases {
  repository(name: "deno", owner: "denoland"){
    releases(first:100){
      nodes{
        tagName
        id
      }
      pageInfo{
        hasNextPage
        endCursor
      }
    }
  }
  rateLimit{
    limit
    cost
    remaining
    resetAt
  }
}

Alternatively, we could create a GitHub action to update the release.json file every hour or so? It'd be better if we could do this via webhook, but we can't create webhooks on the deno repository.

[axetroy]

Would it be a problem for setup-deno to use this query? I'd expect the rate limit to not be a concern, since the queries will be made by users, and exceeding the limit of 5000 would be difficult. Plus, maybe we could cache the results for some duration?

Using Github Api in Github Action will still be considered as the same user, so it will be restricted.

Alternatively, we could create a GitHub action to update the release.json file every hour or so? It'd be better if we could do this via webhook, but we can't create webhooks on the deno repository.

SGTM. But it may not be updated in time.

[maximousblk]

maybe this could work but I'm not sure.

// src/setup-deno.ts

async function run() {
  try {
    let version = core.getInput("version");
    let token = core.getInput("token");
    if (!token) {
      throw new Error("GITHUB_TOKEN not found!");
    }
    if (!version) {
      version = core.getInput("deno-version");
    }
    if (version && token) {
      await installer.getDeno(version, token);
    } else {
      throw new Error("No version specified.");
    }
  } catch (error) {
    core.setFailed(error.message);
  }
}

// src/installer.ts

export async function getAvailableVersions(token: string): Promise<string[]> {
  const tags: string[] = await fetch(
    "https://api.github.com/repos/denoland/deno/tags",
    {
      headers: {
        "Authorization": `token ${token}`,
      },
    },
  )
    .then((response) => response.json())
    .then((data) => {
      return data.sort(function (a: any, b: any) {
        semver.compare(a.name, b.name);
      });
    });
  return tags;
}

[cj81499]

This also might be useful. https://github.com/marketplace/actions/github-graphql-api-query

[axetroy]

update:

I have set up a release server https://deno-release.now.sh

Apart from the inability to provide downloads (CDN restrictions), everything seems to be fine and can be used as an alternative

[cj81499]

Looks nice!

Is the source code available somewhere?

How does the release server get its info? (Does it cache the results of the github api? Does it parse the README file? etc)

It might be nice to return key value pairs of version: download_url, rather than just an array of version numbers?

How does the /release/download endpoint work?

[maximousblk]

@cj81499 deno_release_api

[maximousblk]

Deno is also published on deno.land/x at deno.land/x/deno so there is an (undocumented) API endpoint which lists the deno versions at https://cdn.deno.land/deno/meta/versions.json. But I think this is also when a new tag is created (using webhook) and would cause the same problem as the current solution, but it would prevent scraping the CHANGELOG.md file and would be immune to changed format.

But I still think that using the user's API key (auto-generated) for the API requests should be the solution for v3.

[lucacasonato]

Best solution is to query https://raw.githubusercontent.com/denoland/deno_website2/master/versions.json. We keep that file up to date manually, and it is updated after the release. So the binaries will definitely be ready when the version is listed in that file.

[axetroy]

Best solution is to query denoland/deno_website2@master/versions.json (raw). We keep that file up to date manually, and it is updated after the release. So the binaries will definitely be ready when the version is listed in that file.

This is pretty good.

However, since this file does not record versions before 0.34.0, all versions are currently supported.

This is a breaking change. To be safe, I think it should be kept for a period of time before updating.

This shouldn’t be too long, at most half a year

[zhmushan]

We should replace "nightly" with the official canary channel @axetroy :

steps:
  - uses: denolib/setup-deno@v3
    with:
      deno-version: 973af61d8bb03c1709f61e456581d58386ed4952
      deno-canary: true