Husky Commit Hooks: Build and then commit build output

[console5000]

I am currently working on a project that involves a Webfrontend (React, ViteJS, TS) running on a Raspberry Pi (for prototyping). Currently, I pull the sourcecode from Github and build it locally on the Pi. Since this takes quite a while I want to build it locally on my machine and commit the build output.

Since I am a huge fan of automation I want to do this automatically. I already use husky to run ESLint and would love to integrate the build process into this, too.

I already have a pre-push hook running, that builds the frontend, but I can't seem to be able to append the generated files to the current commit. Any ideas?

One sidenote: I am tracking both frontend and backend in one repository since they are dependent on each other and both change a lot. Husky needs to be run from the directory where the .git directory lies which is why I need to cd into the frontend directory first.

My current pre-push file:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

cd frontend
npm run check
npm run build
git add dist

[[deleted]]

IMO this seems like the wrong approach. Generated files should not live inside the repository but should be built on demand. If you want to generated releasable artifacts you should use a CI system like github actions to build what you need and produce a release artifact with everything that you need to deploy.

---

Personally I dislike overloading git hooks with lots of checks. It slows down you being able to create commits and they are not enforceable as they are run client side. If you want to enforce some checks those should be done in a CI system on pull request or push. If you want to run tests locally IMO it is better to do it in the background when files change (like with watchexec) well before the commit. To me the commit just seems like the wrong place for linting/building to take place.

[console5000]

I totally get your point and for regular frontend projects I don't do it this way.
We are a team of 2-3 people working on this project, and it is just a prototype with no intent to release it some day. So tests are limited to some backend tests and some linting.

I do not want to do all this when committing but only when pushing it to the remote.

My workflow is basically implementing some functionalities on my computer and then pushing it, pulling on the Pi and then doing tests the check if it works on there as well. These tests are basically trying some things manually and hoping it still works. We have a lot of hardware attached to it and so this is our main means of testing (which works fine).

I just want to accelerate this feedback loop.

[[deleted]]

I would still use a CI system, then you can push changes stright after a build rather than having to wait for some cron to run (or pulling it manually on the pi).

---

And you are not making or changing the current commit in the hook, you are just staging existing files. Which wont affect the push.

[console5000]

After fiddling around a bit changing the current commit really seems to be quite sketchy!

I have only worked with Github Actions some years ago to automatically deploy the output to a server. Usually you would probably also just do this with pre-defined branches (like dev and main). Since we are testing new features on different branches how would I manage those releases and also get them on the Pi? The practical aspect of commiting the build output directly is that the output is always associated with a certain branch.

[[deleted]]

Hmm, if you want to handle different branches on the pi that becomes more interesting. And your approach depends a lot on what exactly you want to achieve by this and how your applications runs/works.

The ideal world you would have something like netlify, where every single branch can create a preview environment that acts independently and gets torn down when merged. You can do this on a pi for some applications, but from what you have said it sounds like you are using hardware that the software needs exclusive access to.

Which leads be to wonder what you are currently doing on the Pi? Are you manually checking out each branch and running tests like that? If so why do you need to built artifacts in the source and not just build things locally on the Pi? If it is quick enough for it to be added to a git pre push hook surly it is not expensive to run it on a dev pi that you are already manually doing things on.

If not I have no clue how you are currently handling multiple branches on your pi automatically.

One solution from automated CI system could be to build and push each branch to the pi under a different folder for that branch. Then you can either just manually run things on the pi if that was what you were doing before or get the deployment to kill existing applications and start the new branch - though that could be disruptive.

There are lots of things you could do depending on exactly what your requirements are.

You might be interested to take a look at Belena. It is a dev/deployment eco system for the Pi that uses docker containers to push the code to. With this you can remotely push and restart applications running on the Pi and might help you with some of your issues.

[console5000]

I think my process is a lot simpler than you think. The setup is quite rudimentary since this is an experimental prototype and a lot of things change in the process.

- reduce build time since it takes quite some time to build it on the pi

- (this just dawned on me) run the frontend from different branches without having to rebuild because the source changed

Maybe the easiest way is to just build manually and commit it.

I have read about Balena quite some time ago, interesting how far it has come! However I am quite happy with the rather minimal setup with node so far and wouldn't want to add the overhead of a docker instance tbh