7 ms·

This is getting too much.I wonder what effects this will have on the reputation of Github. If I am blocked by Github every few days and can't properly operate.

This is getting too much.I wonder what effects this will have on the reputation of Github. If I am blocked by Github every few days and can't properly operate. I will start looking for a more reliable alternative. And I am just a solo dev that pays $4, what happens to companies for whom time is worth a lot of money? Pretty disappointing.

chockchocschoir 5y ago
How do you as a solo developer get blocked on anything related to GitHub? Are you doing all project planning on GitHub without any other copies elsewhere? Most if not everything you do on GitHub could be replicated locally, one way or another. I can understand the problem for larger development teams, as a lot of communication and workflows can happen via GitHub Pull Requests or similar.
- tyingq 5y ago
  Maybe using their CI/CD?
  - chockchocschoir 5y ago
    CI/CD should you perform tasks that you could execute on any machine, besides the deployment, which should work differently locally VS via CI service. But it should still be possible to deploy without CI, otherwise you set yourself up for being unable to deploy when you really need it.
    - kiloreux 5y ago
      Yeah, but theory and practice are very different things. If CI always worked for me and my experience was great with it. I will not invest time to do independent CI for everything. Hence depending on Github Actions. Clearly not the best approach, but it's about being pragmatic also.
      - chockchocschoir 5y ago
        What do you mean "independent CI"? You start with a `Makefile` with the commands for testing, building and so on, and CI is just calling those commands but on another instances, that likely gets triggered for each commit/tag/pull request/whatever. When you first setup CI, you don't actually just develop for the CI environment first, that's the second step after you know how to perform the same things locally. So not sure why there would be "independent CI for everything".
        tyingq 5y ago
        It's easy enough to unintentionally box yourself into a hard 3rd party dependency. Like the github secrets store, conditional logic or triggers in the ci.yml files, pipeline driven semantic versioning, etc.
    - DogLover_ 5y ago
      Github-actions is not created to encourage that though. It uses syntax that only works on Github. Look at their workflow-examples and you will see.
      - chockchocschoir 5y ago
        Don't you define things in your repository first (usually via a `Makefile`) and then call those things in the CI environment? Or are you building things differently in the CI environment compared to the local environment? I mean, if you're working on a project that has tests, code coverage and binary builds setup, you usually have a `Makefile` or `package.json` or whatever to run your scripts, and your CI setup just calls those very same scripts but in their environment (sometimes with different arguments/environment variables). Not sure why it would be different for GitHub Actions. It's certainly how I use it day-to-day.
        deckard1 5y ago
        no that's not how it works at all. The "actions" are proprietary to GitHub and hosted on GitHub. People create custom actions and allow others to reuse them. Everything is hooked in to GitHub via their proprietary yaml config. > Not sure why it would be different for GitHub Actions. because vendor lock-in. GitHub doesn't want to make it easy for you to switch.
        greggman3 5y ago
        You can run github actions offline https://github.com/nektos/act https://github.com/nektos/act I don't think github is trying to create lock-in, I think rather they were trying to make a way to easily share actions (not sure what other CIs systems are designed to have an ecosystem of publicly shared actions). The actions are public and therefore easy to make something that interprets them. I can only guess at some point there will be a push for CIs to converge on some "actions" standard, maybe?
        tyingq 5y ago
    - mhitza 5y ago
      > But it should still be possible to deploy without CI, Solo? Yes. In a team? Less often just because you might have credentials stored in secrets that are not shared with the entire team for security reasons. In larger corps it's easier to wait it out that go through the trouble of escalating permission requests. But I do get your point. Personally for deployments I have Ansible playbooks that are invoked via straighforward calls which can be done locally.
- kiloreux 5y ago
  I am a solo dev, but I work in a company and now have been working on pushing something to test it on Github actions. If it was something different, maybe. But I understand how I might have miscommunicated that.
  - misnome 5y ago
    I'm also in a company, but today am building up something on Github Actions. Every single time I start doing development on Actions, GitHub goes down or actions start failing. I'm not sure if this is saying something about me, or GitHub.
- bilekas 5y ago
  > Most if not everything you do on GitHub could be replicated locally, one way or another That's not really the point though.. If you have services in github etc, why would you replicate all of them locally too for unplanned downtime ?
  - chockchocschoir 5y ago
    Well, usually you figure out how to run your tests, check code coverage and build your binaries locally first, then figuring out how to get it to work in the CI environment, not the other way around. So the replication has already been done, but in the direction of local environment > remote environment.
    - bilekas 5y ago
      I don't disagree, really local environments should be able to manage dev and most daily tasks, but large integration pipelines, test automations etc. I just don't feel the need to defend GitHub here for the reason of : "Well you should be able to manage locally anyway"
  - hunter2_ 5y ago
    This is quite similar to the somewhat philosophical question of having backups: if your job is to make sure your company has backups of their data, and you entrust a single vendor with that data because they take care of backups so you don't have to, are you really doing your job? Said another way: if you (or your immediate team) are not the party that turns one thing into two things, then there is still a SPOF in your wheelhouse, and the whole point is for that to not be the case.
    - kayodelycaon 5y ago
      Maintaining an entire secondary deployment and CI system just seems unrealistic to me. I'd get so much flack about the extra spend and when the systems get out of sync and causes downtime, that investment ends up with net negative for all involved.
    - 5y ago
- kayodelycaon 5y ago
  Personally, I can't deploy if GitHub is down. CI pulls from GitHub. One of my projects includes libraries as submodules, with GitHub as the origin. The deployment configuration has everything cloning from GitHub.
- coldpie 5y ago
  Try building any Rust project while GitHub is down.
  - chockchocschoir 5y ago
    That's only applicable if you use crates directly from GitHub repositories right? I've been sitting and developing+building a Rust project for the last +10 hours (except the minutes when I was here arguing on HN) and never hit any issues, but I'm using crates either directly from disk (cloned from GitHub initially) or from crates.io.
    - coldpie 5y ago
      I could be wrong, but try a fresh build with a clean CARGO_HOME (or maybe just a cargo update?). It seems to query a lot if you don't have a full cache.
      - steveklabnik 5y ago
        While it's true that Cargo will attempt to check on some things, you can pass flags to tell it to not bother. Specifically, https://doc.rust-lang.org/stable/cargo/commands/cargo.html#option-cargo---offline https://doc.rust-lang.org/stable/cargo/commands/cargo.html#o...

chockchocschoir 5y ago

How do you as a solo developer get blocked on anything related to GitHub? Are you doing all project planning on GitHub without any other copies elsewhere? Most if not everything you do on GitHub could be replicated locally, one way or another. I can understand the problem for larger development teams, as a lot of communication and workflows can happen via GitHub Pull Requests or similar.

tyingq 5y ago
Maybe using their CI/CD?
- chockchocschoir 5y ago
  CI/CD should you perform tasks that you could execute on any machine, besides the deployment, which should work differently locally VS via CI service. But it should still be possible to deploy without CI, otherwise you set yourself up for being unable to deploy when you really need it.
  - kiloreux 5y ago
    Yeah, but theory and practice are very different things. If CI always worked for me and my experience was great with it. I will not invest time to do independent CI for everything. Hence depending on Github Actions. Clearly not the best approach, but it's about being pragmatic also.
    - chockchocschoir 5y ago
      What do you mean "independent CI"? You start with a `Makefile` with the commands for testing, building and so on, and CI is just calling those commands but on another instances, that likely gets triggered for each commit/tag/pull request/whatever. When you first setup CI, you don't actually just develop for the CI environment first, that's the second step after you know how to perform the same things locally. So not sure why there would be "independent CI for everything".
      - tyingq 5y ago
        It's easy enough to unintentionally box yourself into a hard 3rd party dependency. Like the github secrets store, conditional logic or triggers in the ci.yml files, pipeline driven semantic versioning, etc.
  - DogLover_ 5y ago
    Github-actions is not created to encourage that though. It uses syntax that only works on Github. Look at their workflow-examples and you will see.
    - chockchocschoir 5y ago
      Don't you define things in your repository first (usually via a `Makefile`) and then call those things in the CI environment? Or are you building things differently in the CI environment compared to the local environment? I mean, if you're working on a project that has tests, code coverage and binary builds setup, you usually have a `Makefile` or `package.json` or whatever to run your scripts, and your CI setup just calls those very same scripts but in their environment (sometimes with different arguments/environment variables). Not sure why it would be different for GitHub Actions. It's certainly how I use it day-to-day.
      - deckard1 5y ago
        no that's not how it works at all. The "actions" are proprietary to GitHub and hosted on GitHub. People create custom actions and allow others to reuse them. Everything is hooked in to GitHub via their proprietary yaml config. > Not sure why it would be different for GitHub Actions. because vendor lock-in. GitHub doesn't want to make it easy for you to switch.
        greggman3 5y ago
        You can run github actions offline https://github.com/nektos/act https://github.com/nektos/act I don't think github is trying to create lock-in, I think rather they were trying to make a way to easily share actions (not sure what other CIs systems are designed to have an ecosystem of publicly shared actions). The actions are public and therefore easy to make something that interprets them. I can only guess at some point there will be a push for CIs to converge on some "actions" standard, maybe?
        tyingq 5y ago
  - mhitza 5y ago
    > But it should still be possible to deploy without CI, Solo? Yes. In a team? Less often just because you might have credentials stored in secrets that are not shared with the entire team for security reasons. In larger corps it's easier to wait it out that go through the trouble of escalating permission requests. But I do get your point. Personally for deployments I have Ansible playbooks that are invoked via straighforward calls which can be done locally.
kiloreux 5y ago
I am a solo dev, but I work in a company and now have been working on pushing something to test it on Github actions. If it was something different, maybe. But I understand how I might have miscommunicated that.
- misnome 5y ago
  I'm also in a company, but today am building up something on Github Actions. Every single time I start doing development on Actions, GitHub goes down or actions start failing. I'm not sure if this is saying something about me, or GitHub.
bilekas 5y ago
> Most if not everything you do on GitHub could be replicated locally, one way or another That's not really the point though.. If you have services in github etc, why would you replicate all of them locally too for unplanned downtime ?
- chockchocschoir 5y ago
  Well, usually you figure out how to run your tests, check code coverage and build your binaries locally first, then figuring out how to get it to work in the CI environment, not the other way around. So the replication has already been done, but in the direction of local environment > remote environment.
  - bilekas 5y ago
    I don't disagree, really local environments should be able to manage dev and most daily tasks, but large integration pipelines, test automations etc. I just don't feel the need to defend GitHub here for the reason of : "Well you should be able to manage locally anyway"
- hunter2_ 5y ago
  This is quite similar to the somewhat philosophical question of having backups: if your job is to make sure your company has backups of their data, and you entrust a single vendor with that data because they take care of backups so you don't have to, are you really doing your job? Said another way: if you (or your immediate team) are not the party that turns one thing into two things, then there is still a SPOF in your wheelhouse, and the whole point is for that to not be the case.
  - kayodelycaon 5y ago
    Maintaining an entire secondary deployment and CI system just seems unrealistic to me. I'd get so much flack about the extra spend and when the systems get out of sync and causes downtime, that investment ends up with net negative for all involved.
  - 5y ago
kayodelycaon 5y ago
Personally, I can't deploy if GitHub is down. CI pulls from GitHub. One of my projects includes libraries as submodules, with GitHub as the origin. The deployment configuration has everything cloning from GitHub.
coldpie 5y ago
Try building any Rust project while GitHub is down.
- chockchocschoir 5y ago
  That's only applicable if you use crates directly from GitHub repositories right? I've been sitting and developing+building a Rust project for the last +10 hours (except the minutes when I was here arguing on HN) and never hit any issues, but I'm using crates either directly from disk (cloned from GitHub initially) or from crates.io.
  - coldpie 5y ago
    I could be wrong, but try a fresh build with a clean CARGO_HOME (or maybe just a cargo update?). It seems to query a lot if you don't have a full cache.
    - steveklabnik 5y ago
      While it's true that Cargo will attempt to check on some things, you can pass flags to tell it to not bother. Specifically, https://doc.rust-lang.org/stable/cargo/commands/cargo.html#option-cargo---offline https://doc.rust-lang.org/stable/cargo/commands/cargo.html#o...