search

PatMyron / cloudformation-resource-providers

automated monorepo of public CloudFormation AWS resource providers
https://aws.amazon.com/blogs/aws/cloudformation-update-cli-third-party-resource-support-registry/
12 stars 1 forks source link

Update commits do not provide a helpful diff #3

Open benkehoe opened 2 years ago

benkehoe commented 2 years ago

I guess the pull requests for updating the repo commits are automatically generated, and they use a commit that does not have the current head as a parent, so the .gitmodules file appears new every time. This means you can't see which repos have been updated. It'd be nice to have a meaningful diff (and history) to be able to know what's changing. Example: https://github.com/PatMyron/cloudformation-resource-providers/pull/1/files#diff-fe7afb5c9c916e521401d3fcfb4277d5071798c3baf83baf11d6071742823584

PatMyron commented 2 years ago

Agreed that'd be better, here's where commit-message is set if anyone figures out how to improve: https://github.com/PatMyron/cloudformation-resource-providers/blob/main/.github/workflows/cron.yaml#L18-L22

benkehoe commented 2 years ago

Maybe adding base: main?

PatMyron commented 2 years ago

base branch for the automatic PR is already main: https://github.com/PatMyron/cloudformation-resource-providers/pull/1

benkehoe commented 2 years ago

Yeah, the action notes that actions which checkout a commit may require base: main as input to the create-pull-request action. It's weird because the commit created has no parent

benkehoe commented 2 years ago

Wait. The default branch on the repo is create-pull-request/patch image and main is empty 🤔 image

PatMyron commented 2 years ago

working on main and the PR keeps force pushing a commit to create-pull-request/patch using main as base (switched default to create-pull-request/patch so everyone can easily see the code written by those auto PRs)

benkehoe commented 2 years ago

this means that the diff of the PR is always against main which does not have .gitmodules. If the PR is never merged, .gitmodules is always new in the commit.

Wouldn't it make sense to have the action work on main, automatically push a commit (if anything has changed), and do work on workflows in a separate branch?

PatMyron commented 2 years ago

tbh haven't dug into git submodules enough to understand what happens when the same submodule is added more than once

agree the generic commit force-pushing without merging is hacky/unideal fork, test, and open a PR if desired :) (don't have much time on this now that I left CloudFormation, just figured I'd share this monorepo that helped me while working there)