• 0 Posts
  • 80 Comments
Joined 11 months ago
cake
Cake day: December 29th, 2023

help-circle

  • the various github-supplied actions are good example:

    https://github.com/actions/setup-python

    the action.yml here is the metadata for an action (and you invoke this action by simply referencing actions/setup-python - perhaps with a sha or tag or something to pin it - and the runner clones and runs it, making custom actions simply code with no build process etc necessary which is very nice to not have to bootstrap your build process with a build process eg docker build)

    see the “runs” section there - it invokes node20 to run the action, and specifies some code to run to cleanup

    in the src here we can see what i was mentioning as well about having bi-directional comms with the CI system

    https://github.com/actions/setup-python/blob/main/src/setup-python.ts

    line 54 & 55 we have core.getInput and core.getMultiLineInput, 59 we have core.warning (so logs are formatted and filterable etc - these messages also show up in the build summary; similarly line 100 we have core.startGroup), 154 is core.setFailed so you get proper failure reasons rather than “the last line of stderr”

    now, none of this is specific to running in a real language - in fact i believe all this information is communicated over stdout or stderr - but the ease of simply creating a repo with code in it, and having that as a reusable CI step without worrying about docker container hosting, and having that able to have semantic meaning for its inputs and outputs (and proper reliable escaping of the special CI communication prefixes) is something that kinda doesn’t exist outside of this style system


  • personally i have a very big preference for the “actions” model: actions are “real” code; not bash - so there’s actual variable passing and communication with the CI tool (eg an action can tell the CI system to set a secret value, and the CI tool then hides that value from console output in the future). you can do these things with bash as well, but bash isn’t really a great language - i’d trust node far more to, for example, generate a hash or a JWT etc and actions then have access to the entire of NPM for libraries

    these kinds of things (not only this) make it far superior to a bash-based system IMO













  • does ARM still have better battery life when all of the machine code has to be translated from x86

    afaik macos/rosetta is more efficient than native windows/x86, but that could be down to OS integration, or any number of confounding factors… i’d suggest though that x86 windows applications sometimes run better and more efficiently on alternative platforms, even with the translation layers - whether that’s down to the instruction set or a combination of factors




  • make their browser engine useable for 3rd parties and sell support, make an electron-like product and add premium features… there are so many browser-based products that people sell, and owning 1 of the only viable browser engines should be huge… the fact that firefox is still only barely able to be embedded is a travesty

    it’d be especially valuable if they made a premium electron product that provided security/privacy guarantees, performance benefits, etc - they should siphon some of the profit off the number of for-profit companies that build electron apps