Task #4784: Create a tool for generating Travis config for plugins - Pulp

Actions

Send by e-mail Copy link

Task #4784

closed

Create a tool for generating Travis config for plugins

Added by dkliban@redhat.com almost 5 years ago. Updated almost 4 years ago.

Status:

CLOSED - CURRENTRELEASE

Priority:

Normal

Assignee:

dkliban@redhat.com

Category:

Sprint/Milestone:

3.0.0

Start date:

Due date:

% Done:

100%

Estimated time:

Platform Release:

Groomed:

Sprint Candidate:

Tags:

Plugin Template

Sprint:

Quarter:

Description

The plugin_template bootstrap script generates some Travis configs for the plugin. However, over time we have found that these configs change and require the plugin writer to manually update. As a result of this task, the plugin writer will have a script that is called generate_plugin_travis_config. It will take the following arguments:

plugin app_label (string) - the label used to find plugin repo directory and in template substitution
test_docs (boolean) - if true, Travis will test running 'make html' in the docs directory
deploy_to_pypi (boolean) - if yes, Travis will deploy to PyPI when a tag is pushed
deploy_client_to_pypi (boolean) - if yes, Travis will deploy the Python client library to PyPI when a tag is pushed
deploy_client_to_rubygems (boolean). - if yes, Travis will deploy the Ruby client library to rubygems.org

The plugin writer will still need to provide the credentials for PyPI and Rubygems.org, but the rest will be handled by this script.

Related issues

Actions

Copy link

Updated by dkliban@redhat.com almost 5 years ago

Description updated (diff)

Actions

Copy link

Updated by amacdona@redhat.com almost 5 years ago

+1, this will be helpful. Since has a lot more arguments, it probably makes sense to uses jinja or something instead of python string substitution.

Actions

Copy link

Updated by bmbouter almost 5 years ago

+1 we should do this. The bindings are hugely valuable, but the cost of adding each of these features to each repo is too high. This tool will bring that back into something we can afford to do for all bindings for all plugins!

Actions

Copy link

Updated by dkliban@redhat.com almost 5 years ago

Status changed from NEW to ASSIGNED
Assignee set to dkliban@redhat.com

Actions

Copy link

Updated by dkliban@redhat.com almost 5 years ago

What about adding even more options:

test_mariadb
test_python_client

Actions

Copy link

Updated by bmbouter almost 5 years ago

dkliban@redhat.com wrote:

What about adding even more options:

test_mariadb
test_python_client

??

The test_mariadb definitly makes sense, and I think should be True by default. Also the test_docs (already in the ticket) should default to true also. Basically all the testing should default to true.

test_python_client I could take or leave at the moment. I do think we'll have it one way or another over time. So I would say +0 to that.

Also to confirm, this will use the Ansible installer to handle all the installation right? If so, we can find all those "switch plugin X to Travis" and use those when we apply the tooling.

Actions

Copy link

Updated by dkliban@redhat.com almost 5 years ago

Also to confirm, this will use the Ansible installer to handle all the installation right? If so, we can find all those "switch plugin X to Travis" and use those when we apply the tooling.

Yes, it will use ansible-pulp to deploy the pulpcore with the plugin.

Actions

Copy link