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

Re-evaluate our current approach to CI #2969

Open
jessebraham opened this issue Jan 15, 2025 · 0 comments
Open

Re-evaluate our current approach to CI #2969

jessebraham opened this issue Jan 15, 2025 · 0 comments
Labels
CI Continuous integration/deployment RFC Request for comment
Milestone

Comments

@jessebraham
Copy link
Member

jessebraham commented Jan 15, 2025

There are presently a number of issues with our current CI pipeline(s), many of which resulted naturally as a result of the growth of the repository. However, I feel we're reaching a bit of a tipping point here and need to re-evaluate this to better suit our needs and give us a bit more confidence in the checks being performed.

For starters, I suspect we're performing a lot of the checks multiple times. CI runs in PRs, the merge queue, and then again once merged into main. While not all checks are necessarily performed at each stage, it's quite common for a few PRs to be opened/updated in succession and cause quite a backlog due to the limit of 20 concurrent runners. Much of this congestion is likely avoidable.

Additionally, checks are not being performed consistently across packages. MSRV checks are not being run for each package (in which case, we can't really guarantee this version, can we?), and likewise we need to do better with checking documentation builds. I suspect running documentation builds nightly is adequate, and on failure we can have the workflow open an issue or something.

Another issue is with the nightly checks, in which new errors crop up quite often, and are easy to ignore. Again, opening an issue upon failure is probably a good option.

It would also be nice if we could automatically run the documentation workflow upon creation of a release.

Maybe we can utilize our self-hosted runner VMs as well; this is worth investigating.

We likely want to add a seperate check to only check the stable subset of esp-hal (from #2998)

We might also want to take the time (again :D) to look into semver checks, now that we will have a stable release to compare it to.

Regardless, there's a fair bit to discuss I think, and a pretty serious overall may be in order. If anybody else has thoughts regarding this please comment in this issue.

@MabezDev @tom-borcin can we please schedule a meeting to discuss this at some point in the future? Doesn't have to be right away, but sooner would be better than later probably.

@jessebraham jessebraham added the CI Continuous integration/deployment label Jan 15, 2025
@playfulFence playfulFence added the RFC Request for comment label Jan 17, 2025
@MabezDev MabezDev added this to the 1.0.0-beta.1 milestone Jan 23, 2025
@MabezDev MabezDev marked this as a duplicate of #2998 Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous integration/deployment RFC Request for comment
Projects
Status: Todo
Development

No branches or pull requests

3 participants