Release bot

[tfiers]

(no, tagbot etc no good enough)
(they good to steal from ('built upon') though)
automate steps of devguide release guide.

a cool badge for readme:

moar

[tfiers]

Actually those badges would be perfect in the gh release descr

EDIT: used it here: https://github.com/tfiers/PkgGraph.jl/releases/tag/v0.5.0

[tfiers]

did some research on writing custom actions.
ofc don't even really need one, could create a new workflow with just lotsa bash, or even python.
(and then later factor out, for other repos).

Links:

• 14' youtube tutorial: https://www.youtube.com/watch?v=jwdG6D-AB1k
  • javascript file that calls bash. hah.
  • says there's two ways 'to deploy': commit node_modules/; or 'compile' (transpile?) your custom js together with it's deps
    (const core = require('@actions/core') -- which is a registerd npm module). (Result is an eldritch soup).

https://github.com/julia-actions/RegisterAction/blob/master/register.js
did the former (commit node_modules/)

docs: https://docs.github.com/en/actions/creating-actions

[tfiers]

a template for a custom action: https://github.com/github-developer/javascript-action

[tfiers]

So if I'm correct, using an action in a workflow just needs it to be public on github; and the gh actions server clones the code from there?
I.e. not needed to 'Publish your action on Marketplace'

[tfiers]

Example of compiled: https://github.com/actions/javascript-action/blob/main/dist/index.js
it does have a sourcemap, so that's good.

action.yml indeed calls runs: using: 'node16', main: 'dist/index.js'

I like the codeowners thing btw

From package.json: "scripts": { "prepare": "ncc build index.js -o dist --source-map --license licenses.txt"
So ncc. https://github.com/vercel/ncc

[tfiers]

(tagbot is written in Python, and runs as action in docker)

[tfiers]

How long does it take from initial comment to tagbot ran?

• 10:33 c7b98e7#commitcomment-96164755
• 10:57 merge New version: PkgGraph v0.5.0 JuliaRegistries/General#75675 (24 minutes)
• 10:59 TagBot trigger issue #15 (comment)

so 26 minutes total

(tagbot here ran in just 20 seconds: https://github.com/tfiers/PkgGraph.jl/actions/runs/3917984856

but where is my draft release?)

ah: "GitHub returned a 5xx error code" (annotations of the run)

github.GithubException.GithubException: 502 {"message": "Server Error"}

manual "re-run all jobs"

hm, same error

[tfiers]

So, high-level overview of what our javascript should do, from the devguide:

The release commit:

• In Project.toml, remove the -dev suffix from version.

  • Read a file, regex search (or just dumb, first line starting w/ version = "), str subst, write to file

• Roll-over Changelog.md:

  • Add a commented-out section above the new release, for the next
    version.

    • Some logic to increase vX.Y.Z; or have user input it! Cause we don't know if minor/major/patch bump

  • Move the 'unreleased' badge to the commented out section. Replace with a new
    'released' badge and link, in analogy with previously released versions.

    • More of same

• Commit the above

  • no doubt standard thing in js actions

• ..and comment on this commit on GitHub
  with @JuliaRegistrator register. (This opens a PR in the General registry)

  • js lib for gh api

Before we move on to the next commit, we should make the release on github.
Otherwise the

• "xx commits to main since this release" #68

link in release won't work. (Release/tag must be for branch (main), not commit).

• Gather closed issues and PRs since last release
  • More of that gh api: last release; date of a release; PRs and issues by date

Our js script file could live just in .github/workflows/, btw

Also for the nice badge: we need link to created PR.
So we need to monitor the comment thread started above.
(Can be synchronous: @JuliaRegistrator answers quickly)

In the next commit:

• In Project.toml, bump the relevant version component, and add -dev again.
• In Changelog.md, uncomment the next version's section. ("Changes: none yet")
• If this is the first release, update the 'Installation' section of the ReadMe.
• Optionally add a temporary warning, that the newest release is not yet available for
  install from Genereal (but will be soon). Link to the PR.

(More of same: string replacement)

When the PR is merged:

Here we need to get a signal.
(tagbot has this interesting "trigger issue setup". But it is also the actor in the General registry repo, who closes the PR).
Maybe we can listen for same :) i.e. maybe

• TagBot trigger issue #15

gets updated by the tagbot actor in General, and is the tagbot here just a listener (that we can disable). (Will the actor still send if disabled here?).

• The TagBot github action will automatically run, and create a git tag for the commented-on commit above.
  • This will also trigger a DocBuild run, creating a new directory for the tagged version on the gh-pages branch.
• If this is the first release, update the 'Installation' section of the ReadMe again.
• Remove the temporary warning and PR link.

I think the Docs.yml runs on the tag, so should still work.

[JuliaRegistrator]

Error while trying to register: "Pre-release version not allowed"

[tfiers]

This is tagbot [in my repo] code: https://github.com/JuliaRegistries/TagBot/blob/master/tagbot/action/__main__.py

(yml here: https://github.com/tfiers/PkgGraph.jl/blob/main/.github/workflows/TagBot.yml)

nothing about creating issues.
Maybe in General/ci?
Yeah could well be this: https://github.com/JuliaRegistries/General/blob/master/.github/workflows/TagBotTriggers.yml
which triggers on merged PR (correct). Runs using RegistryCI.TagBot; TagBot.main()

[tfiers]

Here we go: https://github.com/JuliaRegistries/RegistryCI.jl/blob/master/src/TagBot/TagBot.jl
Question is still: will it still work if I delete my TagBot.yml here
At least we now know this guy (remote actor) created the first issue ("This issue is used to trigger TagBot; feel free to unsubscribe")

[tfiers]

Aha, this is the check :)
https://github.com/JuliaRegistries/RegistryCI.jl/blob/master/src/TagBot/TagBot.jl#L60
So any file (in .github/workflow/), but it must contain the string "JuliaRegistries/TagBot".

• maybe_notify

the issue_comments flag is a red herring. It is false, so that line is irrelevant (we indeed have "issue_comment" in our file; but the line is not run).
[search].
so, weird name, and irrelevant

The JuliaRegistries/TagBot contains check is really the only thing :)
So let's hack

