Duplicated HubCap bump PRs with merge conflicts
dbeatty10 opened this issue · 4 comments
Description
Some pull requests (PRs) that bump HubCap are double-created and include merge conflicts. An example: #1477.
Root cause(s)
GitHub Actions are utilized to manage the queue of merge requests, and it is unaware if certain merge requests are essentially duplicated.
Potential solutions
- If the only merge conflict is in relation to the
published_atkey, it is likely that the pull request can just be closed manually since it is redundant. - Is there a method to auto-close pull requests that have merge conflicts plus certain properties?
- Is there a way to prevent adding a merge request that would introduce a conflict proactively?
- Could the
published_atproperty be removed without loss of desirable functionality?
Solution for now
Periodically close these pull requests manually for now since it is easy enough to do and no risk. It wouldn't prevent us from pursuing another option down the road.
It looks like the value for published_at comes from these locations:
- https://github.com/dbt-labs/hubcap/blob/f2609a44f0ef916eacfd5bf8b693947761cef38b/hubcap/records.py#L177
- https://github.com/dbt-labs/hubcap/blob/f2609a44f0ef916eacfd5bf8b693947761cef38b/hubcap/setup.py#L16
The usage of datetime.datetime.now means that the script is not idempotent, but will generate a different timestamp each time the script is executed. The end result is merge conflicts.
Is published_at even used or necessary? If not, the easiest solution would be to just remove it :)
If we do need to keep it, the merge conflicts will be reduced in proportion to the stability of the value. e.g. using the timestamp of the tag rather than the timestamp that the JSON was rendered like this would eliminate most/all of the merge conflicts.
@VersusFacit do you know what would happen if we dropped published_at from the JSON in places like this?
Example merge conflict:
Resolved by dbt-labs/hubcap#141