I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430
Gitlab Epic Issue Relationships Deleted
11–20 of 30 posts
Re: Gitlab Epic Issue Relationships Deleted
#12I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430
You can also add them to GitHub via ZenHub and other such tools.
Re: Gitlab Epic Issue Relationships Deleted
#13Seems like they have it mostly resolved, the releationships were restored from a backup 3 hours prior to the incident, and they are working to restore the data for the 313 (sic.) items still affected: https://gitlab.com/gitlab-org/gitlab/-/issues/348547
I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent
On AWS, EBS snapshots are incremental (I didn't know that until studying for AWS certification), so you could schedule a snapshot every 5 minutes if you wanted.
Looking at the timeline, I'm just gonna repeat something I said in another thread this week: it's easy to underestimate how long it takes to do basically anything with a few hundred GB of important data.
Re: Gitlab Epic Issue Relationships Deleted
#14I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430
That's because github isn't trying to be a replacement for JIRA and source control for most teams.
Scroll down to "break issues into actionable tasks", and they have an example that's even labeled as an "Epic". They are definitely headed in the same direction as Gitlab.
Re: Gitlab Epic Issue Relationships Deleted
#15Earlier quoted context omitted.
I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent
Worst case in 2021 should be a daily full backup + transaction logs. That's enough to get you point in time recovery. On AWS, EBS snapshots are incremental (I didn't know that until studying for AWS certification), so you could schedule a snapshot every 5 minutes if you wanted. Looking at the timeline, I'm just gonna repeat something I said in another thread this week: it's easy to underestimate how long it takes to…
Restoring a new database from the AWS snapshot and transaction logs was literally faster.
Re: Gitlab Epic Issue Relationships Deleted
#16I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430
Huh. While trying to figure out the reasoning behind the name used, TIL that "epic" has acquired a new meaning of "(computing) In software development, a large or extended user story." https://en.wiktionary.org/wiki/epic
Re: Gitlab Epic Issue Relationships Deleted
#17Seems like they have it mostly resolved, the releationships were restored from a backup 3 hours prior to the incident, and they are working to restore the data for the 313 (sic.) items still affected: https://gitlab.com/gitlab-org/gitlab/-/issues/348547
I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent
A far more common setup is regular full backups, often daily though sometimes more/less frequent, with much smaller transaction log backups at high frequency, perhaps every 15 minutes, between. That way you lose at most what has happened since the last log backup, and you can restore to any point in time between the full backup and the last log backup. It takes more effort to restore as you need to first restore the full then restore (replay) the log backups in sequence until the point you care about.
Sometimes there is a third layer between: differential backups. These are usually much smaller than a full backup, while also smaller (and less faf/time to restore) than the log backups for the period they cover, but don't offer point-in-time recovery.
Re: Gitlab Epic Issue Relationships Deleted
#18I was confused by the title. Apparently epics are a way to organize issues by themes across projects. GitHub doesn't have this concept, in case anyone else was wondering. https://docs.gitlab.com/ee/user/group/epics/ https://github.community/t/epics-github-issues/1430
Huh. While trying to figure out the reasoning behind the name used, TIL that "epic" has acquired a new meaning of "(computing) In software development, a large or extended user story." https://en.wiktionary.org/wiki/epic
Re: Gitlab Epic Issue Relationships Deleted
#19Earlier quoted context omitted.
I am curious, how frequently does GitLab backup their DB? 3 hours seems pretty recent
For a full backup of a huge DB a three-hour window is pretty small, but I doubt that is what is happening here. A far more common setup is regular full backups, often daily though sometimes more/less frequent, with much smaller transaction log backups at high frequency, perhaps every 15 minutes, between. That way you lose at most what has happened since the last log backup, and you can restore to any point in time be…
Re: Gitlab Epic Issue Relationships Deleted
#20Seems like they have it mostly resolved, the releationships were restored from a backup 3 hours prior to the incident, and they are working to restore the data for the 313 (sic.) items still affected: https://gitlab.com/gitlab-org/gitlab/-/issues/348547