Skip to main content

GitHub / Source Reconstruction Reference

GitHub / Source Reconstruction Reference

GitHub / Source Reconstruction Reference

Purpose: Define the off-host, version-controlled representation of Skyhawk.org application architecture. GitHub supports reconstruction, rollback, migration and disaster recovery. It does not replace normal database/files backups.

Current State

  • GitHub organization: Skyhawk-Association.
  • Canonical private repository: Skyhawk-Association/skyhawk.org.
  • Organization owner/admin identity used for repository authentication: geneatwell.
  • A2 repository root: /home/darwus/drupalbeta.
  • Local branch: main.
  • Origin: git@github-skyhawk:Skyhawk-Association/skyhawk.org.git.
  • A2 dedicated SSH private key: ~/.ssh/skyhawk_github_ed25519.
  • A2 SSH alias: github-skyhawk, targeting GitHub with the dedicated A2 key.
  • The corresponding public key is authorized on the existing GitHub owner account; the private key remains only on A2.
  • GitHub SSH authentication and private-repository access have been successfully proven from A2.
  • Current first-import staging contains 3292 files, including 737 exported configuration files.

What Belongs in Git

  • composer.json and composer.lock.
  • Current Skyhawk custom modules, CSS, JavaScript and other maintained site-specific application assets.
  • Drupal exported configuration from the current sync directory: sites/default/files/config_Ubo9gqxEHpoMEZNKbhJkVBUc9sN2NnzSV17M10F5hE7w77uws5OFNHtqnAAjUCO9dChbQn6-2A/sync.
  • Drupal scaffold/application files needed for reconstruction.
  • External libraries currently required by the working Drupal application when they are not otherwise reconstructed automatically by Composer.
  • Small reconstruction documentation and project metadata such as .gitignore, .gitattributes, .editorconfig and appropriate Drupal recipe/scaffold material.

What Does Not Belong in Git

  • Database dumps.
  • Passwords, API keys, private keys, credentials, environment secrets or live settings.php.
  • Drupal public user-upload storage.
  • Drupal private files.
  • Temporary files, caches, logs and generated debug evidence.
  • Ordinary server/database backups.
  • Composer-generated vendor, Drupal core and contributed module/theme trees that are reconstructed from Composer.
  • Historical preservation mirrors, completed diagnostic workspaces, obsolete patch archives and one-time maintenance debris.
  • Journal preservation material or other historical assets merely because they happen to reside beneath the Drupal project tree.

Authentication Architecture

  • A2 uses a dedicated Ed25519 key specifically named for Skyhawk GitHub access.
  • The key is selected through SSH alias github-skyhawk.
  • The public key is registered to the existing GitHub account that owns/administers the Skyhawk Association organization.
  • The repository remains private.
  • Do not publish, copy into documentation, or expose the private SSH key.

Normal Update Workflow

  1. Read LOST-D, Rules and this reference.
  2. Make and verify the actual Drupal/application change using the appropriate subject reference.
  3. Update durable documentation when current truth changes.
  4. Review git status and the proposed staged set.
  5. Ensure secrets, runtime files, uploads, private files, backups and unrelated preservation material are excluded.
  6. Stage only accepted architecture.
  7. Inspect staged content before commit.
  8. Create a concise commit describing the proven change.
  9. Push to the private Association repository.
  10. Verify the remote repository reflects the intended commit.

Reconstruction / Migration Model

  1. Provision a compatible host with PHP, database and required server capabilities.
  2. Clone the private Skyhawk-Association/skyhawk.org repository.
  3. Run Composer from the project root to reconstruct Drupal core, contributed projects and PHP dependencies from composer.json and composer.lock.
  4. Restore environment-specific settings and secrets outside Git.
  5. Restore the separately maintained Drupal database backup.
  6. Restore separately maintained public/private site files.
  7. Ensure the configuration sync path is available and reconcile Drupal configuration as appropriate to the restored database/state.
  8. Run Drupal database updates/cache rebuild as required.
  9. Verify the production site, custom modules, Views, routes, libraries, uploads and critical user paths before cutover.

Relationship to Backups

GitHub protects application architecture and change history. Database and file backups protect content and uploaded assets. Both are required for full recovery; neither substitutes for the other.

Maintenance Principle

Keep this reference concise and current. Record durable repository architecture and reconstruction facts here. Generate transient Git status, commit hashes, update availability and diagnostics when needed rather than accumulating them as prose.

Baseline Repository State

  • The initial reconstructable Skyhawk.org application baseline has been committed and pushed successfully to the private Skyhawk-Association/skyhawk.org repository.
  • Branch: main.
  • Initial baseline commit: 3246c05ddc10f310e676a9310ceb96697b202dd0.
  • The A2 local HEAD, upstream origin/main, and GitHub remote branch were independently verified to match after the push.
  • Future application changes follow the normal inspect, stage, review, commit, push and remote-verification workflow documented on this page.

Composer Maintenance Integration

Normal Composer maintenance uses /home/darwus/drupalbeta/bin/skyhawk-composer. Composer itself does not update GitHub.

  • The wrapper does not depend on interactive shell aliases.
  • PHP: /opt/alt/php84/usr/bin/php.
  • Composer: /home/darwus/composer/composer.phar.
  • Project Drush: /home/darwus/drupalbeta/vendor/bin/drush with explicit Drupal root /home/darwus/drupalbeta/web.
  • skyhawk-composer check verifies Git repository identity, branch, origin and synchronization state.
  • skyhawk-composer update <Composer arguments> requires a clean synchronized repository, runs Composer, then Drupal database updates/cache rebuild and creates a pending-publication marker.
  • Functional site acceptance occurs while the transaction remains pending.
  • skyhawk-composer finish <commit message> stages accepted architecture, rejects forbidden runtime/private material, commits, pushes and proves local/remote parity.
  • Direct Composer maintenance is not the normal Skyhawk procedure because it bypasses the Git completion lifecycle.
  • Composer hooks must not automatically commit or push.