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

feat: plan queue functionality #1923

Closed
wants to merge 46 commits into from
Closed

feat: plan queue functionality #1923

wants to merge 46 commits into from

Conversation

ghaiszaher
Copy link
Contributor

@ghaiszaher ghaiszaher commented Nov 29, 2021

Relates to: #1722

Hey @nishkrishnan, based on above discussion, we are submitting this PR that provides plan queue functionality.

The implementation of the queue functionality is complete and the code is almost production-ready. We are seeking your assistance and would appreciate your feedback if this is the right direction and if this functionality could be considered.

We we have done so far:

  • Automatically entering the queue upon a plan request if another PR has the lock.
  • Granting the lock to the next PR in queue when the previous PR is unlocked (either via explicit atlantis unlock command, from Atlantis UI or by merging/closing the PR).
  • Notifying the author that the PR is ready to be planned for the unlocked environments/workspaces.
    • We avoided automatic planning because: 1) A PR can have more than one lock and not all of them might be released yet. 2) It was cumbersome to store the initial command in case extra arguments were passed.
  • Showing the queue in the main UI and in the locks view.
    image
    image

What is missing:

  • Feature flag to enable/disable the queue.
  • Handling plan errors in respect to the queue: currently the lock is released on plan error, which means we should either:
    • Grant the lock to the next person in the queue
    • Or change that behavior and not release the lock on plan errors
  • More commands to handle the queue: e.g. jump in front of the queue, or get out of the queue.
  • More test coverage.

Contributors

@monikma @amir-elgayed @ghaiszaher

ghaiszaher and others added 29 commits August 2, 2021 16:39
* Dequeue next on Atlantis unlock

* Dequeue next on PR cleanup (e.g. after closing)

* Quick fix

* Fix

* Reworked the TODOs, docu and a bit of refactoring
* Display queue details in index and lock-details pages
* feat: improving apply requirements for mergeable on Gitlab (#1675)

* Improving apply requirements for mergeable on Gitlab

* Fixing end of line

* Renaming variables

* Renaming variables

* Fixing variable assignment

* Fixing variable assignment

* fix ignore of --parallel-pool-size flag (#1705)

* Fixing apply permission when MR status is draft (#1736)

* Create bug_report.md (#1725)

* Refactor Apply Requirements into a Handler. (#1729)

* deps: tf 1.0.4 (#1748)

* build(deps): bump tar from 4.4.4 to 4.4.15 (#1733)

Bumps [tar](https://github.com/npm/node-tar) from 4.4.4 to 4.4.15.
- [Release notes](https://github.com/npm/node-tar/releases)
- [Changelog](https://github.com/npm/node-tar/blob/main/CHANGELOG.md)
- [Commits](isaacs/node-tar@v4.4.4...v4.4.15)

---
updated-dependencies:
- dependency-name: tar
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <[email protected]>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* build(deps): bump github.com/hashicorp/go-getter from 1.5.5 to 1.5.6 (#1728)

Bumps [github.com/hashicorp/go-getter](https://github.com/hashicorp/go-getter) from 1.5.5 to 1.5.6.
- [Release notes](https://github.com/hashicorp/go-getter/releases)
- [Changelog](https://github.com/hashicorp/go-getter/blob/main/.goreleaser.yml)
- [Commits](hashicorp/go-getter@v1.5.5...v1.5.6)

---
updated-dependencies:
- dependency-name: github.com/hashicorp/go-getter
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Co-authored-by: Lucas C <[email protected]>
Co-authored-by: Pavel Golubev <[email protected]>
Co-authored-by: Luke Kysow <[email protected]>
Co-authored-by: Aayush Gupta <[email protected]>
Co-authored-by: rui <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Revert the changes related to dequeue lock status message in original PR
* Move inline css to file
# Conflicts:
#	server/events/unlock_command_runner.go
GH-21 Change comment on unlock PR - notify lock creator
@ghaiszaher ghaiszaher changed the title [DRAFT] Plan queue functionality feat: plan queue functionality Nov 29, 2021
@jamengual jamengual added the waiting-on-review Waiting for a review from a maintainer label May 13, 2022
# Conflicts:
#	server/core/locking/mocks/mock_backend.go
#	server/events/unlock_command_runner.go
@ghaiszaher ghaiszaher marked this pull request as ready for review May 16, 2022 15:19
@ghaiszaher ghaiszaher requested a review from a team as a code owner May 16, 2022 15:19
@GabrielBB
Copy link

@ghaiszaher @monikma Great job

@amir-elgayed
Copy link

amir-elgayed commented May 17, 2022

This also relates to #305 but is technically different.

@majormoses As far as I understood, it is quiet different: This is about providing a queueing mechanism for plans cross different PRs that affect the same workspace (they compete for the same lock), if a lock is acquired by PR#1, plans from other PRs will enter a queue and will be notified when the lock is released by PR#1, whereas #305 is about plans on the same PR that is already holding the lock.

@jamengual
Copy link
Contributor

@ghaiszaher is there still interest in getting this merged?

@ghaiszaher
Copy link
Contributor Author

@ghaiszaher is there still interest in getting this merged?

@jamengual yes we are still interested, we'd appreciate any feedback on the current PR.

Copy link
Contributor

@lilincmu lilincmu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except for few nits, this looks great to me! Thank you all for your contribution! 🎉

One more nit from me is, it might be more readable if we define []models.ProjectLock to be a new type, such as ProjectLockQueue. When reading the code, sometimes I had to figure out whether []models.ProjectLock refers to a queue, or simply a list of locks, for example, that are just being unlocked by a PR.

server/events/project_locker.go Show resolved Hide resolved
server/core/db/boltdb.go Show resolved Hide resolved
server/core/db/boltdb.go Show resolved Hide resolved
server/core/db/boltdb.go Show resolved Hide resolved
server/core/locking/locking.go Show resolved Hide resolved
return c.backend.GetQueueByLock(project, workspace)
}

// TODO monikma extend the tests
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has this done? I'm guess you were going to verify DequeueStatus?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, and yes..

lock, err := l.Locker.Unlock(id)
func (l *DefaultDeleteLockCommand) DeleteLock(id string) (*models.ProjectLock, *models.ProjectLock, error) {
// TODO monikma extend the tests
// TODO monikma #9 When the lock(s) has(ve) been explicitly removed, also dequeue the next PR(s)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we going to extend the tests?

@@ -99,14 +99,15 @@ func (p *PullClosedExecutor) CleanUpPull(repo models.Repo, pull models.PullReque
}
}

// TODO monikma extend the tests
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has this done?

server/events/project_locker.go Show resolved Hide resolved
@@ -59,6 +59,7 @@ type TryLockResponse struct {

// TryLock implements ProjectLocker.TryLock.
func (p *DefaultProjectLocker) TryLock(log logging.SimpleLogging, pull models.PullRequest, user models.User, workspace string, project models.Project) (*TryLockResponse, error) {
// TODO monikma extend the tests
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has this done?

@jamengual
Copy link
Contributor

@ghaiszaher do you have any time to address the comments?

@monikma
Copy link

monikma commented Sep 21, 2022

@ghaiszaher do you have any time to address the comments?

@jamengual I tried to answer the comments, since Ghais is currently on vacation. First of all, @lilincmu thanks a lot for the review! Hopefully we can shorten the feedback cycle now, and make each next interaction exponentially quicker ;)

One more nit from me is, it might be more readable if we define []models.ProjectLock to be a new type, such as ProjectLockQueue. When reading the code, sometimes I had to figure out whether []models.ProjectLock refers to a queue, or simply a list of locks, for example, that are just being unlocked by a PR.

Makes a lot of sense to me.

About your questions on the tests - yes we have not implemented all of them, as we first wanted to check with you if this is some functionality that sounds like a good idea, and if how we go about implementing it would make sense to you (as mentioned in the PR description). So my understanding is "yes it does" ? :)

We could continue by applying the suggestions and extending tests. Would that make sense to you? What do you expect from us to call our PR "production ready", and get closer to merging it?

One topic we circled around but never properly got to, is feature flag to enable/disable the feature. If you had any suggestions there, it would be great (meaning how feature flags are usually approached in this codebase, we would not want to break some convention).

@ghaiszaher
Copy link
Contributor Author

@lilincmu @jamengual Since this PR was closed because the repo was deleted from the organization, I raised a new PR: #2782 which is in a better state now

cc @monikma @amir-elgayed

@ghaiszaher
Copy link
Contributor Author

Except for few nits, this looks great to me! Thank you all for your contribution! 🎉

One more nit from me is, it might be more readable if we define []models.ProjectLock to be a new type, such as ProjectLockQueue. When reading the code, sometimes I had to figure out whether []models.ProjectLock refers to a queue, or simply a list of locks, for example, that are just being unlocked by a PR.

Thank you @lilincmu, renamed as part of this commit: 06a83e3

ghaiszaher added a commit to ghaiszaher/atlantis that referenced this pull request Jan 29, 2023
ghaiszaher added a commit to ghaiszaher/atlantis that referenced this pull request Jan 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New functionality/enhancement waiting-on-review Waiting for a review from a maintainer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants