millnut
commented
3 months ago Hi everyone, I've been doing a lot of research over the last 3-4 months around having the modules available on drupal.org and the processes around them I'll go through the questions above first then go into detail about where I have got to;
The drupal.org issue queues are less user friendly than Github issues (a number of people have mentioned this).
This one has a very easy solution we can disable the drupal.org issue tracker per module and on the project overview direct users to the correct github issues.
What do we do with the issues from Github when moving to drupal.org? We have lots of issues (open and closed) on the issues queues in each repository on Github. Can we migrate them to Drupal.org and if so do we want to? Is it worth the effort?
If we follow the above we can keep the issues within GitHub, if we were to add issues into drupal.org monitoring will be tricky as we'd lose the overview of all issues we currently get with GitHub
Composer packages are currently on the namespace localgovdrupal/[project_name]. Moving to drupal.org would change to drupal/[project_name]
Correct, when we start having projects on drupal.org for each module we put there we would need to update each package where it is dependent to now use drupal/[project_name]
How do attributions to contributors work on issues comments?
If issues stay on GitHub there will be no attribution on issues. Currently on drupal.org when a user marks a issue comment as merged/fixed you can select the issues who attributed to fixing the issue and assigned them credit.
How do attributions work in commit messages?
I'm still testing this out and don't have an exact answer yet, but I believe drupal.org does attribute for commit messages as long as the commit email address is in your developer profile at drupal.org gitlab. Previously you could attribute each user who helped on the issue and then also specify the author of the issue on the commit like the below (this is something I'm due to test to confirm this still works):
git commit -m '{Issue number} by username1, username2, username3: {Issue description}' --author="{Author_Drupal_Username} <Author_Drupal_Email>"Is anyone using using Github as upstream dependency?
If someone is using GitHub as an upstream we can specify in release notes there is a location change. However if development stays on GitHub this should not be a problem which I'll explain later on.
Is it possible to run our integration tests on drupal.org a) for a single project b) for the entire localgov_project?
Drupal GitLab CI has improved massively throughout the last 3-6months it would only run on a single project/module but it would run checks for the following using Drupal cores linting/check rules (we can override if required);
- PHP min and max versions Drupal core supports
- Drupal coding standards
- Deprecations
- Tests on current support and future Drupal core releases
- Spelling testing
- ESLint testing
- Stylelint testing
- PHPUnit testing (previous and max versions)
- Composer checks
- Composer linting
You can look into the detail of what it runs from the work I've done previously on the geo_entity module
LocalGov Drupal module availability on drupal.org
Looking at previous discussions around this most people enjoy the user experience of both issues and development (PRs, reviews, etc...) on GitHub so I've based most of my thinking around this.
To start I think we should choose a localgov module that is dependent on the least and add only the Drupal.org GitLab CI config file to each module.
By keeping the development on GitHub we can take advantage of GitHub actions and have an action that runs on pushes to the default branch and on tag creation. This will then have an action "mirror" which will push the branch e.g. 3.x and any tag e.g. 3.0.1, 3.0.2 to the drupal.org git remote using git within the action.
The user that would be used on the action to push to drupal.org will be independent from anyone working on the project, for example we could have a user called localgovdrupal-ci on drupal.org which is used solely for pushing code from GitHub to drupal.org.
A breakdown of what a typical dev branch or release would look like going to drupal.org
Dev branch (e.g. 3.x, known as 3.x-dev on drupal.org)
- User works on issue (bug/feature) on GitHub
- They create their PR on GitHub and the current workflow tests are run
- The PR is reviewed as it is now and either merged or comments added
- PR is merged to the development branch e.g.
3.x - The new "mirror" workflow is run and pushes the changes from GitHub
3.xbranch to the drupal.org3.xdev branch using a drupal.org account used for only CI e.g.localgovdrupal-ci(this shouldn't be owned by a single user account, to handle cases where people may leave the project) - The drupal.org GitLab CI tests run
The reason we have tests at both GitHub and drupal.org GitLab CI is so that the infrastructure is all in place should at some point there is a reason to develop fully on drupal.org.
Release (e.g. 3.0.1 on drupal.org)
- A new release PR is created
- The PR on GitHub and the current workflow tests are run
- The PR is reviewed as it is now and either merged or comments added
- PR is merged to the branch e.g.
3.x - A release is created on GitHub along with a tag
- The new "mirror" workflow is run and pushes the tag from GitHub
3.0.1to the drupal.org3.0.1using a drupal.org account used for only CI e.g.localgovdrupal-ci(this shouldn't be owned by a single user account, to handle cases where people may leave the project) - Once the tag is available on drupal.org, any maintainer added to the module on drupal.org can log in find the recently pushed tag
3.0.1and set this as the latest recommended release on drupal.org
The process above should give us the best of both worlds; development/issue tracking on GitHub, with the benefits of more visibility on drupal.org, surfacing available updates through Drupal's update system and installation metrics for each module.
Let me know your thoughts and questions on any of the above. I'm also available on the slack channels should anyone want to unpick this some more with me.
We have been discussing moving projects to drupal.org for a long time, for a number of reasons, but it is not quick or simple and there are a number of factors that need to be considered. Renewed interest from a number of suppliers and the core team as well as a changing tech climate on drupal.org has prompted the Technical Group to refocus on this and prioritise making a plan of action.
Motivations
There are a number of motivating factors for moving some or all of our repositories from Github to Drupal.org
We do already have representation for both the main installation profiles:
Currently I (try to) keep these two projects updated manually, by pushing new release tags to Drupal.org and creating a matching release. There are also a few issues on the issues queue: https://www.drupal.org/project/issues/localgov?text=&status=All&priorities=All&categories=All&version=All&component=All
Challenges / problems
We have already identified a number of problems or challenges with moving one or more projects to drupal.org.
Previous / related issues
Tagging people who I think have been involved in the discussion to date and might want to contribute to the discussion and implementation:
@stephen-cox @msayoung @millnut @harrybarnard @andybroomfield @Adnan-cds @aaronhirtenstein @willguv @joachim-n