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

Speedup the CI #3029

Closed
8 tasks done
jvoisin opened this issue Dec 21, 2024 · 6 comments
Closed
8 tasks done

Speedup the CI #3029

jvoisin opened this issue Dec 21, 2024 · 6 comments
Assignees
Labels

Comments

@jvoisin
Copy link
Collaborator

jvoisin commented Dec 21, 2024

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.

@jvoisin jvoisin self-assigned this Dec 21, 2024
jvoisin added a commit to jvoisin/v2 that referenced this issue Dec 22, 2024
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
fguillot pushed a commit that referenced this issue Dec 23, 2024
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
@fguillot
Copy link
Member

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.

@jvoisin
Copy link
Collaborator Author

jvoisin commented Dec 25, 2024

Do we really need to build debian pacakages for every architectures for every pull-request?

@fguillot
Copy link
Member

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.

@jvoisin
Copy link
Collaborator Author

jvoisin commented Dec 26, 2024

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.

@fguillot
Copy link
Member

#3043 - ci: avoid building Linux packages for each pull-request
#3044 - ci: run Docker tests only when the Dockerfiles are modified

@jvoisin
Copy link
Collaborator Author

jvoisin commented Dec 27, 2024

The CI is now down to ~2 minutes \o/

@jvoisin jvoisin closed this as completed Dec 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants