travis_dpl_test 2.0.3.beta.4.ror

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: d08df3f0f3f3b81f2f9c520a77de0e0b38758b3a41486615034900319327dce4
+  data.tar.gz: ec81722675eb11831503f8b6bf95dd6ce1d4f75414d91d603c5af5a21e334bc2
+SHA512:
+  metadata.gz: 20e5e997be77c6d9b184537e0c06b3c3226df64fc7a639a4cb2e8fdf0a78a8e5ba946e1d88e17f34327426c19f7fbc03a27e5ba871971c626dfb32607e10ac88
+  data.tar.gz: 99a2d508c87c9e3b679f0696ebd123967dda59f2d9b1bf117eed213f60e6eaa851e2be111e2bb3fe77dc5d0912991eb47b1e17b164712c7596446eedc4fba192

data/CHANGELOG.md

@@ -0,0 +1,172 @@
+# Changelog
+
+## dpl v2.0.3-beta.1 (2022-03-15)
+
+* Deprecate support for Ruby 2.2
+
+## dpl v2.0.2-beta.1 (2020-09-15)
+
+* Add AWS ECR support
+
+## dpl v2.0.1-beta.3 (unreleased)
+
+* Change git_push to use the GitHub token's user name and email as the
+  committer name and email
+
+## dpl v2.0.1-beta.2 (2020-01-27)
+
+* Change codedeploy, lambda, and pages to safelist variables available for
+  interpolation on user facing options
+
+## dpl v2.0.1-beta.1 (2020-01-27)
+
+* No changes
+
+## dpl v2.0.0-alpha.13 (2020-01-17)
+
+* Add s3 `--glob`
+
+## dpl v2.0.0-alpha.13 (2020-01-06)
+
+* Bump Cl which now raises on arguments undeclared by the command
+
+## dpl v2.0.0-alpha.12 (2020-01-06)
+
+* Add npm `--run_script`, allowing one or many scripts from package.json to be run
+* Add elasticbeanstalk `--wait_until_deployed_timeout`
+* Update pages to pass one -m option per commit message line
+* Fix releases to transliterate filenames in an attempt to mirror GitHub's behavior
+
+## dpl v2.0.0-alpha.11 (2019-10-14)
+
+* Fix pages: do not skip if new or only deleted files are present
+
+## dpl v2.0.0-alpha.6 - v2.0.0-alpha.10 (2019-10-09)
+
+* Add a Cloudformation provider
+* Add a Convox provider
+* Add a Gleis provider
+* Remove the Atlas provider (service retired)
+* Rescue `UnknownOption` and suggest known options on Ruby >= 2.4
+* Allow options to be given as env vars on all providers
+
+### Cargo
+
+* Add `--allow_dirty` to allow publishing from a dirty Git working directory
+
+### Cloudfoundry
+
+* Default `--api` to `https://api.run.pivotal.io`
+
+### Elasticbeanstalk
+
+* Hornor `.gitignore` if `.ebignore` is not present
+
+### GCS
+
+* Add `--key_file` to allow using a service account key file
+
+### NPM
+
+* Allow publishing to GitHub Package Registry
+* Add `--dry_run` to allow testing deployments
+
+### Pages
+
+* Do not commit or push unless the working dir is dirty on cloned repos
+
+### Releases
+
+* Make --file glob files by default, and default to `*`
+
+## dpl v2.0.0-alpha.2 (2019-08-28)
+
+* Add `--edge` as an internal flag in case `edge: true` was given in `.travis.yml`
+
+## dpl v2.0.0-alpha.1 (2019-08-27)
+
+* Default to not cleaning the git working directory, but accept `--cleanup` in order to clean up the git working directory.
+* Support a maturity model using dev, alpha, beta, stable.
+* Use Ruby's `DidYouMean` in order to suggest provider names if the given name is not valid.
+* Use `~/.dpl` rather than `./.dpl` as a directory to store assets, and remove `~/.dpl` before the process terminates.
+* Use the AWS SDK v3 for AWS providers.
+* Fix git-ssh to work with non-standard ssh ports (used by all providers that rely on Git).
+
+### bintray
+
+* List files in the downloads list if specified in the descriptor file.
+
+### chef-supermarket
+
+* Read the cookbook name a given metadata.json or metadata.rb file if not given as `--name`.
+* Use `--name` and `--category`, but keep `--cookbook_name` and `--cookbook_category` as deprecated aliases.
+
+### cloudfoundry
+
+* Accept `--v3` in order to use the `v3-push` command.
+
+### codedeploy
+
+* Accept `--file_exist_behavior` in order to specify how to handle files that already exist in a deployment target location.
+
+### elasticbeanstalk
+
+* Accept `--label` and `--description` in order to define these attributes.
+* Remove non-printable unicode chars from the version description.
+* Accept `--debug` in order to list files added to the zip archive.
+* Honor `.ebignore` in order to exclude files from being added to the zip file.
+
+### engineyard
+
+* Use `ey-core` as CLI tooling.
+
+### firebase
+
+* Accept `--only` in order to restrict the resources to deploy.
+* Accpet `--force` in order to delete functions missing from the current working directory.
+* Add `node_modules/.bin` to the `PATH` in case users have `firebase` in that directory.
+
+### gae
+
+* Accept multiple values on on `--config`.
+
+### hackage
+
+* Accept `--publish` in order to publish a package.
+
+### lambda
+
+* Accept `--layers` to deploy function layers.
+* Do not require a role and handler name when functions are only being updated.
+* Use the correct handler name separators for dotnet, go, and java runtimes.
+
+### npm
+
+* Accept `--registry` in order to specify the target registry.
+* Accept `--src` in order to specify a directory or tarball to publish.
+* Accept `auth` as an `--auth_method` in order to force writing the token to `_auth` in `~/.npmrc`.
+
+### pages
+
+* Accept a `--deploy_key` as an alternative to the GitHub token (expects a path to a file).
+* Accept a commit message on `--commit_message`, allow interpolating variables (e.g. as `$TRAVIS_BUILD_NUMBER`).
+* Check if the target branch already exists and preserves git history by default. `--no-keep_history` can be passed in order to erase history on the target branch.
+* Include symbolic links.
+* Add an alternative strategy for deploying via GitHub's pages HTTP API
+
+### pypi
+
+* Accept `--no-remove_build_dir` in order to skip removing the build dir (`./dist`).
+* Run `twine check dist/*` by default, and accept `--no-twine_check` for opting out.
+
+### releases
+
+* Accept a path to a file containing release notes on `--release_notes_file`.
+* Use `--release_notes` for passing the release notes content, keep `--body` as a deprecated alias.
+
+### s3
+
+* Accept `--no-overwrite` in order to not overwrite existing files.
+* Accept `--force_path_style` in order to use the bucket name on the path, rather than the subcomain
+* Print out dots instead of filenames by default, and accept `--verbose` for printing out all filenames uploaded.
+* Use `application/octet-stream` as a default content type if a content type cannot be determined.

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, other beliefs, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Being constructive and proportionate when criticizing
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at the following email address: conduct@travis-ci.org. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org

