Open deer opened 9 months ago
Hmm that would be great. What happened yesterday is that I accidentally made a new 0.4.28
release without having merged my PR. So automating this would help avoid these silly mistakes. The release flow is currently manual, I made it a bit easier with a deno task release X.Y.Z
task, so it would be great to have it in CI. Great, feel also free to assign yourself when you want to tackle something 👍🏼
Notes from discussion with @deer: something like the the following could be brought together into the current tasks/release.ts
task or into a single github worfklow under .github/workflows/release.yml
:
{
"tasks": {
"version:increase": "deno run --allow-read=src/versions.json --allow-write=src/versions.json src/utils/increase_version.ts",
"version:latest": "deno run --allow-read src/utils/latest_version.ts"
}
}
// tasks/increase_version.ts:
import { ReleaseType } from "../deps.ts";
import { increaseVersion } from "../version.ts";
increaseVersion(Deno.args[0] as ReleaseType);
// tasks/latest_version.ts:
import { getLatestVersion } from "../version.ts";
console.log(getLatestVersion());
Maybe unjs/magicast
, a library to programmatically modify JavaScript and TypeScript source codes with a simplified, elegant and familiar syntax powered by recast and babel, can be useful.
0.4.28 broke CI due to formatting. But what if it also broke the (currently non-existent) tests?
Ideally there would be a github action that can be triggered via the UI that releases a new version. I'll look into this since I want to learn more about automating projects.
Second followup item from https://github.com/netzo/netzo/pull/95.