| [11:51:37] | <symbioquine[m]> | Another downside to not having a lockfile saved somewhere permanent is that 3.2.3 no longer passes due to new depedency versions (and CodeSniffer deprecations) getting picked up: https://github.com/symbioquine/farmOS/actions/runs/10228853311 |
| [11:54:39] | <symbioquine[m]> | * Another downside to not having a lockfile saved somewhere permanent is that 3.2.3 no longer passes due to new dependency versions (and deprecations observed by CodeSniffer) getting picked up: https://github.com/symbioquine/farmOS/actions/runs/10228853311 |
| [12:47:25] | <mstenta[m]> | Committing composer.lock for tagged releases in farmOS/composer-project seems like a logical next step to me |
| [12:48:02] | <symbioquine[m]> | mstenta[m]: Agreed, but I'm not blocked on that since I have this work-around: https://github.com/farmOS/farmOS/pull/864#issuecomment-2266918635 |
| [12:48:42] | <mstenta[m]> | Committing composer.lock for every commit to 3.x is tricker, but I don't know if there's a strong need for that |
| [12:49:26] | <mstenta[m]> | (The trickiness is that we need to commit it to the composer-project, NOT to the farmOS repo itself.) |
| [12:50:13] | <mstenta[m]> | Afaik committing composer.lock in the farmOS repo itself wouldn't provide any value |
| [12:50:39] | <symbioquine[m]> | Yeah, I think just having reproducible tagged releases would be a great compromise/step-forward |
| [12:51:49] | <mstenta[m]> | Well that PR I drafted a while back proposed a simple way of doing that. It had a few other things in it though, so maybe we just need to reroll and reconsider the simplest bit of it |
| [12:53:30] | <mstenta[m]> | Tl;dr: it modifies our GitHub action (in farmOS core repo) so that when a tag is pushed, it automatically makes a commit and tag on the composer-project repo. It pushes the tag but does NOT push the main branch to that repo. Thus we end up with composer.lock committed ONLY to tags in that repo, but not to the main branch itself. |
| [12:55:18] | <symbioquine[m]> | mstenta[m]: Cool |
| [12:55:27] | <mstenta[m]> | (The tag commit ONLY adds composer.lock) |
| [12:55:45] | <symbioquine[m]> | Is it an issue if the tags are orphaned? i.e. the tagged commits aren't on any branch? |
| [12:56:07] | <mstenta[m]> | I don't think there's any problem with that |
| [12:56:41] | <mstenta[m]> | I think this is roughly the same approach that Drupal core's own "recommended-project" uses |
| [12:58:56] | <mstenta[m]> | Notice how there is only one commit in the history of composer.lock on the 11.0.0 tag: https://github.com/drupal/recommended-project/commits/11.0.0/composer.lock |
| [12:59:47] | <mstenta[m]> | I've seen this "hanging tag" approach on other projects too |
| [13:00:48] | <mstenta[m]> | It's a clever way to add stuff that is only needed for releases, without needing to add/revert it in the main branch |
| [13:02:57] | <mstenta[m]> | With farmOS/composer-project it would be interesting, though, because we very rarely update that repo, so we'd end up having lots of tags "branching" off of the same "3.x" commit |
| [13:03:22] | <mstenta[m]> | Might look weird when visualized, but conceptually nothing wrong with it, I don't think |
| [13:06:45] | <mstenta[m]> | Further reading: https://stackoverflow.com/questions/14613540/do-git-tags-only-apply-to-t... |
| [13:07:24] | <symbioquine[m]> | ACTION uploaded an image: (212KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/WIpvCTmAzxeBSvGC... > |
| [13:09:30] | <mstenta[m]> | Hmm I'm on my phone and for some reason I can't see your image |
| [13:09:58] | <symbioquine[m]> | Not critical. Just output of git log --oneline --abbrev-commit --all --graph --decorate --color in drupal/recommended-project |
| [13:10:35] | <symbioquine[m]> | Shows each of those tags with a single commit but not on any branch |
| [13:10:39] | <mstenta[m]> | Oh interesting. Wish I could see :-) |
| [13:11:49] | <symbioquine[m]> | Clicking on the commit for any of those tags shows a warning banner: |
| [13:11:52] | <symbioquine[m]> | ACTION uploaded an image: (12KiB) < https://matrix.org/_matrix/media/v3/download/matrix.org/OEuMXOGaMosPiWSB... > |
| [13:12:01] | <symbioquine[m]> | "This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository." |
| [13:12:14] | <symbioquine[m]> | But I guess that's not a problem per-se |
| [13:13:14] | <mstenta[m]> | Yea saw that |
| [13:13:46] | <mstenta[m]> | I've noticed GitHub does that in various situations |
| [13:14:03] | <mstenta[m]> | I imagine GitHub has rules for which commits to keep/purge |
| [13:14:11] | <mstenta[m]> | Just like Git itself |
| [13:14:19] | <mstenta[m]> | Tags are always "keep" :-) |
| [13:14:57] | <mstenta[m]> | I think GitHub keeps commits for PRs even when the branch hets deleted too |
