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
Fixes #24569 - Expose minor/major cvv version in API. #7594
Conversation
@@ -79,9 +79,13 @@ def update | |||
param :description, String, :desc => N_("Description for the new published content view version") | |||
param :force_yum_metadata_regeneration, :bool, :desc => N_("Force yum metadata regeneration on the repositories " \ | |||
"in the content view version") | |||
param :major, :number, :desc => N_("Override the major version number provided by Katello"), :required => false | |||
param :minor, :number, :desc => N_("Override the minor version number provided by Katello"), :required => false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could drop the provided by
in the description
@@ -9,7 +9,11 @@ class Publish < Actions::EntryAction | |||
def plan(content_view, description = "", options = {}) | |||
action_subject(content_view) | |||
content_view.check_ready_to_publish! | |||
version = content_view.create_new_version | |||
if options[:minor] && options[:major] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may need to add some validation at the model level to ensure these are both integer values now that we are allowing customization of them. The major field is an integer in the database but minor is defined as a string which would allow anything. I checked buy didn't see any explicit validations for these fields. Can double check with @beav or @jlsherrill in case I missed them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably do need to check that they are numeric and that no existing CVV exists with those versions. In fact it doesn't even look like there is a unique index on those versions, so that needs to be added to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 to numeric check, I was able to set "five" as the minor string and it resulted in a successful task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@beav Added a check to the model to make sure :minor
is an integer.
class AddIndexToContentViewVersion < ActiveRecord::Migration[5.1] | ||
def change | ||
add_index :katello_content_view_versions, :major | ||
add_index :katello_content_view_versions, :minor |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this index, we need it to be unique across 3 columns, content_view_id, major, and minor. It'd look something like this:
add_index :katello_content_view_versions, [:content_view_id, :major, :minor], :unique => true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to add a uniquness validation to the model as well, something like:
validates :minor :uniqueness => {:scope => [:content_view_id, :major]}
@chris1984 looks like there is still a test failure |
@@ -44,6 +44,8 @@ class ContentViewVersion < Katello::Model | |||
|
|||
validates_lengths_from_database | |||
|
|||
validates :minor, :uniqueness => {:scope => [:content_view_id, :major], :message => N_("Major, and content_view_id trio must be unique")} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This message auto-assumes that it will start with the word "minor" since that's the key its validating. The message should be something like ", major, and content_view_id trio must be unique"
for it to print properly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in they must all three be unique or unique within the scope of each other? Wondering if we can find a word or two that encompasses that for clarity. Trio makes me think I am ordering an appetizer, which makes me hungry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this turned out to be a fixture issue, we are fixing now.
here's an appetizer trio though 🍣 🥘 🍗
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍔
end | ||
|
||
version = library_view.versions.first | ||
version = library_view.versions.find_by(:major => 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jlsherrill @ehelms we weren't sure on this one. In tests, it looks like CVV version 1.0 of the DOV is already created, which makes this create!
fail. We aren't sure if the CVVs on the DOV are actually used anywhere or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel a bit dumb asking this, what does DOV stand for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default organization view, it is the content view that is just Library
version = content_view.create_new_version | ||
if options[:minor] && options[:major] | ||
version = content_view.create_new_version(options[:major], options[:minor]) | ||
increment!(:next_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this needed? I get
2018-08-15T15:08:14 [E|bac|926a6] undefined method `increment!' for #<Actions::Katello::ContentView::Publish:0x00007f2a6ea06c58> (NoMethodError)
/opt/theforeman/tfm/root/usr/share/gems/gems/katello-3.7.0/app/lib/actions/katello/content_view/publish.rb:14:in `plan'
/opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.0.5/lib/dynflow/action.rb:493:in `block (3 levels) in execute_plan'
/opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.0.5/lib/dynflow/middleware/stack.rb:26:in `pass'
/opt/theforeman/tfm/root/usr/share/gems/gems/dynflow-1.0.5/lib/dynflow/middleware.rb:18:in `pass'
when calling the api like this:
http --verify=no -a admin:changeme -b POST https://hostname/katello/api/v2/content_views/3/publish major=10 minor=5
@chris1984 looks good, will retest tomorrow |
The following sequence failed:
It's OK that this failed, but there's no way to make publish work again without setting the major/minor. It looks like the autoincrement needs to bump to whatever major+1 is after publishing with major/minor set |
app/models/katello/content_view.rb
Outdated
@@ -494,7 +494,7 @@ def create_new_version(major = next_version, minor = 0, components = self.compon | |||
:components => components | |||
) | |||
|
|||
increment!(:next_version) if minor == 0 | |||
next_version = major + 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not able to publish after this change:
no implicit conversion of Integer into String (TypeError)
| /home/vagrant/katello/app/models/katello/content_view.rb:497:in `+'
| /home/vagrant/katello/app/models/katello/content_view.rb:497:in `create_new_version'
| /home/vagrant/katello/app/lib/actions/katello/content_view/publish.rb:13:in `plan'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems to help:
self.next_version = major.to_i + 1
However I'm not sure how to get the change to persist. The old increment!
method would auto-save, and I'm not sure where the correct place to do the save is now. We can look at it more tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the old version saved here, i would just do that here too.
update_attributes(:next_version = major.to_i + 1)
But i think there are some conditions that are missed here:
- what if the major version being passed in is older than the current 'next_version'
- for incremental update, you wouldn't want to increment the major if only the minor version is being updated (although maybe it doesn't matter if you handle 1)
@@ -85,6 +86,14 @@ def test_create | |||
assert_template 'katello/api/v2/common/create' | |||
end | |||
|
|||
def test_create_with_version_params | |||
post :create, params: { :name => "My View", :label => "My_View", :major => 2, :minor => 1, :description => "Cool", :organization_id => @organization.id } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be publish
not create, can you also verify that the version with those major and minor versions exist after?
here's a similar test
katello/test/controllers/api/v2/content_views_controller_test.rb
Lines 255 to 261 in 0095469
def test_publish_default_view | |
view = ContentView.find(katello_content_views(:acme_default).id) | |
version_count = view.versions.count | |
post :publish, params: { :id => view.id } | |
assert_response 400 | |
assert_equal version_count, view.versions.reload.count | |
end |
Bonus points if you can make use of @publish_permission
;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the right approach for a controller test which goes to one or more backend services is simply to test that the action is invoked properly. Testing that the major & minor versions exist is the responsibility of a different test (in my opinion!).
🇬🇱 🍏 🥗 |
The changes look good to me, but I worked with a preliminary version of this patch a lot and might not be a good reviewer for final ACK since I'm already familiar with it. Can someone else provide final ack? |
Thanks @chris1984 |
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json { "repos": [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] } ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json { "repos": [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] } ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json { "repos": [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] } ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json { "repos": [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] } ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json { "repos": [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] } ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "Red_Hat_Satellite_Tools_6_3_for_RHEL_7_Server_RPMs_x86_64", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "Red_Hat_Satellite_Tools_6_3_for_RHEL_7_Server_RPMs_x86_64", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "repo_label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "repo_label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with Katello#7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
Previously, the only way to control which packages land in content view version was by using filters, or by managing the contents of the Library versions of the repos. This commit lets you optionally specify the exact package set you want in your repository. It will look at the Library version of each repo, and copy the list of packages into the CV version. Example value for `repos_units` when calling `/katello/api/v2/content_views/2/publish`: ```json [ { "label": "zoo", "rpm_filenames": [ "walrus-5.21-1.noarch.rpm", "gorilla-0.62-1.noarch.rpm" ] }, { "label": "a_longer_label", "rpm_filenames": [ "facter-2.4.6-3.el7sat.x86_64.rpm", "pulp-rpm-handlers-2.13.4.9-1.el7sat.noarch.rpm" ] } ] ``` This works the same for custom and RH repos. When used with #7594, you can set the CV version number as well as the list of packages in each repo. This is useful for cloning a CV version from one Katello to another.
No description provided.