3 ms·

Because this needs to happen as one prepares to push to day's last deploy. Back to backups. Have backups for critical systems, people. In my case, it's buildin

Because this needs to happen as one prepares to push to day's last deploy. Back to backups. Have backups for critical systems, people. In my case, it's building docker containers locally and luckily deploying to one server via ssh.

TechBro8615 4y ago
Because if you don't spend multiple days per year managing your own "backup" to GitHub, you might be left unable to push to GitHub for a few hours per year? btw, I hope none of your CI system relies on build steps that might include pulling code from GitHub or downloading packages from GitHub Package registry. Often when GitHub is down, my CI system on GitLab is broken too.
- hakanderyal 4y ago
  I like to reduce the single point of failure count in my projects as much as I can, with common sense. My backup system is running a few cli commands instead of git push, so it's a no brainer. YMMV.
  - TechBro8615 4y ago
    How sure are you that none of those commands has a dependency on GitHub infrastructure?
    - hakanderyal 4y ago
      Because I use Github only for git hosting and actions (building & deploying containers). In this case, code is already in my computer, and I can build and ssh to server and pull&run the new container. "docker buildx build ... -push" "ssh ...@..." "docker pull ..." "docker compose up ..."
      - TechBro8615 4y ago
        That assumes that none of your Docker images have a build step that includes interacting with GitHub, or if some do, that you have every affected layer already cached on your local computer.
    - ysavir 4y ago
      I understand the point you're making here, but I feel it is being made in an effort to prove hakanderyal technically wrong rather than to evaluate the practicality of single points of failure, which is what they're trying to promote. I this this conversation would be much more helpful and insightful if it was kept on that evaluation track rather than trying to have a final word.
      - TechBro8615 4y ago
        I don't think "GitHub is down" threads are known for the quality of their conversation, but sure. I also agree with reducing (increasing?) single points of failure. I'm not trying to be pedantic, but rather observing that in practice, it's not nearly as easy as spinning up a backup Git server (which is already hard enough). Maintaining two classes of build infrastructure throughout all your dependencies is probably not a worthwhile problem to solve, unless you want to control for the improbable risk that GitHub will be down for weeks at a time. You'd be much better off ensuring that you are able to perform rollbacks without needing to pull from the external world, because this way the worst case scenario is you run a stale version for the time that GitHub is down, in the off chance you pushed a broken version right before the outage.
        ysavir 4y ago
        True, but there are other ways to go about it. Rather than trying to challenge someone's setup, which (I assume, apologies if incorrectly) you aren't familiar with, you can start by asking them about the setup and how they keep it independent from GH. Let them expose either the success of the endeavor or its shortcomings. Such an approach is a constructive one, whereas trying to challenge someone is an antagonistic approach. We're all in this together, so let's keep our discussions constructive, and focus on learning from each other rather than try to tear each other down.
- zuhsetaqi 4y ago
  Is there anywhere a history of the uptime of GitHub?
  - TechBro8615 4y ago
    There is the GitHub Status Page [0], which doesn't display aggregate stats, but you could scrape it and do the analysis. I suspect what you're getting at is that the downtime might evaluate to multiple days over the course of the year. Maybe that's true, idk. I'd be curious, but you'd probably want to do the analysis separately for different services (e.g. Actions vs. Package Registry vs. Git outages all have different effects on build infrastructure downtime). [0] https://www.githubstatus.com/history https://www.githubstatus.com/history
can16358p 4y ago
Depends on the context. I need to push to a repo and QA needs to test the app, but since I can't push, they can't. No other practical way (other than setting up another origin on Bitbucket or GitLab, or emailing/zipping sending etc).
- hakanderyal 4y ago
  Yea, heavily depends on the context. In my case, it's a single dev deploying to single server, so no biggie.

TechBro8615 4y ago

Because if you don't spend multiple days per year managing your own "backup" to GitHub, you might be left unable to push to GitHub for a few hours per year? btw, I hope none of your CI system relies on build steps that might include pulling code from GitHub or downloading packages from GitHub Package registry. Often when GitHub is down, my CI system on GitLab is broken too.

hakanderyal 4y ago
I like to reduce the single point of failure count in my projects as much as I can, with common sense. My backup system is running a few cli commands instead of git push, so it's a no brainer. YMMV.
- TechBro8615 4y ago
  How sure are you that none of those commands has a dependency on GitHub infrastructure?
  - hakanderyal 4y ago
    Because I use Github only for git hosting and actions (building & deploying containers). In this case, code is already in my computer, and I can build and ssh to server and pull&run the new container. "docker buildx build ... -push" "ssh ...@..." "docker pull ..." "docker compose up ..."
    - TechBro8615 4y ago
      That assumes that none of your Docker images have a build step that includes interacting with GitHub, or if some do, that you have every affected layer already cached on your local computer.
  - ysavir 4y ago
    I understand the point you're making here, but I feel it is being made in an effort to prove hakanderyal technically wrong rather than to evaluate the practicality of single points of failure, which is what they're trying to promote. I this this conversation would be much more helpful and insightful if it was kept on that evaluation track rather than trying to have a final word.
    - TechBro8615 4y ago
      I don't think "GitHub is down" threads are known for the quality of their conversation, but sure. I also agree with reducing (increasing?) single points of failure. I'm not trying to be pedantic, but rather observing that in practice, it's not nearly as easy as spinning up a backup Git server (which is already hard enough). Maintaining two classes of build infrastructure throughout all your dependencies is probably not a worthwhile problem to solve, unless you want to control for the improbable risk that GitHub will be down for weeks at a time. You'd be much better off ensuring that you are able to perform rollbacks without needing to pull from the external world, because this way the worst case scenario is you run a stale version for the time that GitHub is down, in the off chance you pushed a broken version right before the outage.
      - ysavir 4y ago
        True, but there are other ways to go about it. Rather than trying to challenge someone's setup, which (I assume, apologies if incorrectly) you aren't familiar with, you can start by asking them about the setup and how they keep it independent from GH. Let them expose either the success of the endeavor or its shortcomings. Such an approach is a constructive one, whereas trying to challenge someone is an antagonistic approach. We're all in this together, so let's keep our discussions constructive, and focus on learning from each other rather than try to tear each other down.
zuhsetaqi 4y ago
Is there anywhere a history of the uptime of GitHub?
- TechBro8615 4y ago
  There is the GitHub Status Page [0], which doesn't display aggregate stats, but you could scrape it and do the analysis. I suspect what you're getting at is that the downtime might evaluate to multiple days over the course of the year. Maybe that's true, idk. I'd be curious, but you'd probably want to do the analysis separately for different services (e.g. Actions vs. Package Registry vs. Git outages all have different effects on build infrastructure downtime). [0] https://www.githubstatus.com/history https://www.githubstatus.com/history

can16358p 4y ago

Depends on the context. I need to push to a repo and QA needs to test the app, but since I can't push, they can't. No other practical way (other than setting up another origin on Bitbucket or GitLab, or emailing/zipping sending etc).

hakanderyal 4y ago
Yea, heavily depends on the context. In my case, it's a single dev deploying to single server, so no biggie.