Closed troibe closed 3 years ago
@adrianomelo Seems like this leads to long build times of 1.5h. Any ideas on how we can reduce these?
Adressing #16 with this branch
Adressing #17 with this branch
@adrianomelo Any ideas of unit tests? I'm thinking of maybe having the Miso and Elm code running side by side and comparing the DOM. On the other hand that would force us stay coupled with the Elm repo down the line.
@adrianomelo Any ideas of unit tests? I'm thinking of maybe having the Miso and Elm code running side by side and comparing the DOM. On the other hand that would force us stay coupled with the Elm repo down the line.
It would be great to have some tests! I am not sure what would be the most effective approach. Maybe we can give this project a try: https://github.com/quickstrom/quickstrom
For now, I would prefer to invest some time in improving the demo, to be honest. Combining with creating a standalone library for the project. We don't need to wait to give it a try on a real project.
@adrianomelo Seems like this leads to long build times of 1.5h. Any ideas on how we can reduce these?
Ideally, we should have a docker image with most of the dependencies already installed. 1.5 hours is a lot!! It would be definitely worth changing the base image or creating a custom one for this project.
I was checking miso
repository. There is a signingKey
param. Do you know how it works? (it takes less than 10 min to build the examples of the project)
https://github.com/dmjio/miso/blob/master/.github/workflows/main.yml
I was checking
miso
repository. There is asigningKey
param. Do you know how it works? (it takes less than 10 min to build the examples of the project)https://github.com/dmjio/miso/blob/master/.github/workflows/main.yml
I will ask David if he has some ideas as to why it's taking so long. The signing key sounds like a good starting point.
See https://nix.dev/tutorials/continuous-integration-github-actions.html
Thanks I will run through the guide. Hopefully it will speed up build times.
@domenkozar I'm a bit confused. When I ran cachix locally on my machine the only compress and push I was getting were for my applications artefacts. Now the one running in this pipeline did what I expected and ran compress and push for all dependency artefacts.
Two different modes of operation: cachix push
will push runtime closure of derivations.
github action will do a diff of store paths and upload everything already built.
Why:
Currently new pull requests are not checked for whether they are actually successfully building or are properly formatted.
What:
Introduce a basic CI/CD workflow which checks the build and format.
Testing: Check the new build indicator