Migrating security issues to git.drupalcode.org will happen via passing through a www.drupal.org drush command which reads a json file with all security issue data. It will be done this way since www.drupal.org has the mapping to GitLab accounts, and shared migration code, like formatting Drupal HTML-ish formatted text as something that GitLab-Flavored-Markdown renders okay. This issue is for creating the JSON export.

What won’t be exported:

  • Component - projects’ components on security.drupal.org are generally not maintained
  • Credit reporters & fixed - GitLab will not contain these directly, they will be on draft security advisories which remain in Drupal
  • Parent & related issues - These could be migrated, although will require another step in updating & mapping. 61 issues have a parent, and there are 294 relations. They have not been used too extensively on security.drupal.org as access control limits what people can see
  • Security advisory drafts - there should not be many drafts for unreleased issues. We can manually copy them over after migration

Issue fork securitydrupalorg-3565761

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

drumm created an issue. See original summary.

drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes
greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Plan sounds good to me so far. Thanks for thinking this through and sharing your plans.

drumm opened merge request !20

drumm’s picture

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

This command is complete as far as I know now. I fully expect there to be future iterations, as I find more with the import.

The main thing that is reviewable here is the mapping to GitLab labels. The rest is relatively straightforward iterating over everything.

It will be invoked like:

drush -v migrate-issue-data --user=1 > sdo-issues.json

User 1 is needed for loading some nodechanges data. The export on private dev is 53M, which includes everything except filenames of uploads; files are not copied to dev.

drumm’s picture

drumm
he/him
Location NY, US
commented
Parent issue: » #3487828: Support confidential issues in git.drupalcode.org for security team triage

  • drumm committed a0a7570f on 7.x-1.x 
    feat: #3565761 Add a drush command to export data to migrate issues to...
drumm’s picture

drumm
he/him
Location NY, US
commented

I am deploying what I have so far, so I can start testing the linting phase with production data. There are a couple things that are harder to get in a dev environment:

  • Drupal.org user IDs - Probably could flip the bakery mode in dev, not allowing login, but should export
  • Attached file paths - we don’t have the files synced to dev, I think the file-related functions must check that the file exists

I still expect followups, although I’ll lean toward any data cleanups on the import side. For example, the import fixes the project of a larger handful of issues that are in projects only on security.drupal.org, such as issues for the security.drupal.org website go to securitydrupalorg module.

drumm opened merge request !23

  • drumm committed 0ab12c6c on 7.x-1.x 
    fix: #3565761 Add closed at timestamp & title
drumm’s picture

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

I’m going to call this fixed since the import side is working well.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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