CI Pipeline: Add upgrade report

Thanks for your interest and initiative on this.

Personally, I think this particular approach is the wrong one. The results of this job are only relevant every couple of years when porting to a new major version of core. It’s a huge waste of computing resources, power (and therefore carbon in the atmosphere), and DA money to run this job on every pipeline for every change.

I’m much more of a fan of running this job in a manual pipeline when I’m actively working on a new major version port.

Personally, I’d revert this commit. But instead of getting on a git pushing match, I wanted to write this here so we could discuss like maintainers. 😂

Thanks again,
-Derek

bluegeek9 → changed the visibility of the branch 8.x-2.x to hidden.

I removed it from the 8.x-2.x branch. That branch probably should never support Drupal 12.

I want to keep it for 3.0.x. It will support Drupal 12 and there is more work before a 3.0.0 release can be made.

Thanks. A few thoughts:

1. Agreed we shouldn't be trying to port 8.x-2.x to D12.
2. Personally, I wouldn't worry about trying to port anything to D12 until at least 12.0.0-beta1 is out. "Chasing HEAD" is a nightmare. I wouldn't be trying to follow bleeding edge core changes as they happen. I'd wait until we were sure the D12 API wasn't going to change, and then worry about porting.
3. Between now and when #2 becomes real, running this job on every push to every issue fork, and on every upstream commit, is a waste of time and resources. So I'd remove this from the 3.0.x branch, too, and run the job manually when we're actively porting to D12.
4. Declaring we're already compatible with D12 is a lie, since we have no idea what other changes will be needed to actually work with a 12.0.0 release.
5. It's helpful if the Git history is accurate. Too bad that you reverted the change on the 8.x-2.x branch with the message: "Issue #3538409 by bluegeek9: CI Pipeline: Add upgrade report". You already added the report, this commit was to remove it. 😂 Please don't auto-pilot with the crappy d.o commit messages. 😅 It's best to say what you're actually changing. In this case, "revert" would be a good word to include. Frankly, instead of a new MR and all that noise, I would have run git revert cf9ba43b26d at the CLI and pushed that.

Meta: I know you were added as a co-maintainer here since I'm chronically busy, over-committed, and don't have enough time for this project on a regular basis. That said, it'd be nice if you waited more than a few hours between opening issues and making commits. 😅 I believe that nothing is so urgent here than waiting a day or 3 would cause any harm. Would you be willing to treat this more as a collaboration, allowing time for myself (and anyone else interested in this project) to weigh in on issues and MRs you open, instead of directly committing them as if you're managing a project all on your own? Thanks!