data/CONTRIBUTING.md

@@ -0,0 +1,392 @@
+# Contributing to Dpl
+
+## Table of Contents
+
+* [Resources](#resources)
+* [Navigating the Codebase](#navigating-the-codebase)
+* [Lifecycle of the Deployment Process](#lifecycle-of-the-deployment-process)
+* [Deployment Tooling](#deployment-tooling)
+* [Runtime Dependencies](#runtime-dependencies)
+* [Unit Tests](#unit-tests)
+* [Runtime Dependency Installation Tests](#runtime-dependency-installation-tests)
+* [Integration Tests](#integration-tests)
+* [Testing Dpl Branches or Forks on Travis CI](#testing-dpl-branches-or-forks-on-travis-ci)
+* [Code Conventions](#code-conventions)
+* [Naming Conventions](#naming-conventions)
+* [Updating the README](#updating-the-readme)
+
+Dpl is a central component in Travis CI, and has been around for a long time.
+
+This library always has been a community effort first. There probably is not a
+single person in the world who is very familiar with all deployment providers
+supported by Dpl.
+
+*Thank you all for this!*
+
+This document is for you if you are looking to contribute to dpl, be it by
+adding a new deployment provider, fixing a bug, or adding a new feature.
+
+Dpl has a [code of conduct](CODE_OF_CONDUCT.md), please follow it in all
+interactions with the project.
+
+Dpl is written in Ruby, and we assume that you familiarize yourself with our
+documentation as much as needed.
+
+## Resources
+
+Hopefully helpful resources are:
+
+* This [document](CONTRIBUTING.md)
+* The [dpl README](README.md)
+* The [dpl API docs](https://www.rubydoc.info/github/travis-ci/dpl) on rubydocs.info
+* The [cl README](https://github.com/svenfuchs/cl/blob/master/README.md)
+
+## Navigating the Codebase
+
+All provider specific classes live in [dpl/providers](lib/dpl/providers).
+These represent the CLI commands that are executed when the command line
+executable `dpl` is run with a given provider name as the first argument.
+
+Each provider is a subclass of `Dpl::Provider`, which is defined in
+[dpl/provider.rb](lib/dpl/provider.rb). The provider base class itself
+subclasses from `Cl::Cmd`, so it represents an executable sub command of the
+main command `dpl`.
+
+For instance, the command `dpl s3 --bucket bucket` instantiates and runs the
+provider class [S3](lib/dpl/providers/s3.rb).
+
+The class `Cl::Cmd` contributes the command line options parser, and its
+class level DSL. Please see the [cl README](https://github.com/svenfuchs/cl/blob/master/README.md)
+for this DSL, and the [S3 provider](/lib/dpl/provider/s3.rb)
+for an example how dpl uses it.
+
+The class `Dpl::Provider` adds, amongst other things, the order of stages
+(methods) that make up the deployment process:
+
+* `init`
+* `install`
+* `login`
+* `setup`
+* `validate`
+* `prepare`
+* `deploy`
+* `finish`
+
+Implementors of concrete provider classes may or may not choose to implement
+any of these instance methods according to their needs, and semantics of their
+tooling and service providers. Please refer to [Dpl::Provider](/lib/dpl/provider.rb)
+for details.
+
+The DSL that is used to declare features, dependencies, environment integration
+etc. on the concrete provider classes is defined in the module
+`Dpl::Provider::DSL`, in [dpl/provider/dsl](/lib/dpl/provider/dsl.rb).
+
+Also of interest is [Dpl::Ctx::Bash](/lib/dpl/ctx/bash.rb),
+the Bash execution context, that runs shell commands, installs dependencies
+etc. (while the `Test` context class is used for testing in order to keep your
+development machine clean and safe when you run tests locally).
+
+```
+lib
+└── dpl
+    ├── assets                # Stores larger shell scripts
+    ├── ctx
+    │   ├── bash.rb           # Bash execution context
+    │   └── test.rb           # Test execution context
+    ├── provider.rb           # Base class for all providers
+    ├── provider
+    │   ├── dsl.rb            # DSL for defining providers
+    │   └── example.rb        # Generating example commands for help output
+    └── providers
+        ├── anynines.rb       # Concrete providers
+        ├── atlas.rb
+        ├── azure_webapps.rb
+        ├── bintray.rb
+        ├── bitballoon.rb
+        └── ⋮
+```
+
+## Lifecycle of the Deployment Process
+
+When a provider class is instantiated and run it will go through a number
+of stages that make up the deployment process.
+
+These are documented in [dpl/provider.rb](/lib/dpl/provider.rb).
+If you are adding a new deployment provider please familiarize yourself with
+this lifecycle.
+
+Feel free to pick and interpret these stages according to the needs and
+semantics of the service provider you are adding. By no means do all of these
+stages have to be filled in or implmented. The `Provider` base class checks for
+these methods, and runs them, if present, so that implementors can choose
+semantically fitting names for their providers.
+
+## Deployment Tooling
+
+If you are adding a new deployment provider please choose the tooling you are
+going to use carefully.
+
+Dpl is a long lived library, and it has outlived many tools that once were
+supported, and no longer are. Thus tooling stability is a major concern for
+this project.
+
+Ideally use official CLI tooling supported by the company who's service
+provider you are about to add. Often, such CLI tools can be installed via
+standard package managers, or manually downloaded using `curl` and installed
+with a few simple Bash commands.
+
+Such CLI tooling is preferrable over Ruby gem runtime dependencies as they can
+be executed in a child process, and won't introduce any dependency resolution
+problems later on.
+
+If no such CLI is available, or it does not look well supported, and your
+provider implementation needs to talk to an external HTTP API then please consider
+using [Net::HTTP](https://ruby-doc.org/stdlib-2.6.3/libdoc/net/http/rdoc/Net/HTTP.html)
+from Ruby's standard library.
+
+If you absolutely have to rely on a runtime Ruby gem dependency, such as a
+provider client implementation, please only do so if the gem is supported by
+the respective company officially. We may choose to reject including runtime
+dependencies that do not look stable or widely supported.
+
+## Runtime Dependencies
+
+Runtime dependencies can be declared on the provider class using the
+[DSL](lib/dpl/provider/dsl.rb).
+
+In the case of APT, NPM, and Pip dependencies these will be installed via
+shell commands at the beginning of the deployment process.
+
+Ruby gem dependencies will be installed using Bundler's [inline API](https://github.com/bundler/bundler/blob/master/lib/bundler/inline.rb),
+at the beginning of the deployment process, so they are available in the same
+Ruby process from then on.
+
+## Unit Tests
+
+`Dpl` uses [RSpec](https://github.com/rspec) for tests. The specs reside in
+`spec`, and each provider class has a corresponding file
+`spec/dpl/providers/*_spec.rb` to hold tests.
+
+Provider tests should be implemented on an input/output acceptance level, as
+much as possible.
+
+They use a [Ctx::Test](blob/masterlib/dpl/ctx/test.rb) execution context in
+order to avoid running actual shell commands, or actually installing
+dependencies at test time. There are custom [RSpec matchers](spec/support/matchers)
+in place that help with making assertions against this execution context.
+
+If your provider has to talk to an external HTTP API then ideally use
+[Webmock](https://github.com/bblimke/webmock) to stub external requests. If by
+any means possible try to avoid mocking or stubbing Ruby client classes (this
+is not always possible, but should be considered).
+
+### Running Unit Tests Locally
+
+You can run the unit test suite locally as follows:
+
+```
+bundle install
+bundle exec rspec
+```
+
+In order to execute tests only for a certain provider you can run:
+
+```
+bundle exec rspec spec/dpl/providers/[provider]_spec.rb
+```
+
+In order to execute a single test or group of tests add a line number like so:
+
+```
+bundle exec rspec spec/dpl/providers/[provider]_spec.rb:25
+```
+
+These tests can be run safely on any development machine, anywhere.
+
+## Runtime Dependency Installation Tests
+
+We additionally run tests that exercise runtime dependency installation on
+Travis CI.
+
+These live in [.travis/test_install](.travis/test_install). It is not
+advisable to run these tests outside of an ephemeral VM or container that can
+be safely discarded, as they are going to leave various artifacts around.
+
+## Integration Tests
+
+In order to ensure proper integration with the service providers supported
+we also periodically run a test suite that exercises actual deployments to
+these providers.
+
+These tests live in [.travis/providers](/.travis/providers), and the are
+triggered using the script [trigger](/.travis/trigger).
+
+An integration test consists of:
+
+* A setup script that creates an application (or artifact) to deploy (or
+  upload).
+* A YAML config snippet that configures and triggers the deployment as part of
+  a build on Travis CI.
+* A test script that tests if the deployment was successful.
+
+For example:
+
+* [github-pages/prepare](/.travis/providers/github-pages/prepare)
+  creates a minimal Git repository that serves an `index.html` on GitHub Pages in a temporary directory.
+* [github-pages/travis.yml](/.travis/providers/github-pages/travis.yml)
+  configures the build to use Dpl 2.0 to deploy this repository to GitHub Pages.
+* [github-pages/test](/.travis/providers/github-pages/test)
+  tests if the deployment was successful.
+
+The tests can be run on Travis CI individually, or combined, by triggering a
+build via our API, using the script [.travis/trigger](/.travis/trigger).
+This takes a provider name as an argument, and requires a Travis CI API token.
+
+For example, this triggers a build that executes the GitHub Pages test on
+Travis CI:
+
+```
+.travis/trigger github-pages --token [token]
+```
+
+The token can also be set as an environment variable:
+
+```
+export TRAVIS_API_TOKEN=[token]
+.travis/trigger github-pages
+```
+
+The `trigger` script accepts multiple provider names as arguments. If no
+arguments are given then tests for all providers will be run.
+
+### Integration Test Configuration
+
+In the build config YAML snippet make sure to use the branch of your fork for the
+deployment tooling, and allow the deployment to run on your branch:
+
+```yaml
+deploy:
+  - provider: [name]
+    edge:
+      source: [your-login]/dpl
+      branch: [your-branch]
+    on:
+      branch: [your-branch]
+```
+
+Ideally use credentials for an isolated account on the service you are deploying to.
+This is generally good practice, and way you can hand things off to someone else.
+
+In order to get things working encrypt the credentials against your fork, and
+add them to the build config YAML snippet. If you are in the root directory
+of your fork then this command should do the trick:
+
+```
+travis encrypt password=[password]
+```
+
+If you do not have the `travis` CLI installed you can install it using:
+
+```
+gem install travis
+```
+
+When you add encrypted credentials to the build config YAML snippet also add a comment
+that allows others to identify the account used. E.g:
+
+```yaml
+deploy:
+  - provider: pages
+    github_token:
+      # personal access token with repo scope on the account [name]
+      secure: "[encrypted token]"
+```
+
+Open a pull request. In order for us to merge your test, and get it working on
+our repository you will need to re-encrypt the credentials against
+`travis-ci/dpl`, like so:
+
+```
+travis encrypt -r travis-ci/dpl password=[password]
+```
+
+Whatever minimal deployment you can get working is be a great contribution.
+Even if for some reason it proves hard to test the deployment in an automated
+fashion, but you have a successful deployment that can be verified manually,
+please still open a pull request, and talk to us. Any test is better than no
+test.
+
+## Testing Dpl Branches or Forks on Travis CI
+
+It is possible to test a new deployment provider or new functionality of dpl on
+Travis CI. In order to do so, add proper configuration on the `edge` key to
+your `.travis.yml` like so:
+
+```yaml
+deploy:
+  provider: [name]
+  edge:
+    source: [github-handle]/dpl
+    branch: [branch]
+  on:
+    branch: TEST_BRANCH # or all_branches: true
+  ⋮ # rest of your provider's configuration
+```
+
+This builds the `dpl` gem on the Travis CI build environment from your
+repository, on the given branch. Then it installs the gem built from this code
+base, and uses it to run your deployment.
+
+When submitting a pull request, please be sure to run at least one deployment
+with the new configuration, and provide a link to the build in your pull
+request.
+
+## Code Conventions
+
+Dpl does not follow any strict code styleguide.
+
+Please take a look around other providers, and try to follow a similar code
+style to what you find.
+
+Try to use the [DSL](/lib/dpl/provider/dsl.rb) as much
+as possible.  It keeps the code declarative and readable, so that people not
+familiar with Ruby or programming in general can still follow it, and make
+sense of it.
+
+If you find yourself trying to achieve something that should be, but is not
+supported by the DSL please [open an issue](https://github.com/travis-ci/dpl/issues/new)
+about it.
+
+If you are rather unfamiliar with Ruby, and have trouble following our code
+style then please submit your pull request anyway, or get in touch, so we can
+help.
+
+## Naming Conventions
+
+Dpl uses constant names following Ruby naming conventions. I.e. constant
+names use `CamelCase`, and they live in files named in `snake_case.rb`.
+
+If you pick such names for a new provider please try to follow these
+conventions.
+
+Real world service provider or company names do not always translate to such
+conventional Ruby names one-to-one. That is ok, they don't have to. These Ruby
+constant names are representations of real world service and company names in
+Ruby code.
+
+Other Ruby libraries often (not always) follow a similar thinking. E.g.
+even though Amazon Web Services brand name is `AWS` the module name
+they chose in their [aws-sdk](https://github.com/aws/aws-sdk-ruby) is
+`Aws`, not `AWS`.
+
+## Updating the README
+
+The [README](/README.md) is generated from a
+[template](/lib/dpl/assets/dpl/README.erb.md).
+
+In order to update the README please edit the template, and run:
+
+```
+gem install ffi-icu
+bin/readme > README.md
+```

data/Gemfile

@@ -0,0 +1,32 @@
+# frozen_string_literal: true
+
+$LOAD_PATH << 'lib'
+require 'dpl/support/gems'
+
+source 'https://rubygems.org'
+ruby '>= 3'
+
+gemspec name: 'travis_dpl_test'
+gem 'cl', git: 'https://github.com/zgid123/cl'
+gem 'packagecloud-ruby', git: 'https://github.com/flywirecorp/packagecloud-ruby'
+# gem 'json_pure', '~> 2.6'
+
+# gem 'regstry', path: '../../registry'
+
+gems = Dpl::Support::Gems.new('lib/dpl/providers/**/*.rb')
+gems.each do |name, version, opts|
+  gem name, version, opts
+end
+
+group :test do
+  gem 'coveralls'
+  gem 'rspec'
+  gem 'webmock'
+end
+
+group :development, :test do
+  gem 'rubocop'
+  gem 'rubocop-performance'
+  gem 'rubocop-rspec'
+  gem 'simplecov-console'
+end