| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7627: Add new option to `bundle gem` for choosing a CI sevice r=colby-swandale a=colby-swandale
### Context
At the moment, every gem created with `bundle gem` will have configuration generated for Travis CI regardless of if you want to or not. When this change was introduced, Travis CI was a clear recommendation for most open source projects to use for testing their projects with. But this is no longer true, there are now lots of different CI services and Travis CI is no longer the clear recommendation it once was.
### Changes
This PR introduces a new option to `bundle gem` for choosing a CI service or just not generating one at all.
```
Creating gem 'test'...
Do you want to add Continuous Integration to your gem? Adding a CI service to your project helps ensure your project is well tested before shipping your gem to users. Bundler recommends several different services for testing your code. For more information about each service, see:
* Travis CI: https://travis-ci.org/
* Github Actions: https://github.com/features/actions
* Circle CI: https://circleci.com/
* Gitlab CI: https://docs.gitlab.com/ee/ci/
Type 'github', 'travis', 'gitlab' or 'circle' to generate those test files now and in the future. github/travis/gitlab/circle/(none):
```
I decided to add Github Actions, Gitlab, Circle CI along with Travis CI, which i think covers most services most people will typically go with.
Each service will generate it's own configuration which is ready to use out the box.
Co-authored-by: Colby Swandale <me@colby.fyi>
Co-authored-by: Andre Arko <andre@arko.net>
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7660: Try to migrate GitHub Actions from Travis CI r=hsbt a=hsbt
Fixes #7587
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This reverts commit 63917c1c9db60b87e14ffb3a8a162e4f58dc4276.
|
| | | |
|
| | |
| | |
| | | |
Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Without shelling out. It should be faster, and it avoids a ruby 2.3
issue where gems installed through a subprocess are not picked up by the
currently running rubygems.
I'm also removing some unneeded `travis_retry` from the TravisCI
configure. These steps shouldn't timeout and if they do, we should
figure out why. Also, they could be hiding other issues not related to
the network. In this case, `travis_retry bin/rake spec:parallel_deps`
was hiding the issue installing dev dependencies being fixed by this
commit.
|
| | | |
|
| | |
| | |
| | |
| | | |
This reverts commit a39e100be885f72a261a4c78032655d13502e44e.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
This reverts commit f018c6dd687b33c71b5ddb42c5e437704e73bd15.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | | |
Co-Authored-By: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7665: Fix sudo specs environment r=hsbt a=deivid-rodriguez
### What was the end-user or developer problem that led to this PR?
The developer problem is that sudo specs are not correctly setting the environment (except for ruby 2.3). The specs are accidentally passing but you can tell that they are running against the system ruby by the [warning messages they print](https://travis-ci.org/rubygems/bundler/jobs/658272719#L531-L558).
This causes problems when migrating to github actions. See https://github.com/rubygems/bundler/pull/7660#discussion_r385616844.
Another problem is that the environment is setup manually outside of `rake spec:sudo`, so there's no easy way of running sudo specs manually if your system does not have the right sudoers configuration.
### What is your fix for the problem, implemented in this PR?
My fix is to properly set sudo configuration to preserve the environment so that the correct ruby can be found by sudo specs, and also to move the logic inside `rake spec:sudo` so that the specs can easily be run manually without side effects.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|