[tfiers]

A 'manual' link to diff with previous is nice, actually: https://github.com/simonp0420/PkgOnlineHelp.jl/releases
(yes there's the compare button. but requires loading new page from releases overview (specific release), finding gray 'Compare' button in top right, and then picking sth in dropdown) (link is the same though)

[tfiers]

• Read a file, regex search (or just dumb, first line starting w/ version = "), str subst, write to file

So there's three ways already: https://nodejs.dev/en/learn/writing-files-with-nodejs/

• fs.writeFile(), with callback function for when done. in which you check if (err)
• fs.writeFileSync() (which throws err)
• await fs.writeFile(). same, throws err.
  • but now fs is from const fs = require('fs/promises');, not const fs = require('fs')

[tfiers]

Nice overview of links into mdn for learning modern js syntax:
https://nodejs.dev/en/learn/how-much-javascript-do-you-need-to-know-to-use-nodejs/#what-is-recommended-to-learn-before-diving-deep-with-nodejs

---

Interesting, js is JIT compiled: https://nodejs.dev/en/learn/the-v8-javascript-engine/#compilation
(so a combo of interpreted and JIT compiled. Type inference then?). (Node is written in C++). (LLVM for the web?) (node is not web)

WASM deepdive

on WebAssembly (https://nodejs.dev/en/learn/nodejs-with-webassembly/). My understanding from twitter etc is that WASM is fast; but data marshalling is slow, and if you want to interact with the user, that needs to happen.
(ah, I saw this indeed: https://news.ycombinator.com/item?id=30156437)

WebAssembly modules cannot directly access OS functionality on its own. […] → WASI API to access the OS functionality.

("LLVM for the web" above: ig Node JIT has its own internal IR. Related: wasm and llvm? → https://webassembly.org/docs/faq/ / "Why not just use LLVM bitcode as a binary format?")

WASI: A system interface to run WebAssembly outside the web.
Why: Developers are starting to push WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines.
But we don’t yet have a solid foundation to build upon. Code outside of a browser needs a way to talk to the system — a system interface. And the WebAssembly platform doesn’t have that yet.

(https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/)

WASI stands for WebAssembly System Interface. It's an API designed by the Wasmtime project that provides access to several operating-system-like features, including files and filesystems, Berkeley sockets, clocks, and random numbers, that we'll be proposing for standardization.

(https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md)

"CG" in wasm jargon means Community Group. https://webassembly.github.io/cg-charter/

[tfiers]

TS: https://nodejs.dev/en/learn/nodejs-with-typescript/

so you need to compile it, npx tsc example.ts
it prolly compiles to .js. So where do those live? Is there src map? (well, I keep forgetting we're not in browser, so I have access to src code)
Do you then need to separately run those js? (sth like node build/main.js)
Nothing jumps out in docs! ah ok, here: https://www.typescriptlang.org/docs/handbook/2/basic-types.html

ig TS decision y/n depends on how much better the IDE experience is.

---

What I want is live repl experience (like julia-vscode with file and repl and alt-enter, or prolly like clojure).
also kinda like browser devtools.

so is that possible in vscode? and w/ typescript?

Ok this seems good: JavaScript REPL - Visual Studio Marketplace (which yes has TS support too)
surprisingly new and unknown! https://stackoverflow.com/questions/55829739/vscode-run-javascript-file-line-by-line-like-repl
(unless I'm searching for wrong keywords)

weird that not open source.
the prior art / competitor: https://quokkajs.com/
small prior art: https://github.com/axilleasiv/vscode-javascript-repl-docs

ah, and then, of course, there's https://observablehq.com/

node has repl yes. you can prob include files there. but then no typing code in editor.

maybe you can do some weird workflow with browser devtools that lets you edit a js 'file' (w/o reloading page)

[tfiers]

Where to put this code. New repo is cleaner cause it's not just the .js or .ts file
there's also either the npm_modules dir, or a compiled file
-- well if I'm experimenting it's fine to gitignore those
but if using as gh action, then one of either of those ugly non-human readable things must be committed

so. I'll do directly in new repo, to not soil this repo with kilobytes of gibberish

(I could do the npm-install inside the action/workflow sure; then no commit of gibberish necessary.
then js would live in: .github/worfklows/release.js. Or, if not gh, scripts/? misc/?)
no, it's partly gh specific, with the release notes and issues and whatnot

---

but yeah, a pre-compiled/built/resolved script is better: faster run and less energeia

---

so, I'll do in new repo; but a dumb one; and no pre'compile'/'linking' necessary yet.

for data-to-act-on, can hardlink to PkgGraph
or copy-in relevant pkggraph files as testcase, good for later automation

where to put on disk. it's a js proj.. Somewhere in ~ root mayb ig. w/e. I have sth like ~/archive for later (or just delete, ofc. it's archived on gh)

[tfiers]

For the steps (#72 (comment)):
no commented out sections and uncommenting sections needed.
Just add when needed. (In step two, namely)
Advantage: new version (which component to bump) not needed in step one anymore.

Actually step two could be manual. And then yes, step one adds a commented-out section; just without a version yet.
The user then sets the new version (with also -dev) in Project.toml, and puts it in the header of the new section in Changelog.md added by the bot (and uncomments it)

So ok, step 1:

• Project.toml: remove -dev from version
• Changelog.md
  • change badges for section being released
    (from 'unreleased', to current date and tag link that will soon exist)
  • add commented out new section (versionless now)
• commit
• comment on commit
• draft gh release

Step 2 is manual.
(accept the gh release draft (includes tag, for main branch); and new version, with -dev, in both project and changelog, and commit)

Step 3:

• [ ] Get triggered by merged General PR ("TagBot")
• .. actually.
  We don't need to do anything!
  The tag is already created; and docbuild CI builds on a git tag.
  So yeah, if we tag, it kinda makes sense we don't need 'TagBot'