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

Add full build workflow to check every variation of the project on MacOS #8276

Closed
wants to merge 1 commit into from

Conversation

wmontwe
Copy link
Member

@wmontwe wmontwe commented Oct 8, 2024

This adds a new workflow to run the build command to check all variants of the app. This should help to catch issues early in the process. It uses the MacOS runner to also cover these development machines.

@wmontwe wmontwe requested a review from cketti as a code owner October 8, 2024 18:43
@wmontwe wmontwe requested a review from kewisch October 8, 2024 18:44
@wmontwe wmontwe force-pushed the add-full-build-workflow branch from 9ada920 to 4341d3c Compare October 9, 2024 08:35
@wmontwe wmontwe changed the title Add full build workflow to check every variation of the project Add full build workflow to check every variation of the project on MacOS Oct 9, 2024
@cketti
Copy link
Member

cketti commented Oct 9, 2024

I don't think we should run a full build on every update to a pull request. It takes forever and I think it's unlikely to catch a lot of errors.

Once we have daily builds, we'll get a full build run every day (with changes to the main branch). I don't think it's a problem that we'll then only catch rare issues after the changes have been merged. We can fix the problem the day after the failed daily run.

@kewisch
Copy link
Member

kewisch commented Oct 9, 2024

If we do this on pull request, then we should probably use a matrix strategy to build in parallel. This way the time does not increase. @wmontwe how do you feel about only doing this on main with daily builds? It might have the downside that if there is an issue from a contributor, they might be long gone and we have to deal with the fallout or back out the patch.

@wmontwe
Copy link
Member Author

wmontwe commented Oct 9, 2024

We could do this as part of the daily build with an additional workflow trigger to start it on demand. Due to different platforms used to develop the app, there is a risk that failures will enter main unnoticed.

And yes, this new workflow setup is not sofisticated and could be optimized, so it might take less time to execute.

There is also the GitHub feature to create a merge queue that could run a full test suite before merging into main and avoid heavy builds on pull-request updates. See: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request-with-a-merge-queue

The beauty of that approach is that a merge is also validated aggainst the most recent state of main, ensuring that it will work well.

@kewisch
Copy link
Member

kewisch commented Oct 10, 2024

I'm liking the merge queue thing. Let's agree on something in the next team meeting.

@wmontwe
Copy link
Member Author

wmontwe commented Oct 15, 2024

Closing in favor of a more sophisticated version

@wmontwe wmontwe closed this Oct 15, 2024
@wmontwe
Copy link
Member Author

wmontwe commented Oct 17, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants