3 ms·

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 o

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.
  - nomilk 1y ago
    Good advice about locking versions. I can literally see uses: browser-actions/setup-chrome@latest in my discarded yml file. Regarding containers, nope, I know and love docker, but it's unnecessary complexity for a one person project. IME, projects that use docker move at half the pace of the projects that don't. (similar to Actions - lots of fun, feels like 'best practice', but velocity suffers - i.e. it steals time that should be spent talking to users and building).
    - SeanAnderson 1y ago
      I see. I don't feel the way you do about containers. In most scenarios I barely remember the abstraction layer exists. The only time in recent memory I've regretted using one was when doing game development and struggling to get GPU hardware acceleration functioning within the container. On the other hand, I remember lots of historical situations where I've dirtied my host machine's globals, gone back to an older project, and found the project non-functional (python2 vs python3 being namespaced to python, competing node/npm versions, etc.) If anything, with the advent of Claude Code et al., I've become an even stronger proponent of container-based development. I have absolutely zero interest running AI on my host machine. It's reassuring to know that a rogue "rm -rf" will, at worst, just require me to rebuild my container.
    - motorest 1y ago
      > Regarding containers, nope, I know and love docker, but it's unnecessary complexity for a one person project. This is a perplexing comment. Can you provide any specifics on what leads you to believe that Docker is a hindrance? I've been using Docker for ages, both professionally and in personal projects, and if anything it greatly simplifies any workflow. I wonder what experience you are having to arrive to such an unusual outcome.
- serial_dev 1y ago
  For small projects, getting rid of the CI/CD can make sense in certain cases. I almost started my simple static site with GitHub Actions as setting up CI/CD is “just something you do”, then I realized I want to deploy in 2 seconds, not in 2 minutes.

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.
- nomilk 1y ago
  Good advice about locking versions. I can literally see uses: browser-actions/setup-chrome@latest in my discarded yml file. Regarding containers, nope, I know and love docker, but it's unnecessary complexity for a one person project. IME, projects that use docker move at half the pace of the projects that don't. (similar to Actions - lots of fun, feels like 'best practice', but velocity suffers - i.e. it steals time that should be spent talking to users and building).
  - SeanAnderson 1y ago
    I see. I don't feel the way you do about containers. In most scenarios I barely remember the abstraction layer exists. The only time in recent memory I've regretted using one was when doing game development and struggling to get GPU hardware acceleration functioning within the container. On the other hand, I remember lots of historical situations where I've dirtied my host machine's globals, gone back to an older project, and found the project non-functional (python2 vs python3 being namespaced to python, competing node/npm versions, etc.) If anything, with the advent of Claude Code et al., I've become an even stronger proponent of container-based development. I have absolutely zero interest running AI on my host machine. It's reassuring to know that a rogue "rm -rf" will, at worst, just require me to rebuild my container.
  - motorest 1y ago
    > Regarding containers, nope, I know and love docker, but it's unnecessary complexity for a one person project. This is a perplexing comment. Can you provide any specifics on what leads you to believe that Docker is a hindrance? I've been using Docker for ages, both professionally and in personal projects, and if anything it greatly simplifies any workflow. I wonder what experience you are having to arrive to such an unusual outcome.
serial_dev 1y ago
For small projects, getting rid of the CI/CD can make sense in certain cases. I almost started my simple static site with GitHub Actions as setting up CI/CD is “just something you do”, then I realized I want to deploy in 2 seconds, not in 2 minutes.