Write feature Files for Node view: project_release_download_table

Attached is the patch for this feature. Request to review and share your thoughts.

It seems my patch submission is missing along with the comment!

Resubmitting the patch.

@ksbalajisundar Comment #2 which contained your original patch was 'unpublished', so I re-published it and it shows up now.

I believe that this can be worked on now. It needs review for tabbed out table endings and other convensions we've agreed on since you took this on originally.

tagging

Committed the feature to repo and can be seen here - http://drupalcode.org/project/doobie.git/commit/1d71eba

New releases come out fairly frequently so I'm concerned about looking at the specific version numbers

I'm also wondering if we're testing the right thing here, but since I'm not sure how it would go astray (files missing, files not matching their label, wrong contents, etc.) I'm not quite sure how it should be adjusted.

I think I'll leave this one for feedback from sdboyer.

sorry for the delay.

testing for dev version strings is a little hinky, but ok. testing for point release strings is definitely not cool.

my ideal approach to this would be that we test the presence of specific versions that we create, but there's a LOT that goes into that. so we can punt on that, probably for quite a while.

a better, but more attainable approach here would be to test that there are releases that conform to the expected patterns, rather than testing for any specific numbers. it may be a little tricky to combine a multiline arg with pattern matching, but i'm sure y'all can figure it out :)

Lets discuss this on our call today

Currently we can write tests as below:

Given I am on "/project/drupal"
When I follow "6.x" "development" version
Then .......

Given I am on "/project/drupal"
When I follow "7.x" "recommended" version
Then .......

Given I am on "/project/drupal"
When I follow "Notes" for "7.x" "development" version
Then .......

Given I am on "/project/drupal"
When I download the "tar" file of "7.x" "recommended" version
Then the downloaded file name should match pattern "drupal-7.x"

Let's have sdboyer take a look at whether this is what he meant.

Added a wip tag to the first scenario as the contents of the page has changed and the language needs to be updated.

 Scenario: View the list of available releases       # features/project/project_release_download_table.feature:6
    Given that I am on the homepage                   # FeatureContext::thatIAmOnTheHomepage()
    When I follow "Get Started with Drupal"           # FeatureContext::clickLink()
    And I follow "Download Drupal 7."                 # FeatureContext::clickLink()
      Link with id|title|alt|text "Download Drupal 7." not found.
    Then I should see the heading "Download & Extend" # FeatureContext::iShouldSeeTheHeading()
    And I should see the following <texts>            # FeatureContext::iShouldSeeTheFollowingTexts()
      | texts                |
      | Downloads            |
      | Recommended releases |

needs work here

Sorry, this should have been tagged as @known_git6failure.

This works fine on d.o. The tag is made and committed - http://drupalcode.org/project/doobie.git/commit/760c650

But, still needs review by sdboyer related to #12

Setting version and still needs sdboyer's input here.

Need 7.x update

Feature updated in 7.x branch - http://drupalcode.org/project/doobie.git/commit/2d40f9f

Any idea if they're going to stop calling the files tar.gz as is being done on production now and start calling them gz, as we're seeing on git7?

This test is failing appropriately right now - test will need updating if this change is okay.

Fixing the filename output is currently blocked on #1791970: Optionally detect tar.* as extension instead of * on views file extension field handler

Thanks dww. We can mark this test rtbc, then. It's as done as it will get until D7 Drupal.org is ready for feedback.

Updated response headers for D7 and verified.