Posts tagged: just

[1] Astral uses just in CI, kinda cool to stumble into this setup in the wild. run: just release-run ${{ secrets.GITHUB_TOKEN }} ${{ github.event.inputs.sha }} ${{ github.event.inputs.tag }} And her is the accompanying justfile. you can see how it accepts arguments, and starts calling out to other just recipes. release-run token commit tag: #!/bin/bash set -eo pipefail rm -rf dist just release-download-distributions {{token}} {{commit}} datetime=$(ls dist/cpython-3.10.*-x86_64-unknown-linux-gnu-install_only-*.tar.gz | awk -F- '{print $8}' | awk -F. '{print $1}') just release-upload-distributions {{token}} ${datetime} {{tag}} just release-set-latest-release {{tag}} Note This post is a thought [2]. It’s a short note that I make about someone else’s content online #thoughts References: [1]: /static/https://github.com/astral-sh/python-build-standalone/blob/main/.github/workflows/release.yml [2]: /thoughts/

Testing fresh nvim installs can be a pain, and hard to di without borking your known good install. I’ve been using NVIM_APPNAME to run a test nvim in a sandbox that wont bork my main install. This usually runs for me in under a minute, can be down under 15s if I remove some of the TreeSitter installs at the end. This beats a full docker build of my full devtainer to test out nvim packaging woes. rm ~/.cache/wwtest -rf rm ~/.local/share/wwtest -rf rm ~/.config/wwtest -rf cp -r nvim/.config/nvim/ ~/.config/wwtest NVIM_APPNAME=wwtest nvim --headless "+Lazy sync" +qa NVIM_APPNAME=wwtest nvim --headless "+TSUpdateSync" "+sleep 5000m" +qa NVIM_APPNAME=wwtest nvim --headless "+MasonUpdate" +qa NVIM_APPNAME=wwtest nvim --headless "+TSInstallSync! c cpp go lua python rust tsx javascript typescript vimdoc vim bash yaml toml vue just" +qa NVIM_APPNAME=wwtest nvim --headless "+MasonInstall lua-language-server rustywind ruff ruff-lsp html-lsp typescript-language-server beautysh fixjson isort markdownlint stylua yamlfmt python-lsp-server" +qa NVIM_APPNAME=wwtest nvim I’ve started to use this as a just recipe to run before deploying a new version of my dotfiles. So far its pairing nicely with...

GitHub - casey/just: 🤖 Just a command runner 🤖 Just a command runner. Contribute to casey/just development by creating an account on GitHub. GitHub · github.com [1] new versions of just now come with color variables already set. [group('manage')] version: #!/usr/bin/env bash version=$(cat version) echo current version {{BOLD}}{{GREEN}}$version{{NORMAL}} Note This post is a thought [2]. It’s a short note that I make about someone else’s content online #thoughts References: [1]: https://github.com/casey/just?tab=readme-ov-file#constants [2]: /thoughts/

pipely/justfile at main · thechangelog/pipely I like the idea of having like this 20-line Varnish config that we deploy around the world, and it’s like: Look at our CDN! - thechangelog/pipely GitHub · github.com [1] I found this nugget in thechangelogs justfile, it lets you add color to your justfile with variables quite easily. # https://linux.101hacks.com/ps1-examples/prompt-color-using-tput/ _BOLD := "$(tput bold)" _RESET := "$(tput sgr0)" _BLACK := "$(tput bold)$(tput setaf 0)" _RED := "$(tput bold)$(tput setaf 1)" _GREEN := "$(tput bold)$(tput setaf 2)" _YELLOW := "$(tput bold)$(tput setaf 3)" _BLUE := "$(tput bold)$(tput setaf 4)" _MAGENTA := "$(tput bold)$(tput setaf 5)" _CYAN := "$(tput bold)$(tput setaf 6)" _WHITE := "$(tput bold)$(tput setaf 7)" _BLACKB := "$(tput bold)$(tput setab 0)" _REDB := "$(tput setab 1)$(tput setaf 0)" _GREENB := "$(tput setab 2)$(tput setaf 0)" _YELLOWB := "$(tput setab 3)$(tput setaf 0)" _BLUEB := "$(tput setab 4)$(tput setaf 0)" _MAGENTAB := "$(tput setab 5)$(tput setaf 0)" _CYANB := "$(tput setab 6)$(tput setaf 0)" _WHITEB := "$(tput setab 7)$(tput setaf 0)" Usage echo: echo {{_BOLD}}{{_GREEN}}hello there{{_RESET}} Note This post i...

Safer Bash Shebang Recipes - Just Programmer's Manual just.systems [1] When using justfiles each line is ran separately from the last, unless you specify the file to be ran by something other than just such as bash. If you want variables to persist you need to set a shebang. Also if you are using your script i a way that you want it to exit when it fails you need to set -e and -o pipefail. This is critical if you are thinking about using just for production scripts like ci/cd. I’ve hit too bugs where ci passes, but no artifacts were created issues for this exact reason. foo: #!/usr/bin/env bash set -euxo pipefail hello='Yo' echo "$hello from Bash!" Note This post is a thought [2]. It’s a short note that I make about someone else’s content online #thoughts References: [1]: https://just.systems/man/en/safer-bash-shebang-recipes.html?highlight=pipefail#safer-bash-shebang-recipes [2]: /thoughts/