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

Improve the oldest_stopped algorithm #30

Open
sbidoul opened this issue Dec 3, 2021 · 2 comments
Open

Improve the oldest_stopped algorithm #30

sbidoul opened this issue Dec 3, 2021 · 2 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@sbidoul
Copy link
Owner

sbidoul commented Dec 3, 2021

Currently the oldest_stopped algorithm that is used by the undeployer protects the build for the last commit of each branch (non-PR) build.

The algorithm could be made smarter by also returning these for undeployment, and giving lower undeployment priority to the last commit of each PR too.

  • first undeploy builds by creation order, excluding the last build of each repo/target-branch/pr
  • then undeploy the last commit of prs
  • then undeploy the last commit of branches (non-PR)
@sbidoul sbidoul added the enhancement New feature or request label Dec 3, 2021
@simahawk
Copy link

simahawk commented Dec 4, 2021

Wondering: would it be easy/convenient/helpful to trigger runboat build only on demand to avoid building every time?
Something like /ocabot runboat [build|run], or using a label.
All in all we don't always need to test manually.

@sbidoul sbidoul added the good first issue Good for newcomers label Dec 4, 2021
@sbidoul
Copy link
Owner Author

sbidoul commented Dec 4, 2021

@simahawk I chose to optimize the experience for functional people who want to test PRs or main branches. With the current approach (since they usually come at least a little while after the commit), they click start and have an instance ready to use within a few seconds. If they had to wait for a full build that would be minutes, which disrupts the flow. The drawback is energy spending for builds that will never be started. Tradeoffs, as always.

BTW, I'm setting the good first issue label on this one as there is a test and it's just a matter of udpating the test and adjusting the SQL query.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants