After a project has been promoted, verify

site user can anonymously clone using the project short name
owner can push after following directions to remotes

site user and owner can NOT clone using the former sandbox url (which can be calculated based on git user name and node id)

Comments

eliza411’s picture

Some clarification:
anonymous:

  • git vetted creates a sandbox in the given
  • git vetted promotes the sandbox in the given
  • anonymous scenario: clone the full project repo

project owner:

  • create a sandbox in the given
  • promote the sandbox in the given
  • follow directions on the Version control tab to update your remote
  • push to the repo
pradeeprkara’s picture

Assigned: Unassigned » pradeeprkara
Issue tags: +sprint 6

tagging

pradeeprkara’s picture

Observed a behavior :

When I clone a sandbox repo as user:

i.e.
git clone --recursive --branch master ssh://gitvetteduser@git6.devdrupal.org:2020/sandbox/gitvetteduser/1723603.git 4sjvt9mhjseq5eqj_dir1

It is asking to enter gitvetteduse password and when entered , cloning is happening (This is fine)

But when an anonymous user tries to clone the same repo:

i.e.
git clone --recursive --branch master ssh://git6.devdrupal.org:2020/sandbox/gitvetteduser/1723603.git 4sjvt9mhjseq5eqj_dir2

it is again again asking the system user password at git6.devdrupal.org. If I am logged in as root user, it will ask to enter root@git6.devdrupal.org password and when I just hit enter it will start cloning.

Is this normal?

eliza411’s picture

Status: Active » Needs work

I think this is normal behavior. @sdboyer can weigh in, but you should probably continue as if it's okay.

What's happening is that all repositories are public and can be cloned by anyone, even if the authentication fails.

If you view the project page logged out, you'll see what an anonymous user sees and shouldn't experience the password prompt on clone.

pradeeprkara’s picture

Issue tags: +sprint 7

tagging

pradeeprkara’s picture

Status: Needs work » Needs review

As drupal.org and git6site.devdrupal.org have different patterns for git end points, sandbox git urls have been generated based on the below example urls:

git6site.devdrupal.org:
user logged in:
git clone --recursive --branch master ssh://username@git6.devdrupal.org:2020/sandbox/username/project_short_code.git

Anonymous:
git clone --recursive --branch master ssh://git6.devdrupal.org:2020/sandbox/username/project_short_code.git

drupal.org:
When user logged in:
git clone --recursive --branch master username@git.drupal.org:sandbox/username/project_short_code.git
Anonymous:
git clone --recursive --branch master http://git.drupal.org/sandbox/username/project_short_code.git

Please review the commit.

2a455dc

Some updates: 648d801

Also merged #1706946: Edit project node (promoted) - (promoted_projects.feature) here

pradeeprkara’s picture

Title: Promoted Projects you don't maintain/own » Promoted Projects you don't maintain/own (promoted_projects.feature)
eliza411’s picture

Status: Needs review » Needs work

I made some changes to the feature language in http://drupalcode.org/project/doobie.git/commit/b528aac

I also have a couple of questions:

  Scenario: Clone the sandbox repository as project owner
    Given I am logged in as "git vetted user"
    Then I should not be able to clone the sandbox repo

Is there a reason for skipping the When statement here? I think breaking it into the two conventional steps will make where failure is occurring much easier to see:

  1. The action the user performs (When I clone the repo)
  2. The expected outcome (Then I should see something indicating I've failed)
  Scenario: Clone the sandbox repository as anonymous user
    Given I am on the homepage
    Then I should not be able to clone the sandbox repo

I'm not sure based on what I see that this tests what's intended (although I think it does). I expect to see something more user-visible, like:

Given I'm not logged in
When I clone the repo
Then is should see "some sort of access denied" 
pradeeprkara’s picture

Issue tags: +sprint 8

tagging

pradeeprkara’s picture

Status: Needs work » Needs review

The When step was skipped because of the unavailability of old sandbox git endpoints in the current Version control tab.

Separated the action and outcome as suggested.

Please review the feature: 0902136

PS: As there are some issues reported after the latest upgrade:#1784356: Unable to initialize the repository, you might get some failed scenarios until it is resolved.

eliza411’s picture

Component: Feature/Scenarios » Step definitions

This is, as you point out, waiting on #1784356: Unable to initialize the repository - I marked the scenarios @wip and am moving this forward to code review on the hope that jhedstrom or someone can help with them.

pradeeprkara’s picture

Issue tags: +sprint 9

step definitions have been modified to support anonymous user cloning. The password will be passed as "" in this case.

Also the error which anonymous user will get while cloning an old sandbox repo has been modified as "remote HEAD refers to nonexistent ref, unable to checkout"

Please review the commit: 2820a19

eliza411’s picture

Status: Needs review » Needs work

Added a wip tag to the final scenario as the I clone the sandbox repo step is failing.

  Scenario: Clone the sandbox repository as anonymous user                                  # features/project/promoted_projects.feature:37
    Given I am not logged in                                                                # FeatureContext::iAmAnAnonymousUser()
    When I clone the sandbox repo                                                           # FeatureContext::iCloneTheSandboxRepo()
      Sandbox git end point is empty
    Then I should see the error "remote HEAD refers to nonexistent ref, unable to checkout" # FeatureContext::iShouldSeeTheError()
pradeeprkara’s picture

Status: Needs work » Needs review
Issue tags: +sprint 10

I clone the sandbox repo works for me and I'm not sure why it failed for you. can you run once again and see?

Removed @wip tag and updated the feature context with "Expect" library status check(mostly for windows)

The changes are at: 76e8217

eliza411’s picture

Status: Needs review » Needs work
Issue tags: -sprint 6, -sprint 7, -sprint 8, -sprint 9, -sprint 10

This still fails on ubuntu with expect library set up:

 @clean_data
  Scenario: Clone the sandbox repository as anonymous user                                                           # features/git/promoted_projects.feature:37
    Given I am not logged in                                                                                         # FeatureContext::iAmAnAnonymousUser()
    When I clone the sandbox repo                                                                                    # FeatureContext::iCloneTheSandboxRepo()
    Then I should see the error "remote HEAD refers to nonexistent ref, unable to checkout"                          # FeatureContext::iShouldSeeTheError()
      The error:"remote HEAD refers to nonexistent ref, unable to checkout" is not happening
pradeeprkara’s picture

Status: Needs work » Needs review

Tested the feature from an Ubuntu OS and found that GIT returns different error string in the mentioned scenario; not sure it is because of the difference in the installed version of GIT. So I think , hard coding the expected string should be avoided.
Created a new custom step: I should see an error

Please review and rerun the test. The commit: bcd5227, fa622af

eliza411’s picture

Status: Needs review » Needs work

I'm getting:

  @clean_data @wip
  Scenario: Clone the sandbox repository as anonymous user                                                           # features/git/promoted_projects.feature:37
    Given I am not logged in                                                                                         # FeatureContext::iAmAnAnonymousUser()
    When I clone the sandbox repo                                                                                    # FeatureContext::iCloneTheSandboxRepo()
    Then I should see the error "remote HEAD refers to nonexistent ref, unable to checkout"                          # FeatureContext::iShouldSeeTheError()
      The error:"remote HEAD refers to nonexistent ref, unable to checkout" is not happening

I've still merged this to master with the wip tag

pradeeprkara’s picture

Status: Needs work » Needs review

It seems like you still have the previous version. I had replaced that step with a new one. You can it in my previous commit: http://drupalcode.org/project/doobie.git/commit/bcd5227

eliza411’s picture

Status: Needs review » Reviewed & tested by the community

I must have run this from master ... Will honestly be glad to have that gone! Looks good. I've removed the @wip tag, so it's ready for inclusion in the full-suite.

pradeeprkara’s picture

Version: » 6.x-1.x-dev
Issue tags: +sprint 10

this was left to tag

kssundar’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Component: Step definitions » Feature/Scenarios
Assigned: pradeeprkara » kssundar
Priority: Major » Normal
Status: Reviewed & tested by the community » Patch (to be ported)
Issue tags: +sprint 18

Need 7.x update

kssundar’s picture

kssundar’s picture

Status: Patch (to be ported) » Needs review

review later

eliza411’s picture

Status: Needs review » Reviewed & tested by the community

I removed the @wip tag so this test will be included in full runs. It's as ready as it can be until the D7 Drupal.org is ready for feedback.

http://drupalcode.org/project/doobie.git/commit/44de740

eliza411’s picture

Component: Feature/Scenarios » Test needs update
Status: Reviewed & tested by the community » Needs work
Issue tags: +qa, +drupal.org D7

The project shortname is getting lost between creation in the first scenario and the post promotion check.

eliza411’s picture

Issue tags: -drupal.org D7

removing tag