kotovalexarian-likes-github/capistrano
1
0
Fork 0
mirror of https://github.com/capistrano/capistrano synced 2023-03-27 23:21:18 -04:00
Code Releases Activity
capistrano/features/deploy.feature

89 lines
3.1 KiB
Gherkin
Raw Normal View History

Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
Feature: Deploy
Background:
Given a test app with the default configuration
And servers with the roles app and web
Scenario: Creating the repo
When I run cap "git:check"
Update assertions for 'git:check' test scenario Capistrano 'git:check' task executes a `git ls-remote -h #{repo_url}` command to check if remote repo is accessible. If successful, command output is a list of references and their SHAs. Task should be successful and we're pretty sure remote repo will have a `master` reference, so that's what we're asserting. We're NOT asserting: * repo references other than master - likely to change * reference SHAs - will definitely change
2014-04-25 16:03:22 -04:00
Then the task is successful
Restricting the uploaded git wrapper file permissions to 700. Additional step in the 'Creating the repo' scenario to test this adjustment.
2016-05-17 10:25:38 -04:00
And git wrapper permissions are 0700
Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
Scenario: Creating the directory structure
When I run cap "deploy:check:directories"
Then the shared path is created
And the releases path is created
Scenario: Creating linked directories
When I run cap "deploy:check:linked_dirs"
Then directories in :linked_dirs are created in shared
Scenario: Creating linked directories for linked files
When I run cap "deploy:check:make_linked_dirs"
Then directories referenced in :linked_files are created in shared
Scenario: Checking linked files - missing file
Update 'checking linked files' cucumber scenarios 'Checking linked files' scenarios were passing, but the steps were not defined at all. This commit defines the required steps.
2014-04-26 07:27:24 -04:00
Given a linked file "missing_file.txt"
But file "missing_file.txt" does not exist in shared path
Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
When I run cap "deploy:check:linked_files"
Update 'checking linked files' cucumber scenarios 'Checking linked files' scenarios were passing, but the steps were not defined at all. This commit defines the required steps.
2014-04-26 07:27:24 -04:00
Then the task fails
Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
Scenario: Checking linked files - file exists
Update 'checking linked files' cucumber scenarios 'Checking linked files' scenarios were passing, but the steps were not defined at all. This commit defines the required steps.
2014-04-26 07:27:24 -04:00
Given a linked file "existing_file.txt"
And file "existing_file.txt" exists in shared path
Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
When I run cap "deploy:check:linked_files"
Replace an assertion without implementation with the one that works
2014-04-25 17:32:33 -04:00
Then the task is successful
Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
Scenario: Creating a release
Merge branch '3.1.x' Conflicts: CHANGELOG.md README.md lib/capistrano/tasks/git.rake lib/capistrano/templates/deploy.rb.erb
2013-11-02 07:08:10 -04:00
Given I run cap "deploy:check:directories"
Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
When I run cap "git:create_release" as part of a release
Then the repo is cloned
And the release is created
Scenario: Symlink linked files
Update 'symlink linked files' cucumber scenario When `deploy:symlink:linked_files` task is executed, only the release path (containing the timestamp) is created. After the task is done, it is hard to navigate over that release path (again, because it's a timestamp) to perform the assertions. To solve the issue, we're additionally creating a current path because the assertion is much more easily done via `current_path`.
2014-04-26 08:30:55 -04:00
When I run cap "deploy:symlink:linked_files deploy:symlink:release" as part of a release
Integration tests with Vagrant and Cucumber This commit removes the existing 'local' integration tests and replaces them with Cucumber features running against VMs. At this stage, some of the assertions are pending due to the limited nature of the response returned when executing commands through Vagrant, but the framework is there as a starting point to build upon. To run the suite: bundle exec cucumber During development, avoid scraping the VM between runs: bundle exec cucumber KEEPING_RUNNING=1 Ultimately I would like to see the `TestApp` helpers along with the Vagrant integration packaged and available for use when developing gems that work with Cap. For now though, this closes #641
2013-09-27 06:45:55 -04:00
Then file symlinks are created in the new release
Scenario: Symlink linked dirs
When I run cap "deploy:symlink:linked_dirs" as part of a release
Then directory symlinks are created in the new release
Scenario: Publishing
When I run cap "deploy:symlink:release"
Then the current directory will be a symlink to the release
deploy:cleanup should skip only the invalid releases and continue the rotation of releases (#1899) * deploy:cleanup should skip only the invalid releases and continue the rotation of releases * Add cucumber tests for deploy:cleanup * PR feedback * rebase on master * add ruby 2.4.1 to specs * vagrant works with bundler 1.15.3 * remove unnecessary command
2017-07-22 19:15:44 -04:00
Scenario: Cleanup
Given config stage file has line "set :keep_releases, 3"
And 5 valid existing releases
And an invalid release named "new"
When I run cap "deploy:cleanup"
Then 3 valid releases are kept
And the invalid "new" release is ignored
Prevents last good release from being deleted on cleanup (#1922) * Prevents last good release from being deleted on cleanup Issue: 1907 If there are many failed deployments the relese folders will still be left there and eventually if deploy:cleanup is executed it will delete the release that is referenced by the "current" symlink, potentially causing downtime. That change will prevent the "current release" from ever being removed during cleanup. * Link PR on CHANGELOG * Verify if current dir exists Check if current release directory exists instead of relying on exceptions being raised.
2017-10-12 15:40:57 -04:00
Scenario: Cleanup after many failed releases doesn't remove last good release
Given config stage file has line "set :keep_releases, 2"
And I make 2 deployments
And an invalid release named "77777777777777"
And an invalid release named "88888888888888"
And an invalid release named "99999999999999"
When I run cap "deploy:cleanup"
Then 3 valid releases are kept
And the current directory will be a symlink to the release
Batch rm -rf calls in deploy:cleanup. (#2027)
2019-08-28 21:17:26 -04:00
Scenario: Cleanup when there are more releases than arguments can handle
Given config stage file has line "set :keep_releases, 3"
And 5000 valid existing releases
When I run cap "deploy:cleanup"
Then 3 valid releases are kept
Adds acceptance test for rollback feature. (#1891) * #1736 Adds acceptance test for rollback feature. * Made vagrant_cli_command function return values explicitly over setting instance variables.
2017-07-04 22:02:58 -04:00
Scenario: Rolling Back
Given I make 2 deployments
When I run cap "deploy:rollback"
Then the current symlink points to the previous release
Scenario: Rolling Back to a specific release
Given I make 3 deployments
When I rollback to a specific release
Then the current symlink points to that specific release
deploy:cleanup should skip only the invalid releases and continue the rotation of releases (#1899) * deploy:cleanup should skip only the invalid releases and continue the rotation of releases * Add cucumber tests for deploy:cleanup * PR feedback * rebase on master * add ruby 2.4.1 to specs * vagrant works with bundler 1.15.3 * remove unnecessary command
2017-07-22 19:15:44 -04:00
Copy permalink