-
Notifications
You must be signed in to change notification settings - Fork 735
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
Speedup the CI #3029
Comments
As stated in the [documentation](https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#changing-the-languages-that-are-analyzed): > CodeQL code scanning automatically detects code written in the supported languages. This will also reduce the number of CodeQL jobs from two to one. See miniflux#3029
As stated in the [documentation](https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning#changing-the-languages-that-are-analyzed): > CodeQL code scanning automatically detects code written in the supported languages. This will also reduce the number of CodeQL jobs from two to one. See #3029
Regarding the Linux packaging phase, it's possible that tools like GoReleaser or nfpm are faster because there is no need to use containers and Qemu, but I never tried it. |
Do we really need to build debian pacakages for every architectures for every pull-request? |
Short answer yes. I believe it was discussed previously in this thread. As you mentioned, cross-compilation might catch most problems, but I don't want to be in a situation where the Debian package is broken when it's time to release a tagged version. If the CI speed is really a concern, I'm okay to run this job on a daily basis instead of each pull-request. |
I think weekly basis would be enough: one has to really try hard to break things in a platform-specific way. I think™ it's a concern, as all the other jobs are done in 2 minutes, while this one takes 20 minutes. |
The CI is now down to ~2 minutes \o/ |
Currently, the CI is quite slow (around 20 minutes to run), it would be nice to speed it up a bit, to make it more pleasant to send pull-requests, but also to avoid burning electricity/resources for nothing.
systemd
to build miniflux on RHEL? Replace %{?systemd_requires} with%{?systemd_ordering} #3036go vet ./...
taking 30s?! Don't rungo vet ./...
as it's run as part of golangci-lint #3033-cover
? Only run-race -cover
on ubuntu in the CI #3035-race
? Maybe doing it only a single one would be enough. Only run-race -cover
on ubuntu in the CI #3035The text was updated successfully, but these errors were encountered: