search

racket / racket-ci

Repo for organizing CI efforts
MIT License
6 stars 1 forks source link

Vision 2021 #8

Open pmatos opened 3 years ago

pmatos commented 3 years ago

Welcome to 2021 - I know I am a month late, but I will try to pack as much as possible in the 11months that are left.

I had some time to sit down with some coffee and think about what I would love to see in Racket CI towards the end of this year. I won't be able to do everything on my own, but I will work in this direction. Furthermore, I welcome input, suggestions, complaints, and if possible, help.

Some of the items that follow are leftovers from Vision 2020 (#4) that are still relevant and others are from other issues here (like #7, #3, #2).

High Level Items (in no specific order):

Small Fixes/Additions (in no specific order):

After some discussion and everyone is on the same page, I will write a blog post about this, so your input is welcome. Feel free to comment even if you do not want to work on this. Input is always welcome.

sorawee commented 3 years ago

Should we add DSL for workflow files?

pmatos commented 3 years ago

Should we add DSL for workflow files?

Doh - I had that in my notes and forgot. I had it in prose in #4 and I will add it as an item. Thanks

rfindler commented 3 years ago

There is a pkg-build running at Northwestern that occasionally I have trouble with (it is running on a machine that just sits in a room in the department) but mostly works. Is there a way that its results might become more visible to people through your efforts? I think there are plenty of people that just don't know that things aren't working in their packages. ~https://plt.eecs.northwestern.edu/pkg-build/~ (finally got the domain name fixed)

https://plt.cs.northwestern.edu/pkg-build/

pmatos commented 3 years ago

hi @rfindler - that's really interesting. I didn't know about that pkg-build. Would you want to move the build process as well? I think both are possible, we could easily include the results on the future dashboard that we are planning or even move the build to a nightly schedule on github vms. What is your preference?

pmatos commented 3 years ago

@rfindler there's a cool possible integration, which is to optionally open a bug report automatically for packages hosted publicly on github if pkg-build fails to build.

rfindler commented 3 years ago

hi @rfindler - that's really interesting. I didn't know about that pkg-build. Would you want to move the build process as well? I think both are possible, we could easily include the results on the future dashboard that we are planning or even move the build to a nightly schedule on github vms. What is your preference?

I have to say I don't really know what's being offered here! :) Matthew and I have been running these snapshot builds for quite a while now using various VMs in a kind of hodge podge of configurations that seemed useful. As for moving that or the snapshot pkg build to github's VMs, I'd be worried about the cost. It would certainly be nice to reduce the amount of IT work I do, but it does take several hours (with 16 way parallelism on a 8 year old (but expensive at the time) machine) to run the pkg build.

@rfindler there's a cool possible integration, which is to optionally open a bug report automatically for packages hosted publicly on github if pkg-build fails to build.

That sounds great! There is the problem that occasionally the pkg build fails for reasons that aren't the pkg itself's fault so maybe we should build in some kind of redundancy (like it has to fail a few times or a human blesses the specific list in a simple way before the issues get opened or something)?

pmatos commented 3 years ago

hi @rfindler - that's really interesting. I didn't know about that pkg-build. Would you want to move the build process as well? I think both are possible, we could easily include the results on the future dashboard that we are planning or even move the build to a nightly schedule on github vms. What is your preference?

I have to say I don't really know what's being offered here! :) Matthew and I have been running these snapshot builds for quite a while now using various VMs in a kind of hodge podge of configurations that seemed useful. As for moving that or the snapshot pkg build to github's VMs, I'd be worried about the cost. It would certainly be nice to reduce the amount of IT work I do, but it does take several hours (with 16 way parallelism on a 8 year old (but expensive at the time) machine) to run the pkg build.

That's an easy question to answer. Here's what's being offered - I don't unfortunately work on Racket full time but my free time is dedicated to Racket. I would like to focus more on the compiler internals but I think CI is important so I will do the work I can if nobody else steps forward. I have no agenda except to suggest stuff and do it as I go along. If the core team asks me to prioritize, I will because... I have no agenda. So, if you ask me, can you plese do this? I will. With regards to machines, I have a 40 core machine that I can dedicate to this through a github runner. We can add it as a github runner and setup a workflow to do this if you want to replace your server and forget about maintenance. At least then, if we have a workflow to do the work everyone can contribute to it and the action itself will run on my server instead.

@rfindler there's a cool possible integration, which is to optionally open a bug report automatically for packages hosted publicly on github if pkg-build fails to build.

That sounds great! There is the problem that occasionally the pkg build fails for reasons that aren't the pkg itself's fault so maybe we should build in some kind of redundancy (like it has to fail a few times or a human blesses the specific list in a simple way before the issues get opened or something)?

That would be a second step but certainly sounds doable.

All in all, I want to emphasize that I started doing CI for Racket because I thought it would be fun to get some CI done at a point where there was nothing. So getting started was easy. Things just developed from there. But in the end I want to do what's better for the Racket community and those who benefit directly from CI - the main devs. If there's another priority that's not above let me know. The whole purpose of these "Vision 202x" posts are to understand if I am missing something that people want/need.

As mentioned in the original post, I won't be able to do everything this year. If others help, great. If not, I will slowly try to tick things off the list and recompile it in 2022. I have other things I want to do within the Racket Ecosystem, therefore other people contributing to CI would help me to do more work elsewhere.

pmatos commented 3 years ago

I added to the list slack notifications for github actions but missed @samth did this already (https://github.com/racket/racket/blob/3a49533ff52364684a6f7e2753e6811378f72008/.github/workflows/ci-push-x86_linux.yml#L416). Anything else to do here @samth ?