Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

upgrade-provider no longer adds Fixes keyword and issue to automatic PRs #291

Closed
guineveresaenger opened this issue Nov 6, 2024 · 1 comment · Fixed by #293
Closed
Assignees
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed

Comments

@guineveresaenger
Copy link
Contributor

guineveresaenger commented Nov 6, 2024

What happened?

See example below - it seems that automation-created issues are missing the "Fixes" keyword.

Locally created PRs as pulumi/pulumi-dbtcloud#168 do not have this problem.

Example

pulumi/pulumi-auth0#687

should have closed

pulumi/pulumi-auth0#686

but was missing the "Fixes <issue #>" text .

Output of pulumi about

n/a

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@guineveresaenger guineveresaenger added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Nov 6, 2024
@danielrbradley danielrbradley removed the needs-triage Needs attention from the triage team label Nov 7, 2024
@danielrbradley
Copy link
Member

Ok, making some headway with this today … I’ve created tags in the upstream xyz provider so we can run upgrades on pulumi-xyz without it failing.

I’ve also added the ability to set the version of upgrade-provider when running in CI for better predictability and to enable testing.

Observations:

  1. When using CI to create both the issue and PR, I’m still seeing no “fixes” appear.
  2. When I re-run the PR creation locally it adds the “fixes”.
  3. When closing existing PRs and re-running in CI, I also see the “fixes”.

Therefore, I think we’re running into an issue with a delay in the GitHub issue searching. I think there’s a delay between opening an issue and being able to search on the contents of the body.

I would guess searching on author doesn’t have this issue because it’s using a simpler indexing strategy which is updated synchronously at the point of saving, but the text body searching is only “eventually consistent”.

Therefore, I could see a few approaches to solving this:

  1. Add a delay between creating the issue and starting the PR creation (not good IMO)
  2. Remove the filtering on pulumiupgradeproviderissue so we just fetch the 100 latest issues in the repo and look at their titles for matching the exact upgrade issue title format
  3. Try switching away from a keyword in the body and see if labels indexing is faster. This would require setting up new labels in all repos and reworking more aspects.

danielrbradley added a commit that referenced this issue Nov 8, 2024
This might be running very quickly after the issue was created and it might not yet be indexed. Instead, just list the latest 100 issues and filter on exact title format instead.

The current rate of issue creation is low enough that the latest 100 issues should safely include all open upgrade issues.

Fixes #291

We'll continue to use the token for issue de-duplication as this only happens once per day and so is reliably in the GH issue search index.
@pulumi-bot pulumi-bot added the resolution/fixed This issue was fixed label Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Some behavior is incorrect or out of spec resolution/fixed This issue was fixed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants