Problem/Motivation

Currently, development for config_enforce_devel happens in a separate project: https://www.drupal.org/project/config_enforce_devel

This was originally done as a security measure: config_enforce should be in your composer require section, and config_enforce_devel should only be in your require-dev section. The upshot of this is that in production, the tool that is used to change enforcement settings isn't even available (i.e. the code isn't sitting there waiting to be enabled/installed, in contrast with something like Views UI). Note: In addition, config_devel is a dependency of config_enforce_devel, and may be best to keep out of production files.

As a consequence of these two being separate projects, development on these two projects has multiple points of unnecessary overhead due to the need to manage two separate projects. There are code paths from Config Enforce Devel that depend on code from Config Enforce, and keeping them in sync is not a simple task and developer experience is not very smooth.

On a more practical level, there are some other consequences:

  • Issue management: We often need to create essentially duplicate issues (and MRs, etc.) across both projects
  • User friendliness: Users may be confused as to where to report bugs/request features/etc.

Proposed resolution

We still want to maintain two separate projects on drupal.org, two sets of releases, and the require/require-dev structure outlined above.

Code structure changes

Do a subtree merge to pull config_enforce_devel's codebase with history (excluding .local-dev, .ddev, and some other directories/files) into ./.config_enforce_devel in this repository. In our testing, including a dot-prefixed module into the codebase makes that submodule "invisible" to Drush and the Drupal UI and not able to be installed. This way the edge case users that are doing something unconventional such as directly cloning config_enforce or configuring composer to clone all dependencies (prefer-source option), would not end up with config_enforce_devel ready to install on their production environment.

Regardless of where we place config_enforce_devel's inside of config_enforce, we will update .gitattributes to exclude all config_enforce_devel files from packaging, so that when pulling in config_enforce via composer, or even a zip or tarball, config_enforce_devel will not be included. One edge case is that composer can be configured to clone all dependencies (prefer-source option), which would end up including config_enforce_devel's code.

We will pull over the local-dev and DDEV setup from config_enforce_devel and adapt it to work with config_enforce and the revised file structure that we come up with. config_enforce_devel can likely be brought in as a path repository in our local-dev composer file.

We will also need to figure out a releasing/packaging strategy so that we push releases to config_enforce_devel, in terms of git git subtree push --prefix .config_enforce_devel seems like it would be part of it. On a related note but likely out of scope here, we may want to be more precise about our composer requirements in between the two projects, or at least more aware of potential incompatibilities between the two codebases. It seems to me the simplest thing would be to make config_enforce_devel's composer.json depend on the same version as "self" at all times.

Move any relevant issues from Config Enforce Devel to Config Enforce, possibly under a new Component called Config Enforce Devel. Remaining issues can be closed, and the Config Enforce Devel issue queue can be closed. We can then link from the Config Enforce Devel project sidebar to the Config Enforce issue queue.

We also considered that currently we could have a maintainer that only works on Config Enforce Devel. Going forward, such a maintainer would not have direct VCS write access, and their MRs would be reviewed/merged by full maintainers, in a model somewhat similar to Drupal core and its subsystem maintainers.

Remaining tasks

Experiment with placement of config_enforce_devel inside config_enforce, to see if we can have Drupal's extension system ignore config_enforce_devel code, even if it's present (which might be the case if a user cloned the module in, or used composer with prefer-source).

Comments

star-szr created an issue. See original summary.

star-szr’s picture

star-szr
he/him
Primary language English
commented
Issue summary: View changes

  • e23bc821 committed on 2.0.x 
    dev: #3559151 Exclude Drumkit `d` symlink from packaging

  • ergonlogic committed 12559d9a on 2.0.x 
    dev: #3559151 Add Drumkit target to make releases of both CE and CED

  • 7180953c committed on 2.0.x 
    docs: #3559151 Move docs out of CED subdirectory

  • ergonlogic committed 42425446 on 2.0.x 
    dev: #3559151 Update Composer config to accomodate new repo structure

  • ergonlogic committed 94d06c8c on 2.0.x 
    dev: #3559151 Update DDEV config to accomodate new repo structure

  • ergonlogic committed 06beaf86 on 2.0.x 
    dev: #3559151 Move Drumkit to root of the project.

  • ergonlogic committed c3381f7c on 2.0.x 
    dev: #3559151 Update .gitattributes to ignore .config_enforce_devel

  • ergonlogic committed dfcb4fb3 on 2.0.x 
    dev: #3559151 Move local development resources to the root of the...

  • ergonlogic committed 28ff6ca2 on 2.0.x 
    docs: #3559151 Update CED README with link to CE project.

  • ergonlogic committed 7c629950 on 2.0.x 
    docs: #3559151 Update READMEs to explain new subtree structure.

  • star-szr committed 8323aa17 on 2.0.x 
    dev: #3559151 Fix `make releases`, update CED repo URL

By: ergonlogic...
star-szr’s picture

star-szr
he/him
Primary language English
commented
Status: Active » Fixed

This is complete!

For the record, we made a detailed checklist on a GitLab issue, pasting the contents here to show the steps we went through.

- [x] Push 2.0.x branch from drupal.org config_enforce to this repo
- [x] Push 2.0.x branch from drupal.org config_enforce_devel to https://gitlab.com/consensus.enterprises/drupal/config_enforce_devel
- [x] Review (possibly merge) MRs on config_enforce_devel on drupal.org
    - [x] Close https://git.drupalcode.org/project/config_enforce_devel/-/merge_requests/15 with a comment, the changes are small and trivial to reimplement, and cannot be merged as-is
    - [x] Review https://git.drupalcode.org/project/config_enforce_devel/-/merge_requests/23
    - [x] Consider merging https://git.drupalcode.org/project/config_enforce_devel/-/merge_requests/24 into 2.0.x
    - [x] Close https://git.drupalcode.org/project/config_enforce_devel/-/merge_requests/25 and the associated issue, we will create target modules in the SimpleTest site instead
    - [x] Review https://git.drupalcode.org/project/config_enforce_devel/-/merge_requests/26 - possibly it's merging the previous two into one MR, but doesn't seem to apply, possibly can be closed
    - [x] Close https://git.drupalcode.org/project/config_enforce_devel/-/merge_requests/27 and the associated issue, or move to CE and repurpose to use the SimpleTest sites/ directory approach instead
- [x] Subtree ~~merge~~ *add* CED into CE/.config_enforce_devel
    - [x] Add `monorepo` branches to both projects
    - [x] ~~Prepare CED by moving the codebase into the desired subdirectory:~~ This is no longer relevant, since we're using a `git subtree add`/`git subtree push` approach.
    ```
    git clone git@gitlab.com:consensus.enterprises/drupal/config_enforce_devel.git --branch monorepo
    cd config_enforce_devel
    git filter-repo --to-subdirectory-filter .config_enforce_devel --refs monorepo
    ```
    - [x] ~~Do the subtree merge:~~ Replaced by the `git subtree add` below
    ```
    cd ..
    git clone git@gitlab.com:consensus.enterprises/drupal/config_enforce.git --branch=monorepo
    cd config_enforce
    git remote add ced ../config_enforce_devel
    git fetch ced --no-tags
    git merge --allow-unrelated-histories ced/monorepo
    git remote remove ced
    ```
    - [x] Do the subtree add:
    ```
    git subtree add --prefix=.config_enforce_devel/ git@gitlab.com:consensus.enterprises/drupal/config_enforce_devel.git 2.0.x
    ```
    - [x] Test that a `git subtree push` will still look reasonable of the 2.0.x branch of CED
    - [x] Check that we can push to drupal.org repo for config_enforce (because we've re-written the history)
    - [x] Move .local-dev and .ddev to top level
    - [x] Update .gitattributes at top level to include 
    - [x] Update CE README to explain the presence of CED in a subdir
    - [x] Review to see if there are any other changes/removals that make sense at this point
    - [x] Move CED docs to project root
    - [x] Sort out publishing of docs site in CI (https://www.drupal.org/project/config_enforce/issues/3559151)
    - [x] Exclude Drumkit components via `.gitattributes`
- [x] Update .local-dev and .ddev to function with the new structure
    - [x] Check that the path to the CED module is not nested within CE, but its own separate path (that we have configured as a composer path repo)
- [x] Test/come up with the release process manually in our sandbox environment
    - [x] Push changes in CE to CED (from within CE): `git subtree push --prefix=.config_enforce_devel/ git@gitlab.com:consensus.enterprises/drupal/config_enforce_devel.git 2.0.x`
    - [x] Push tags to both projects (CE & CED) - Note that there doesn't appear to be a way to push tags directly to CED via `git subtree push`
    - [x] Cut releases so we can examine the resulting tarballs
- [x] Add Drumkit targets to automate the release process:
    - [x] Pass in or prompt for a tag name
        - [x] Prompt could display the latest tag for reference (because you most often want to do something like alpha-n+1, or later a.b.n+1 or similar)
    - [x] Subtree push to config_enforce_devel as part of the release process
        - [x] Prompt/confirm before pushing to git.drupalcode.org
- [x] Test that the security promises that we have made are still being kept when releasing on git.drupalcode.org (specifically, no CED packaged with CE, and no .local-dev or .ddev either)

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.