4 ms·

I stopped using Actions for side projects a few months ago, things are simpler now (I run tests locally). I felt like Actions were a time sink that trick you i

by nomilk 1y ago

I stopped using Actions for side projects a few months ago, things are simpler now (I run tests locally). I felt like Actions were a time sink that trick you into feeling productive - like you're pursuing 'best practice' - while stealing time that could otherwise be spent talking to users or working on your application.

raybb 1y ago
Makes sense for side projects. I think there's real value for open source projects so people can get feedback quickly and maintainers can know that the tests are passing quickly.
nixpulvis 1y ago
Um... maybe some actions setups are overly complex, but CI/CD is valuable if done well. For example, running tests before merge ensures you don't forget to. Running lints/formatters ensures you don't need to refactor later and waste time there. For my website, it pushes main automatically, which means I can just do something else while it's all doing it's thing. Perhaps you should invest in simplifying your build process instead?
- nomilk 1y ago
  It's valuable, but at what cost? The day I forget to run tests before merging I'll set up CI/CD (hasn't happened before, unlikely, but not impossible). My build process is gp && gp heroku main. Minor commits straight to main. Major features get a branch. This is manual, simple and loveable. And involves zero all-nighters commit-spamming the .github directory :)
  - nixpulvis 1y ago
    I mean, I agree it would be nice to be able to test actions locally (maybe there's a tool for this). But I keep my actions very simple, so it rarely takes me a lot of time to get them right. See https://github.com/nixpulvis/grapl/blob/master/.github/workflows/rust.yaml https://github.com/nixpulvis/grapl/blob/master/.github/workf... If you want more complex functionality, that's why I suggested improving your build system, so the actions themselves are pretty simple. Where things get more frustrating for me is when you try using more advanced parts of actions like releases and artifacts which aren't as simple as running a script and checking it's output/exit code.
    - nomilk 1y ago
      < 20 lines is nice. Just refreshed my memory by looking at mine. 103 lines. Just the glance brought back painful memories. The worst areas were: - Installing ruby/bundler/gems/postgres/js libraries, dealing with versioning issues, and every few months have them suddenly stop working for some reason that had to be addressed in order to deploy. - Installing capybara and headless chrome and running system tests (system tests can be flakey enough locally, let alone remotely). - Minor issue of me developing on a mac, deploying to heroku, so linux on GHA needs a few more things installed than I'm used to, creating more work (not the end of the world, and good to learn, but slow when it's done via a yaml file that has to be committed and run for a few minutes just to see the error).
wara23arish 1y ago
i recently started and kinda agree? my setup before was just build and scp now it takes like 3 mins for a deploy: i haven’t setup caching for builds etc. but that feels like a self made problem my proj is pretty simple so thats probably why
- huflungdung 1y ago
  [dead]
- tracker1 1y ago
  For my current work project, caching was actually slower than just doing fresh resource installs... I don't know if Github has some transparent caching proxies for npm, nuget, etc, but they run faster than the cache save/restore does. We're using the github hosted runners for pull requests and builds... the build process with build and attach .zip files into a release and the deploy process runs on self-hosted runners on the target server(s). Tests for PRs takes about 2-4min depending on how long it takes to queue the job. Build/Bundling takes about 3-5 minutes. The final deploys are under a minute. The biggest thing for me is to stay as hands off from the deployed servers as possible. Having done a lot of govt and banking work, it's just something I work pretty hard to separate myself from. Automating all the things and staying as hands off as I can. Currently doing direct deploys, but would rather be deploying containers.
vel0city 1y ago
Is it a project where it's pretty much just you doing things, or something with a team of people working on things? Are you working in a space with strong auditability concerns or building pretty much hobby software? For the personal home hacking projects I do, I often don't even make an external repo. I definitely don't do external CI/CD. Often a waste of time. For more enterprise kind of development, you bet the final gold artifacts are built only by validated CI/CD instances and deployed by audited, repeatable workflows. If I'm deploying something from a machine I have in my hands with an active local login for, something is majorly on fire.
SeanAnderson 1y ago
Can you explain your thoughts here more? I don't think I'm following. Are you saying that the act of setting up the CI pipeline is time consuming? Or the act of maintaining it? The only time I think about my CI pipeline is when it fails. If it fails then it means I forgot to run tests locally. I guess I can see getting in the weeds with maintaining it, but that always felt more likely when not deploying Dockerized containers since there was duplication in environmental configs that needed to be kept synchronized. Or are you commenting on the fact that all cloud-provided services can go down and are thus a liability? Or do you feel limited by the time it takes to recreate environments on each deployment? I haven't bumped into this scenario that often. Usually that dominating variable in my CI pipeline is the act of running tests themselves. Usually due to poor decisions around testing best practices that cause the test runner to execute far slower than desired. Those issues would also exist locally, though.
- nomilk 1y ago
  Maintaining was painful (strongly disliked when an Action would start failing for unknown reasons, forcing prioritisation of the Action over the app and users). But setting up a useful CI/CD pipeline was the worst part. The tl;dr is installing everything and getting system tests (i.e. tests using a browser) to work was just excruciating, partly because of the minutes long cycle time between making changes in the yaml, committing, pushing, clicking and waiting for it to fail. The cycle time was the killer. (if you could reliably run GHAs locally, my opinion of them would be completely different - and I tried Act, but it had its own problems, mostly related to its image and dependences being a bit different to that used in GHA). More details (linking to save repeating them): https://news.ycombinator.com/item?id=45530753 https://news.ycombinator.com/item?id=45530753
  - SeanAnderson 1y ago
    Why are you having to manage your dependencies separately in GH actions YAML? Are you not using containers for local development? In my experience, I just set everything up inside my container locally, run tests locally, push the Dockerfile to GH, and re-run my CI off of dependencies declared in the Dockerfile. https://stackoverflow.com/questions/61154750/use-local-docker-image-in-a-github-action https://stackoverflow.com/questions/61154750/use-local-docke... I agree that debugging flakey tests locally is much easier, though, and flakey tests in a CI pipeline is really aggravating. Flakey tests are just aggravating in general, though. I've also had frustrations where, if I didn't lock the versions of my actions, they'd start failing randomly and require intervention. Just getting into a good habit of not relying on implicit versioning for dependencies helped a lot.

by nomilk 1y ago

raybb 1y ago

Makes sense for side projects. I think there's real value for open source projects so people can get feedback quickly and maintainers can know that the tests are passing quickly.

nixpulvis 1y ago

Um... maybe some actions setups are overly complex, but CI/CD is valuable if done well. For example, running tests before merge ensures you don't forget to. Running lints/formatters ensures you don't need to refactor later and waste time there. For my website, it pushes main automatically, which means I can just do something else while it's all doing it's thing. Perhaps you should invest in simplifying your build process instead?

nomilk 1y ago
It's valuable, but at what cost? The day I forget to run tests before merging I'll set up CI/CD (hasn't happened before, unlikely, but not impossible). My build process is gp && gp heroku main. Minor commits straight to main. Major features get a branch. This is manual, simple and loveable. And involves zero all-nighters commit-spamming the .github directory :)
- nixpulvis 1y ago
  I mean, I agree it would be nice to be able to test actions locally (maybe there's a tool for this). But I keep my actions very simple, so it rarely takes me a lot of time to get them right. See https://github.com/nixpulvis/grapl/blob/master/.github/workflows/rust.yaml https://github.com/nixpulvis/grapl/blob/master/.github/workf... If you want more complex functionality, that's why I suggested improving your build system, so the actions themselves are pretty simple. Where things get more frustrating for me is when you try using more advanced parts of actions like releases and artifacts which aren't as simple as running a script and checking it's output/exit code.
  - nomilk 1y ago
    < 20 lines is nice. Just refreshed my memory by looking at mine. 103 lines. Just the glance brought back painful memories. The worst areas were: - Installing ruby/bundler/gems/postgres/js libraries, dealing with versioning issues, and every few months have them suddenly stop working for some reason that had to be addressed in order to deploy. - Installing capybara and headless chrome and running system tests (system tests can be flakey enough locally, let alone remotely). - Minor issue of me developing on a mac, deploying to heroku, so linux on GHA needs a few more things installed than I'm used to, creating more work (not the end of the world, and good to learn, but slow when it's done via a yaml file that has to be committed and run for a few minutes just to see the error).

wara23arish 1y ago

i recently started and kinda agree? my setup before was just build and scp now it takes like 3 mins for a deploy: i haven’t setup caching for builds etc. but that feels like a self made problem my proj is pretty simple so thats probably why

huflungdung 1y ago
[dead]
tracker1 1y ago
For my current work project, caching was actually slower than just doing fresh resource installs... I don't know if Github has some transparent caching proxies for npm, nuget, etc, but they run faster than the cache save/restore does. We're using the github hosted runners for pull requests and builds... the build process with build and attach .zip files into a release and the deploy process runs on self-hosted runners on the target server(s). Tests for PRs takes about 2-4min depending on how long it takes to queue the job. Build/Bundling takes about 3-5 minutes. The final deploys are under a minute. The biggest thing for me is to stay as hands off from the deployed servers as possible. Having done a lot of govt and banking work, it's just something I work pretty hard to separate myself from. Automating all the things and staying as hands off as I can. Currently doing direct deploys, but would rather be deploying containers.

vel0city 1y ago

Is it a project where it's pretty much just you doing things, or something with a team of people working on things? Are you working in a space with strong auditability concerns or building pretty much hobby software? For the personal home hacking projects I do, I often don't even make an external repo. I definitely don't do external CI/CD. Often a waste of time. For more enterprise kind of development, you bet the final gold artifacts are built only by validated CI/CD instances and deployed by audited, repeatable workflows. If I'm deploying something from a machine I have in my hands with an active local login for, something is majorly on fire.

SeanAnderson 1y ago

Can you explain your thoughts here more? I don't think I'm following. Are you saying that the act of setting up the CI pipeline is time consuming? Or the act of maintaining it? The only time I think about my CI pipeline is when it fails. If it fails then it means I forgot to run tests locally. I guess I can see getting in the weeds with maintaining it, but that always felt more likely when not deploying Dockerized containers since there was duplication in environmental configs that needed to be kept synchronized. Or are you commenting on the fact that all cloud-provided services can go down and are thus a liability? Or do you feel limited by the time it takes to recreate environments on each deployment? I haven't bumped into this scenario that often. Usually that dominating variable in my CI pipeline is the act of running tests themselves. Usually due to poor decisions around testing best practices that cause the test runner to execute far slower than desired. Those issues would also exist locally, though.

nomilk 1y ago
Maintaining was painful (strongly disliked when an Action would start failing for unknown reasons, forcing prioritisation of the Action over the app and users). But setting up a useful CI/CD pipeline was the worst part. The tl;dr is installing everything and getting system tests (i.e. tests using a browser) to work was just excruciating, partly because of the minutes long cycle time between making changes in the yaml, committing, pushing, clicking and waiting for it to fail. The cycle time was the killer. (if you could reliably run GHAs locally, my opinion of them would be completely different - and I tried Act, but it had its own problems, mostly related to its image and dependences being a bit different to that used in GHA). More details (linking to save repeating them): https://news.ycombinator.com/item?id=45530753 https://news.ycombinator.com/item?id=45530753
- SeanAnderson 1y ago
  Why are you having to manage your dependencies separately in GH actions YAML? Are you not using containers for local development? In my experience, I just set everything up inside my container locally, run tests locally, push the Dockerfile to GH, and re-run my CI off of dependencies declared in the Dockerfile. https://stackoverflow.com/questions/61154750/use-local-docker-image-in-a-github-action https://stackoverflow.com/questions/61154750/use-local-docke... I agree that debugging flakey tests locally is much easier, though, and flakey tests in a CI pipeline is really aggravating. Flakey tests are just aggravating in general, though. I've also had frustrations where, if I didn't lock the versions of my actions, they'd start failing randomly and require intervention. Just getting into a good habit of not relying on implicit versioning for dependencies helped a lot.