horse666

This is really cool, looking forward to trying it out.

Obligatory mention of Neon (https://neon.com/) and Xata (https://xata.io/) which both support “instant” Postgres DB branching on Postgres versions prior to 18.

Aurora clones are copy-on-write at the storage layer, which solves part of the problem, but RDS still provisions you a new cluster with its own endpoints, etc, which is slow ~10 mins, so not really practical for the integration testing use case.

Related https://github.com/jdx/hk/, from jdx, the author of Mise.

No worries, thanks!

Nice work @jdxcode, this looks great.

Is there any functionality in this release that might help with or be useful in features for sharing Mise config/tasks _across_ repos?

And do you have any thoughts on that idea in general?

https://github.com/jdx/mise/discussions/4562

I don’t understand what you mean, sorry. If you are manually copying a password, then you are not using passkeys? There is nothing to copy/accidentally leak with passkeys.

I guess it will be a while before passkeys are the _only_ option that websites accept

Phishing protection? Unlike passwords, passkeys are bound to a domain.

Great, thanks for confirming

Hi @tudorg - do the Xata copy-on-write branches work like Neon in that you effectively get an isolated Postgres cluster, allowing you to test roles, extensions, creating/dropping DBs, altering schema & data of existing DBs, etc? I looked in the docs but it wasn’t clear to me.

Obligatory mention of https://raindrop.io/

I switched from Pinboard a year or more ago after using it for many years, mainly because I found the iPhone app and integration (eg share feature, to save bookmarks) to be flaky.

Raindrop has been great - imported seamlessly from Pinboard and the iPhone and Desktop app work well for me.

Until Neon can fix that, I found it on the Wayback Machine - https://web.archive.org/web/20240524181543/https://neon.tech...

Yes, also definitely a big vote for Mise.

I’ve switched recently from asdf for managing language & tool versions and the ergonomics are much nicer (eg one command vs having to manually install plugins, etc., more logical commands) It’s also noticeably faster.

Regarding the env vars features, a couple of relevant Mise issues around people trying to integrate env var secrets using SOPS, 1Password, etc.

- https://github.com/jdx/mise/issues/1617

- https://github.com/jdx/mise/issues/1359

I’d not heard of Neon, it looks interesting.

When you say “a copy-on-write version of your prod database”, from reading the docs, this includes both schema and data?

I couldn’t find anything on data anonymisation/obfuscation - how do you handle that?

Exa is unmaintained, but there’s a maintained fork called eza - https://github.com/eza-community/eza

I would suggest never doing that, because it makes it impossible, or at least very difficult, to:

1. Lint the code using ShellCheck, which IMO is essential for any shell

2. Run and test that code locally, or anywhere outside of the CI tool

It’s only marginally less convenient to externalise the code into a .sh file and load it in CI.

Looks like a decent list, but mostly not really Linux, just Unix/GNU?

Is saying “most of something” a universal generalisation?

The comment didn’t say “you’re not a crypto enthusiast _unless_ you believe X”. It just made an assertion (which, for what it’s worth, I think is incorrect) that the majority have a certain belief.

There’s an awkward gotcha/incompatibility between “Required status checks” and workflows that get skipped [1], eg due to setting a “paths” property of a push/pull_request workflow trigger [2].

The checks associated with the workflow don’t run and stay in a pending state, preventing the PR from being merged.

The only workaround I’m aware of is to use an action such as paths-filter [3] instead at the job level.

A further, related frustration/limitation - you can _only_ set the “paths” property [2] at the workflow level (i.e. not per-job), so those rules apply to all jobs in the workflow. Given that you can only build a DAG of jobs (ie “needs”) within a single workflow, it makes it quite difficult to do anything non trivial in a monorepo.

[1]: https://docs.github.com/en/repositories/configuring-branches...

[2]: https://docs.github.com/en/actions/using-workflows/workflow-...

[3]: https://github.com/dorny/paths-filter

Yes, absolutely! I loved listening to the Reith lectures many, many years ago, when Vilayanur Ramachandran gave them. You can still listen to them here, http://www.bbc.co.uk/radio4/reith2003/

In Lecture 4 (Purple Numbers and Sharp Cheese) he talks about the Kiki / Bouba effect. His enunciation is amazing.

How does this compare to Mergify? https://mergify.io/

Heh. Aaron Patterson (aka tenderlove), core Ruby and Rails contributor, agrees with you. Although maybe not as forcefully :)

https://tenderlovemaking.com/2016/02/05/i-am-a-puts-debugger...

Thought I'd get their docs updated - https://github.com/mxschmitt/action-tmate#manually-triggered...

One approach to avoid this karlicoss is to add a “workflow dispatch” section to the “on” events in the workflow:

  workflow_dispatch:
    inputs:
      debug_enabled:
        description: 'Run the build with tmate debugging enabled (https://github.com/marketplace/actions/debugging-with-tmate)'     
        required: false
        default: false

Then under the job steps, make the debug step conditional on that optional flag:

     # Enable tmate debugging of manually-triggered workflows if the input option was provided
      - name: Setup tmate session
        uses: mxschmitt/action-tmate@v3
        if: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.debug_enabled }}

You then can just trigger the build on the required branch, setting debug_enabled to true and voila.

Edit: but agree the CircleCI interface is nicer where you can just run a debug build with ssh access directly.

Just because something might be impossible to solve fully, doesn’t mean we shouldn’t still try? For example cryptography is an arms race against code breakers, but that’s not a reason to just give up on encryption?

Also a multi-front defence seems sensible. Agree with points below that the law needs to catch up on this front, but is not mutually exclusive to efforts in improving detection.