Add Julia test to CI workflow

[Felix-Gauthier]

ref: #18 (comment)

[etpinard]

Great. Thanks for doing this!

There's one problem with adding this test that I just realised this morning.

According to the current release checklist, we npm run build then we git push before running npm publish. That is, the "new" build artifacts namely

https://unpkg.com/dash-textarea-autocomplete@$(version)/deps/deps.tar.gz

will not be available during the CI test run that follows the git push and that test run will fail ❌

Maybe there's a way to cleverly reorder the release checklist to make the git push run pass.

Or, maybe we could "move" this julia test out of the CI workflow and into the release checklist itself after the npm publish step but before the @JuliaRegistrator step 🤔

[Felix-Gauthier]

Or, maybe we could "move" this julia test out of the CI workflow and into the release checklist itself after the npm publish step but before the @JuliaRegistrator step 🤔

Yeah, but at that point we're already committed to the release, so if it fails 😕 ...

[Felix-Gauthier]

Whe might want to use an Overrides.toml file instead to point to a local resource ?

[etpinard]

Yeah, but at that point we're already committed to the release, so if it fails

Right, but you could say the same about

---

I think what we want to avoid at all cost is to publish a non-working package over npm, pypi, the julia general registry and pushing non-working git-tag over to the Github releases.

That said, making a "wrong" version commit (i.e. git commit -m "X.Y.Z") and pushing it the github with git push isn't that bad. We can always add another version commit on top of the tree once things work.

So, it would be nice to find a way to test the julia package with the updated Artifact.toml before publishing.

[Felix-Gauthier]

So, it would be nice to find a way to test the julia package with the updated Artifact.toml before publishing.

It's a catch 22 -- can't test without publish, can't publish without test 😋

I still think Overrides.toml might have potential : if we can point to a local resource we can make sure the .tar assets are good with the provided sha hashes for Julia. From there we can assume that the url will be valid when published

[etpinard]

It's a catch 22 -- can't test without publish, can't publish without test

Right. That's why I have doubt about using Artifacts for a project like this one, where the non-julia files are "source" files not just "assets" (i.e. artifacts).

Like mentioned in #20, if RelocatedFolders.@path were a stdlib export, then we wouldn't be having this debate. Development, testing and publishing would be friction-less, but it is worth adding a "0.x" dep to this project?

[Felix-Gauthier]

I side-stepped the potential invalid url issue in 5d98d56 by pre-setting up the artifact directory (so no download gets triggered)

Override.toml turned out to only work if the artifacts have been previously installed, so that was a dead end.

The disadvantage with this solution is that we'll never test the url, even if it's valid.

[Felix-Gauthier]

we could use Downloads for that though, on failure, extract deps manually.

[Felix-Gauthier]

5d98d56 seemed to have been failing because I was screwing around with force-push yesterday evening. Seems good now with the clean rev hash on 7f93a11

[Felix-Gauthier]

We can now either :

• Add a 'test install' step after publishing on npmjs in CONTRIBUTING.md
• Have a if/else statement in this to test the url and extract the deps when it's invalid

I like option#2 a bit less because it amounts to not really testing the url anyways (it'll always work with the 'hack' in the CI) we should rely on that manual test in the post-publish step IMO

[etpinard]

We can now either :

I would do neither.

(1) Testing the Julia package after the npm publish step manually won't really help as:

• that's already part of the tests on the JuliaRegistries/General PR
• catching the mis-publish before calling the julia registrator bot does really help us, as we would still need to register the broken release as JuliaRegistries/General doesn't allow us to release non-sequential versions.

(2) Setting an if/else for downloading the artifacts from the url isn't that great either. Let's say we make a PR that adds a features in the JS code, this proposed test would then attempt to grab an outdated JS file from the previous published version. So we would essentially test something that will be replaced once the feature is released 🙃

So, I'd say we merge this PR as is (maybe with some additional comments in the workflow file) and let the JuliaRegistries/General PR tests do their job. If the tests fail there then yes it's annoying, but at least now we figured out a (non-so-elegant but working) way out of it now part of the CONTRIBUTING.md file.

The test added in is still very useful as it checks that there are no mistakes make by the postbuild_fixups.sh script in the src/DashTextareaAutocomplete.jl file.

[Felix-Gauthier]

I agree with your (1) and (2) points. I'll add comments to the workflow soon.

[etpinard]

Great !