GitHub Actions თუ GitLab CI: უფასო წუთები რეალურ ხარჯს მალავს

|ავტორი: QUASA-ს სარედაქციო გუნდი|5 წთ საკითხავი
GitHub Actions თუ GitLab CI: უფასო წუთები რეალურ ხარჯს მალავს

მცირე კერძო გუნდისთვის GitHub Actions-ისა და GitLab CI-ის ფასი იმაზეა დამოკიდებული, რომელ hosted runner-ზე მუშაობს თითოეული job და რა კვოტა აქვს გუნდს. GitHub Actions-ის ბილინგის წესებით, GitHub Free კერძო რეპოზიტორიებისთვის თვეში 2 000 სტანდარტული runner-ის წუთს მოიცავს; კვოტის შემდეგ ორბირთვიანი Linux runner წუთში $0.006 ღირს, Windows — $0.010, ხოლო სტანდარტული macOS — $0.062. საჯარო რეპოზიტორიაში სტანდარტული GitHub-hosted runner უფასოა, დიდი runner კი კვოტის არსებობის შემთხვევაშიც ფასიანია.

GitLab-ის გამოთვლითი წუთების წესებით, GitLab.com-ის Free namespace თვეში 400 compute minute-ს იღებს. თითოეული job-ის მოხმარება მისი ხანგრძლივობა წამებში / 60 × cost factor ფორმულით ითვლება: Linux small-ის კოეფიციენტია 1, Linux medium-ის — 2, Windows medium-ის — 1, macOS M1 medium-ის — 6. ეს კოეფიციენტები დოლარული ტარიფები არ არის. ამიტომ მცირე კერძო Linux პროექტს, რომელიც GitLab-ის hosted კვოტას უკვე სცდება, მაგრამ GitHub-ის კვოტაში ეტევა, GitHub Actions-ზე გამოთვლითი გადასახადი არ ექნება; უკვე შეძენილ GitLab Premium გეგმაში კი დამატებითი job შეიძლება ჩართულ წუთებში მოთავსდეს.

ერთი თვის გამოსათვლელი შაბლონი

შედარების ერთეული job-ია და არა pipeline-ის დაწყებიდან დასრულებამდე გასული დრო. პარალელურად გაშვებული job-ებიც ცალ-ცალკე მოიხმარენ runner-ის დროს. Linux, Windows და macOS სამუშაოებისთვის ცალკე ჩაიწერეთ თვეში გაშვებების რაოდენობა, თითო გაშვებაში job-ების რაოდენობა, ერთი job-ის ხანგრძლივობა და runner-ის ზომა; თუ ხანგრძლივობა მერყეობს, საშუალოსთან ერთად დატვირთული თვეც გამოთვალეთ.

  • თითოეული ტიპის თვიური დრო მიიღეთ ასე: გაშვებები × ამ ტიპის job-ები ერთ გაშვებაში × ერთი job-ის წუთები. გადატვირთული ან წარუმატებელი job-ის ხელახალი გაშვებაც ცალკე დაამატეთ.
  • GitHub-ის კერძო პროექტისთვის სტანდარტული runner-ის მოხმარება ანგარიშის დარჩენილ კვოტას შეადარეთ. კვოტის შემდეგ თითოეული სისტემის ფასიანი დრო მის წუთობრივ ტარიფზე გაამრავლეთ; დიდი runner-ის დრო ცალკე, სრულ ფასად დაითვალეთ.
  • GitLab.com-ის hosted runner-ზე თითოეული job-ის დრო მის cost factor-ზე გაამრავლეთ და namespace-ის შედეგები შეკრიბეთ. მიღებული compute minute-ები შეადარეთ გეგმის კვოტას, ხოლო დანაკლისისთვის დამატებითი წუთების პაკეტები ჩასვით.
  • საბოლოო ჯამს მიუმატეთ მხოლოდ ის ლიცენზიები, საცავი და საკუთარი runner-ის ხარჯები, რომლებიც არჩევანის შედეგად ნამდვილად დაემატება გუნდს. უკვე შეძენილი გეგმის სრული ღირებულება და ახალი სამუშაოს დამატებითი ღირებულება ცალკე აჩვენეთ.

ეს შაბლონი ორივე პლატფორმისთვის ერთნაირ job-ების ნაკრებს უნდა ეფუძნებოდეს. თუ runner-ის შეცვლა build-ს აჩქარებს, ახალ ხანგრძლივობასთან ერთად ახალი ზომის ფასიც ჩაწერეთ. მხოლოდ ძველი დროის ახალ კოეფიციენტზე გამრავლება შეცდომაში შეგიყვანთ: სწრაფმა runner-მა შეიძლება მეტი ღირდეს წუთში, მაგრამ ნაკლები წუთი იმუშაოს.

რას ცვლის ოპერაციული სისტემა და runner-ის ზომა

Linux-ზე კვოტების შედარება შედარებით მარტივია, თუ ორივეგან მცირე სტანდარტულ მანქანას იყენებთ. Windows-ისა და macOS-ის შემთხვევაში ჯერ ხელმისაწვდომობა შეამოწმეთ, შემდეგ ფასი: GitHub-ს კვოტის შემდეგ თითოეული სისტემისთვის საკუთარი წუთობრივი ტარიფი აქვს, GitLab-ში კი hosted job-ის წუთები შესაბამისი კოეფიციენტით გარდაიქმნება. შერეული დატვირთვისას GitHub-ის მთელი უფასო კვოტა თითოეულ ოპერაციულ სისტემას ცალ-ცალკე არ ეკუთვნის.

macOS-ზე მხოლოდ წუთების შედარება განსაკუთრებით შეცდომაში შემყვანია. GitLab-ის macOS hosted runner-ები ბეტა რეჟიმშია და GitLab.com-ზე Premium და Ultimate მომხმარებლებისთვის, ასევე შესაბამისი ღია კოდის პროგრამებისთვისაა ხელმისაწვდომი. ჩვეულებრივ GitLab Free გუნდს macOS-ის დამატებითი compute minute-ების ფასი ცალკე ვერ უშველის — ჯერ runner-ზე წვდომისთვის საჭირო გეგმის ღირებულება უნდა გაითვალისწინოს. GitHub-ის დიდი runner-იც ცალკე ფასიანი არჩევანია, ამიტომ სტანდარტული და დიდი მანქანების დრო ერთ კალათაში არ მოათავსოთ.

პირობითად, თვეში 100 macOS build, თითოეული 10 წუთით, შესრულების 1 000 წუთს იძლევა. GitLab-ის M1 medium-ზე ეს 6 000 compute minute გახდებოდა, თუ ყველა job ერთნაირი ხანგრძლივობით დასრულდებოდა. ასეთი ანგარიში აჩვენებს კვოტის მოხმარებას და არა მზა გადასახადს: მასში ჯერ არც საჭირო ლიცენზიაა ჩართული და არც ის ცვლილება, რომელსაც სხვა runner-ზე build-ის რეალური სიჩქარე გამოიწვევდა.

საჯარო პროექტი და მცირე კერძო გუნდი

საჯარო პროექტისთვის GitHub-ის სტანდარტული hosted runner-ის უფასო გამოყენება ძლიერი საწყისი პირობაა. GitLab.com-ზე პროექტის საჯაროობა თავისთავად ულიმიტო compute minute-ებს არ ნიშნავს; GitLab for Open Source პროგრამაში მიღებულ საჯარო პროექტს შეღავათიანი კოეფიციენტი აქვს. შესაბამისად, საჯარო პროექტისა და პროგრამის მონაწილე პროექტის ხარჯი სხვადასხვა სცენარად უნდა დაითვალოთ.

კერძო გუნდზე გავლენას ლიცენზიაც ახდენს. GitLab-ის ფასების გვერდზე Premium მითითებულია $29-ად მომხმარებელზე თვეში, წლიური გადახდით; გეგმა თვეში 10 000 compute minute-ს მოიცავს, დამატებითი 1 000 წუთის პაკეტი კი $10 ღირს. GitLab.com Free-ის კერძო ზედა დონის ჯგუფს ხუთი მომხმარებლის ზღვარი აქვს. Premium-ის წუთები მთელ ჯგუფს ეკუთვნის და ადგილების რაოდენობის ზრდასთან ერთად არ მრავლდება.

პირობითი მაგალითი: გუნდი თვეში 100 Linux build-ს უშვებს და თითოეული 8 წუთს გრძელდება. მიღებული 800 წუთი GitHub Free-ის სტანდარტულ კვოტაში ეტევა, GitLab Free-ის hosted კვოტას კი 400 წუთით სცდება. თუ გუნდს სხვა მოხმარება არ აქვს, GitLab-ზე დამატებითი წუთების ერთი პაკეტი დასჭირდება; მხოლოდ ამ დატვირთვისთვის Premium-ის შეძენა ადგილების ხარჯსაც დაამატებდა. ორივე უფასო კვოტაში მოთავსებულ უფრო მცირე დატვირთვაზე გამოთვლითი გადასახადი ორივეგან ნულის ტოლი იქნებოდა.

მაღალი მოცულობა და უკვე შეძენილი გეგმა

პირობითად, თვეში 8 000 Linux build-წუთი, ერთნაირი ხანგრძლივობისა და სხვა მოხმარების გარეშე, GitHub Free-ზე 2 000 ჩართული წუთის შემდეგ 6 000 ფასიან წუთს დატოვებს: ორბირთვიანი Linux runner-ის გამოთვლითი ფასი $36 იქნება. GitLab Free-ზე Linux small runner იმავე დროს 8 000 compute minute-დ ჩათვლის; 400 ჩართული წუთის შემდეგ 7 600 წუთის დასაფარად რვა დამატებითი პაკეტი, ანუ $80, იქნება საჭირო. მაგალითი ფასებს ადარებს თანაბარი შესრულების დროით და არ ამტკიცებს, რომ ორი runner რეალურ build-ს ერთნაირ დროში დაასრულებს.

იმავე პირობითი დატვირთვა GitLab Premium-ის ჩართულ 10 000 წუთში მოთავსდება. თუ კომპანიამ ეს გეგმა თანამშრომლობის სხვა საჭიროებებისთვის უკვე შეიძინა, ახალი job-ების დამატებითი გამოთვლითი გადასახადი შეიძლება ნული იყოს. თუ გეგმა მხოლოდ CI-სთვის უნდა იყიდოს, ხუთი ფასიანი ადგილის თვიური ეკვივალენტი $145 გამოდის წლიური გადახდის პირობით და GitHub-ის ზემოთ დათვლილ გამოთვლით ხარჯს აღემატება. გადაწყვეტილებას სწორედ ამ ორი განსხვავებული ფინანსური მდგომარეობის გარჩევა ცვლის.

საკუთარი runner და შენახვის ხარჯი

თვითჰოსტირებული runner hosted წუთების კვოტაზე დამოკიდებულებას ამცირებს, მაგრამ გამოთვლითი რესურსი თავად გუნდმა უნდა უზრუნველყოს. GitHub Actions თვითჰოსტირებული runner-ის გამოყენებისთვის პლატფორმის წუთობრივ გადასახადს არ აწესებს; GitLab.com-ზე პროექტისა და ჯგუფის საკუთარი runner-ების job-ები hosted instance runner-ის compute კვოტას არ ხარჯავს. შედარებაში ჩასვით მანქანის ან ღრუბლოვანი რესურსის, განახლებების, გამართვისა და გაუმართაობაზე დახარჯული დროის ფასი. მცირე დატვირთვისას ამ მუდმივმა ხარჯმა hosted ვარიანტის ეკონომია შეიძლება გადაფაროს.

შენახვაც ცალკე სტრიქონია. GitHub-ზე არტეფაქტებსა და Packages-ს საერთო საცავის კვოტა აქვთ, cache კი ცალკე აღირიცხება; კვოტის გადაჭარბებისას შენახვის გადასახადი runner-ის წუთებისგან დამოუკიდებლად გროვდება. GitLab.com-ის საცავის წესებში Free პროექტისთვის მითითებული 10 GiB რეპოზიტორიასა და LFS-ს ეხება, ხოლო build-ის არტეფაქტები ამ კონკრეტულ ლიმიტში არ შედის. ამიტომ GitHub-ის არტეფაქტების ბილინგი GitLab-ის რეპოზიტორიის ლიმიტს პირდაპირ არ შეადაროთ: თითოეული საცავის კატეგორია და მისი გამოყენების პირობა ცალკე შეიტანეთ თვიურ ჯამში.

ასევე წაიკითხეთ:

გაზიარება:

მსგავსი სტატიები

გამოიწერეთ ჩვენი ბიულეტენი

მიიღეთ უახლესი ამბები Web3-ის, AI-სა და კრიპტოს შესახებ პირდაპირ თქვენს ელფოსტაზე.

0