Slow CI builds #734

New Issue

GiteaMirror · 2025-11-02T03:34:27-06:00

GiteaMirror commented

2025-11-02 03:34:27 -06:00

Originally created by @ethantkoenig on GitHub (May 24, 2017).

Our CI builds are very slow (can take up to an hour). #1783 will help, but that will only reduce the durations of some CI builds (and those builds will still take >20 minutes).

make release usually takes about 20 minutes to complete in Drone. Is it absolutely necessary for us to compile to every supported architecture in every build? What is running make release supposed to ensure/accomplish?

Originally created by @ethantkoenig on GitHub (May 24, 2017). Our CI builds are very slow (can take up to an hour). #1783 will help, but that will only reduce the durations of some CI builds (and those builds will still take >20 minutes). `make release` usually takes about 20 minutes to complete in Drone. Is it absolutely necessary for us to compile to every supported architecture in every build? What is running `make release` supposed to ensure/accomplish?

GiteaMirror added the topic/build label 2025-11-02 03:34:27 -06:00

GiteaMirror closed this issue

2025-11-02 03:34:27 -06:00

GiteaMirror commented

2025-11-02 03:34:28 -06:00

@lunny commented on GitHub (May 24, 2017):

for Pull Request, make release is no need I think.

@lunny commented on GitHub (May 24, 2017): for Pull Request, `make release` is no need I think.

GiteaMirror commented

2025-11-02 03:34:28 -06:00

@ethantkoenig commented on GitHub (May 24, 2017):

Only for tag builds?

@ethantkoenig commented on GitHub (May 24, 2017): Only for tag builds?

GiteaMirror commented

2025-11-02 03:34:28 -06:00

@lunny commented on GitHub (May 24, 2017):

@ethantkoenig Not only tags. Also master and other branches since we provides these downloads on https://dl.gitea.io

@lunny commented on GitHub (May 24, 2017): @ethantkoenig Not only tags. Also master and other branches since we provides these downloads on https://dl.gitea.io

GiteaMirror commented

2025-11-02 03:34:29 -06:00

@lunny commented on GitHub (May 24, 2017):

@tboerger @bkcsoft @appleboy

@lunny commented on GitHub (May 24, 2017): @tboerger @bkcsoft @appleboy

GiteaMirror commented

2025-11-02 03:34:29 -06:00

@DblK commented on GitHub (May 27, 2017):

Is this linked to #1783? If yes, maybe we can close it.

@DblK commented on GitHub (May 27, 2017): Is this linked to #1783? If yes, maybe we can close it.

GiteaMirror commented

2025-11-02 03:34:29 -06:00

@appleboy commented on GitHub (May 29, 2017):

@DblK @lunny I will make new PR to fix @tboerger comments https://github.com/go-gitea/gitea/pull/1783#issuecomment-304476001

@appleboy commented on GitHub (May 29, 2017): @DblK @lunny I will make new PR to fix @tboerger comments https://github.com/go-gitea/gitea/pull/1783#issuecomment-304476001

GiteaMirror commented

2025-11-02 03:34:29 -06:00

@ethantkoenig commented on GitHub (Jun 2, 2017):

Would it be possible to cache compiled vendor/ packages that are generated in make release, and reuse them across different builds? The contents of vendor/ rarely change, so it seems like a waste to repeatedly recompile them (multiple times, once for each supported architecture) every build.

@ethantkoenig commented on GitHub (Jun 2, 2017): Would it be possible to cache compiled `vendor/` packages that are generated in `make release`, and reuse them across different builds? The contents of `vendor/` rarely change, so it seems like a waste to repeatedly recompile them (multiple times, once for each supported architecture) every build.

GiteaMirror commented

2025-11-02 03:34:30 -06:00

@lunny commented on GitHub (Dec 12, 2017):

This has been resolved.

@lunny commented on GitHub (Dec 12, 2017): This has been resolved.

GiteaMirror referenced this issue

2025-11-02 11:49:10 -06:00

[PR #734] [MERGED] public/img: reduce the size of PNG images #15549

Sign in to join this conversation.