Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update CI tooling for raku/doc #4195

Open
melezhik opened this issue Feb 8, 2023 · 2 comments
Open

Update CI tooling for raku/doc #4195

melezhik opened this issue Feb 8, 2023 · 2 comments
Assignees
Labels

Comments

@melezhik
Copy link
Contributor

melezhik commented Feb 8, 2023

Hi ! After a short talk with @coke creating this suggestion ticket.

https://irclogs.raku.org/raku/2023-02-08.html#01:31-0001

@melezhik melezhik added the docs Documentation issue (primary issue type) label Feb 8, 2023
@coke coke added the devops label Feb 8, 2023
@coke coke added this to the 2023-First Quarter milestone Feb 8, 2023
@coke coke removed the docs Documentation issue (primary issue type) label Feb 10, 2023
@coke
Copy link
Collaborator

coke commented Feb 28, 2023

My cleanup has probably broken the existing CI we had for tests @dontlaugh, any recommendations for how we should be running our CI tests?

We need:

  • a prebuilt raku and zef, (that we can update after each release) and prove (or perhaps prove6)
  • preferably pre-installed deps
  • A way to (manually is fine) rebuild the test agent when deps change, or raku is updated, etc.

In my opinion, we're fine running tests ONLY on the files that changed for the given commit, but if we do that, we need to definitely monitor when they failed and make them green when they're clear. This makes it more complicated than just running all tests for everything and then we can ignore all previous failures when we get any 100% pass.

@dontlaugh
Copy link

I have some infra work to do to facilitate this. Here is the architecture I'm going to pursue (it's what I've implemented for $DAYJOB, as well as for my personal servers).

Compute Substrate

  • We provision a linux server running LXD.
  • We use Packer to create pre-baked LXD images that
    • Can build Raku and zef from source
    • Install CI agents for running builds
    • Can provide zef, raku, etc. to a CI build process at runtime

The current CI setup for Raku/doc-website is effectively doing all this already, but I need to migrate that stuff into the shared Hetzner account where we are now running docs.raku.org

Config Backup

The Packer files will be checked into Raku/infra; container builds (in this case, LXD containers) are not exactly idempotent (since running apt get foo can technically yield different results over time), but it's good enough.


Our current CI for Raku/doc-website already uses this architecture. I just need to re-implement it in the common Hetzner account.

@coke coke changed the title Possible usage of SparrowCI for some CI tasks Update CI tooling for raku/doc Mar 1, 2023
@coke coke modified the milestones: 2023-Quarter 1, 2023-Quarter 2 Apr 1, 2023
@coke coke modified the milestones: 2023-Quarter 2, 2023-Quarter 3 Jul 12, 2023
@coke coke modified the milestones: 2023-Quarter 3, 2023-Quarter 4 Oct 8, 2023
@coke coke added devops and removed devops labels Oct 8, 2023
@coke coke modified the milestones: 2023-Quarter 4, 2024-Quarter-2 Mar 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants