https://github.com/fonsp/js-julia-artifacts-test-1
https://github.com/fonsp/js-julia-artifacts-test-1
Last synced: 4 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/fonsp/js-julia-artifacts-test-1
- Owner: fonsp
- Created: 2022-02-23T21:24:14.000Z (over 4 years ago)
- Default Branch: main
- Last Pushed: 2022-02-24T16:37:55.000Z (over 4 years ago)
- Last Synced: 2025-10-26T05:59:05.800Z (7 months ago)
- Language: Julia
- Size: 59.6 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# js-julia-artifacts-test-1
This Julia package contains a folder `frontend/` with unbundled JS files. You can run `bundle_frontend.sh` to bundle it, creating a `frontend-dist/` folder. (Right now it's a simple `deno bundle`, but it could be anything, like `npm run build`.)
Because this contains binary outputs, we want to `.gitignore` it. But when releasing a new version of our package, we need the folder, panic!
The solution (suggested by @staticfloat) is to use a combination of GitHub Actions, GitHub releases (on a [dummy repository](https://github.com/fonsp/js-julia-artifacts-test-2)) and Julia Artifacts. It works!
# How to release
## Step 1
Change the version number in Project.toml. Make a commit that you want to release.
## Step 2
Go to [Actions](https://github.com/fonsp/js-julia-artifacts-test-1/actions), then to the [Bundle action](https://github.com/fonsp/js-julia-artifacts-test-1/actions/workflows/prepare-release.yml). Dispatch the workflow.
## Step 3
Wait for a GitHub notification to come in (you will be `@mentioned`). Follow the instructions!
A commit was created on a separate branch with the bundled frontend included as artifact! Ready to release :)
# How does it work?
All of the magic is in our [GitHub action](https://github.com/fonsp/js-julia-artifacts-test-1/blob/main/.github/workflows/prepare-release.yml). It does the following:
1. Run the `frontend_bundle.sh` script.
2. Archive the output folder to create `frontend-dist.tar.gz`
3. On a dummy repository (https://github.com/fonsp/js-julia-artifacts-test-2), a dummy release is created and this tarball is uploaded as release binary. ([Example release](https://github.com/fonsp/js-julia-artifacts-test-2/releases/tag/hello-from-ff76e0a0f3b9ffe8b25a9deef9f2b81feb8b1522))
4. Using [ArtifactUtils.jl](https://github.com/simeonschaub/ArtifactUtils.jl), an Artifacts.toml file is created/updated to include this release download URL as dependency, with the right hashes. ([Example (old example from the wrong branch)](https://github.com/fonsp/js-julia-artifacts-test-1/blob/95f3cd3758eac79822bded602ec7e7bd2df955cb/Artifacts.toml))
5. We `git checkout` the `bundled` branch, and do `reset --hard` to make it exactly match `main` (or whatever branch you triggered the workflow from), removing any old commits.
6. A new commit is added with the new Artifacts.toml file.
7. The bot writes a comment on that commit, tagging the `actor` who initiated the action, with instructions to release. ([Example (might be garbage-collected in the future)](https://github.com/fonsp/js-julia-artifacts-test-1/commit/f0726fce57ba51c1dbf1a7cb315c2b3b37f624a0))
For more info, see the [workflow file](https://github.com/fonsp/js-julia-artifacts-test-1/blob/main/.github/workflows/prepare-release.yml).
## About `reset --hard`
Doing `reset --hard` on the `bundled` branch means that we can use any branch as the original, not just `main`.
This means that old bot-generated commits will be removed, leaving them "dangling" without a branch, and git will eventually garbage-collect them. However! If I release that dangling commit, a git tag will be created (by tagbot), so it will never be removed!
## Why not commit back to the original branch?
Why not commit the Artifacts.toml back to the original branch (i.e. `main`)? Commiting back to `main` would leave the outdated Artifacts.toml file hanging around, even if the `frontend` folder is changed afterwards. With the current strategy, you either have a "development commit", on the `main` branch, which does not have the bundle, or a "release-ready commit", which does.
Well... I'm not sure which is better!
## How to ensure that you always release a bundle?
This is still TODO: on Pluto.jl we run an additional test on the bundle branch, which does not have internet access, to verify that we have offline support.
In this setup, we should test that the artifact exists and that it works.