![]() With docker compose, using the -d flag runs the containers in the background. Note that background processes do not exit at the end of the step - They keep running until the whole job completes. In our end-to-end testing job, we start Docker dependencies while building the code so that the network requests can complete in the background and the containers are ready for the tests to begin. You can save time in your job by pulling dependencies while performing other work. Check out the GitHub documentation on artifacts to see how to achieve this. We have found uploading and downloading artifacts to be very fast, and we’ve seen substantial reductions in the total time taken by our workflows when using this strategy. Instead, we can use the improved strategy (pseudocode): install dependencies For our projects using Go, it’s easy to cross-compile for various platforms, meaning that only the run integration tests step needs to be run on each platform. That execution time is multiplied across each environment. In a complex project like Fleet, installing and building takes a substantial portion of the execution time. Try performing preparatory work in a separate job that only runs once per workflow, then fanning out to the build matrixĬonsider the naive matrix strategy (pseudocode): for each environment combination: The build matrix is a convenient way to run across combinations of environments. These tips can help save time and money while getting the most value from GitHub Actions. Here at Fleet, we make extensive use of GitHub Actions, and we want to share some tips that we’ve learned along the way. 4 tips for GitHub Actions usability (+2 bonus tips for debugging)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |