After creating a sandbox and promoting it, the message should say:

New URL

Now that this experimental project has been promoted, you'll need to update the URL of your remote repository or reclone it.
git remote set-url origin git-vetted@git.drupal.org:project/[project short name].git

Instead, it's using the sandbox number:
git remote set-url origin git-vetted@git.drupal.org:project/[sandboxnumber].git

Comments

helmo’s picture

helmo commented

That would be the @auth_project_url variable in $defaults
Which gets data from @project_name. Which in trun gets it from:

  if (is_object($node->versioncontrol_project['repo'])) {
    $repo_name = $node->versioncontrol_project['repo']->name;
  }
  else {
    // Fallback, just after creation the repo object above might not be available.
    $repo_name = $node->field_project_machine_name[$node->language][0]['value'];
  }
  $project_url_name = check_plain(drupal_encode_path($repo_name . '.git'));

So I'm guessing that $node->versioncontrol_project['repo']->name still has the sandbox number.

eliza411’s picture

eliza411 commented

I verified that this is working as expected on git7site.devdrupal.org, but not on production - I may just be much too tired, but I don't seem to have access to the value in the short_name field to fix this in the database.

eliza411’s picture

eliza411 commented

I've updated the URL in the database for now so it's not just wrong with the following:

Don't forget to substitute your project's new short name in the brackets below (and remove the brackets!)

git remote set-url origin @git_username@git.drupal.org:project/[project_short_name_here].git

Once it's straightened out, that'll need to be set back to:

git remote set-url origin @auth_project_url

tvn’s picture

tvn commented
Issue tags: +Drupal.org 7.1
helmo’s picture

helmo commented
Assigned: Unassigned » eliza411

This is not actionable for me ...
@eliza411 please triage this when you have some time...

eliza411’s picture

eliza411 commented
Assigned: eliza411 » marvil07

Sorry I didn't update this. I pinged marvil07 in IRC to see if it's something he could help with. I'm not sure he ever saw that ping, though.

@marvil07, is this something you can lend a hand with? I've put a work-around in place, but I'd like to get this issue in the right queue so it can get addressed eventually.

marvil07’s picture

marvil07 commented
Assigned: marvil07 » eliza411

I verified that this is working as expected on git7site.devdrupal.org, but not on production - I may just be much too tired, but I don't seem to have access to the value in the short_name field to fix this in the database.

That sounds strange, any difference between the project_git_instructions_project_promoted variable in production and git7site?

@helmo: Thanks for the pointer!

@eliza411: I have been reviewing the code around sandbox promotion, following a summary.

The place where the repository object rename is happening is on the hook_project_promote_sandbox() implementation by drupalorg_versioncontrol module, which is not directly changing the value, but scheduling the required operations(i.e. real git directory rename) to perform on that event.
That hook is changing the repository object, so AFAIK it should be changed, unless project_git_instructions implementation of hook_project_promote_sandbox() is called before.

@eliza411: can you please retrieve module weights of these modules in both production and git7site? here the untested query: select name, weight from system where name in ('project_git_instructions', 'drupalorg_versioncontrol').

eliza411’s picture

eliza411 commented

When I did the comparison between git7 and prod, git7 had not yet been updated with a copy of the database from production. The database is now a dump from prod, and the problem is repeatable on git7site as well.

After promoting the project:
auth_project_url - ssh://admintest@git7.devdrupal.org:2020/project/2156596.git
project_name - 2156596.git

Then, when I click the Version control tab, I see:
auth_project_url - ssh://admintest@git7.devdrupal.org:2020/project/purple_ponies.git
project_name - purple_ponies.git

I can hunt down the module weight tomorrow if you think it's relevant, but we won't have a working value to compare it with.

eliza411’s picture

eliza411 commented

Here are the weights from git7site, which, like I said, is now behaving the same as production:

+--------------------------+--------+
| name                     | weight |
+--------------------------+--------+
| project_git_instructions |      0 | 
| drupalorg_versioncontrol |     15 | 
+--------------------------+--------+
marvil07’s picture

marvil07 commented

@eliza411, that can explain the problem: both modules are implementing hook_project_promote_sandbox(), project_git_instructions is executing first. drupalorg_versioncontrol implementation is the one changing the repository name.

Not sure if we need to have different weights for other hooks, but changing the weight to make project_git_instructions execute after project_git_instructions should solve the problem.

A quick test could be achieved doing(again untested): update system set weight = 16 where name = 'project_git_instructions', then trying a promotion.

Self note: Why are we dealing with repository renaming in drupal_versioncontrol instead of versioncontrol_project?

helmo’s picture

helmo commented

@marvil07: sounds like a practical solution. Or is there something like a hook_project_post_promote_sandbox()

eliza411’s picture

eliza411 commented

@marvil07: Changing the weights did make a difference:

+--------------------------+--------+
| name                     | weight |
+--------------------------+--------+
| drupalorg_versioncontrol |     15 | 
| project_git_instructions |     16 | 
+--------------------------+--------+

Output:

auth_project_url - ssh://admintest@git7.devdrupal.org:2020/project/yellow_yaks.git
project_name - yellow_yaks.git

helmo’s picture

helmo commented

Great, can you apply this on the live site? Or do we need the needs deployment tag?

drumm’s picture

drumm
he/him
Location NY, US
commented
Status: Active » Fixed

Done on production.

If this sort of issue comes up again - a small query needs to be run on production, the ideal thing to do is write an update function in drupalorg. Or at least put the query in the issue summary and mark needs review.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.