Problem/Motivation

Drupal releases are more complex than they used to be, with many processes and procedures that need to happen in a specific order.

Our current packaging system is a collection of jenkins jobs and drupal hooks that happen in a somewhat indeterminate way now.

It also does not currently package 8.8.* as we have been marketing it (namely, using composer to do so).

This meta will be used to track the various steps we're taking and the overall architecture we plan on implementing to facilitate this need.

Proposed resolution

TBD

Remaining tasks

Most of these tasks do not need separate child issues. Where appropriate, child issues are linked.

☑️ - Complete
➡️ - In progress
🔲 - not started

☑️ Design database schema changes - drupalorg_packaging_job_table
☑️ Implement the database schema for drupalorg_packaging_job_table
☑️ Implement the update hook for the database schema for drupalorg_packaging_job_table
☑️ Add drupalorg_packaging_job_table to the whitelist for dev sites
☑️ Rename git_hash to commit_id
☑️ Update new release packaging triggers to use new packaging_job entity
☑️ Audit the pift_ci_job entity to see what elements should be ported to the packaging_job entity
☑️ Define additional packaging features that should be supported by new packaging_job entity
☑️ The packaging_job entity needs a start function to send data to jenkins (runJob)
☑️ Packaging jenkins: update the updates.xml (updates meta data)
☑️ Packaging jenkins: drush callback to set the job to 'complete'
☑️ For initial testing, skip queuing and have job creation connect to jenkins and run. Jenkins jobs set to echo only.
☑️ Packaging jenkins: Call the packager (generate tar.gz and zip)
☑️ (on deployment) Test the new architecture of packaging in place of old version - prior to adding composer step
☑️ (on deployment) Add packaging queue supervisord config to puppet
☑️ If the new pipeline passes production validation, turn on queuing and allow jenkins to directly run the commands
☑️ Change package_release_run_queue to simply clear old queue and ignore
☑️ Packaging jenkins: call the subtree splitter step, and disable existing subtree splitter
☑️ Backup: Merge in @traviscarden's update to subtree splitter and add error handling so we can bail if it tries to build an old package, and then be able to re-run the job to complete packaging. Kludgy workaround but will allow us to release without risk of publishing the wrong splits in the package.

Following the release of 9.0.0-alpha1 with partial manual intervention:
☑️ Make sure that the composer create project command properly returns an exception when failing
☑️ Poll packagist to ensure it's ready to build ^^ i.e: retry the composer create project command with good error state handling every 15 seconds following a packaging attempt, and bail after 30 min or so
☑️ Make the subtree splitter take the sha1 of packages as an optional argument, so that for tags specifically we can package without a sha if needed
☑️ However, tags should pass on a proper sha1 where possible as well

Once no manual intervention is required for packaging, finishing the following:
☑️ Speed up packaging by not re-splitting the subtrees for tagged releases - instead use the split generated by the latest dev release, and re-associate the correct tags with their correct commits.
☑️ Create a local sub-tree split mechanism for packaging
☑️ Primary goal: Make another intermediate deployment with working local sub-tree splitting to enhance security release packaging process

Follow-ups

After initial deployment and a production release test, further extend this work by:
🔲 After packaging pipeline is rebuilt and in production - re-audit the security packaging enhancements
🔲 Packaging jenkins: create a git clone bash script
🔲 Packaging jenkins: Call the project_composer drush hooks
🔲 Packaging jenkins: Call release hash processing, ensuring it understands published vs. not published
🔲 Packaging jenkins: If someone pushes a new Stable release of core, automatically update the DrupalCI branch label
🔲 Convert hook functions into drush commands, and remove old implementations
🔲 Parallelize local sub-tree splitting to speed up the process
🔲 Create maintenance job to handle stuck drupalorg packaging jobs in the queue

Comments

Mixologic created an issue. See original summary.

Mixologic’s picture

dww’s picture

Issue summary: View changes
Issue tags: +Needs issue summary update

Thanks for this meta plan. The summary says:

This meta will be used to track the various steps we're taking and the overall architecture we plan on implementing to facilitate this need.

Steps can be covered by child issues (thanks!), but "overall architecture we plan on implementing" could use some fleshing out in a summary. Adding template, but proposed resolution is TBD.

hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes

Updating with the adjusted order of next packaging pipeline steps, now that the initial deployment is complete.

Unfortunately the initial deployment and packaging of 8.8.2 revealed that Packagist isn't ready to serve the subtree splits immediately after we push them up, so when the next pipeline step runs it's still grabbing old splits.

However, since our goal is to package from local subtree splits anyway - we intend to go ahead and implement that ASAP which solves the above problem as well.

hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
Status: Active » Needs review

Updating issue summary to reflect that the primary work is complete. Marking needs review until we have a) verified that the latest changes work fully unattended, and b) have moved the follow ups to a new issue.