v3 roadmap
axetroy opened this issue · comments
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
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.
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.
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.
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;
}This also might be useful. https://github.com/marketplace/actions/github-graphql-api-query
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
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?
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.
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.
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
