java postprocessor isn't hermetic for libraries-bom versions

[BenWhitehead]

When OwlBot runs it's post processor it's possible that the version updates to the README.md for libraries-bom won't be properly proposed in the bump PR and will then be proposed multiple times in other PRs.

Example of java-storage PR where it received the README.md update even though the PR wasn't related to version bumps: https://github.com/googleapis/java-storage/pull/1186/files

Corresponding libraries-bom snippet at the time of postprocessor run for PR 1186: https://github.com/googleapis/java-storage/blob/1e55dba4cd5111472b9bb05db08ba7e47fafe762/samples/snippets/pom.xml#L27

[parthea]

Hi @Neenu1995 , this issue is out of SLO because it's marked as P1. Please could you take a look?

[Neenu1995]

I plan to a take a look in the coming weeks.

Mean while, downgrading it to p2 because it is no-blocking.

[suztomo]

I also observed the postprocessor touching the README.md's versions caused pull request conflict state in pull requests. A potential scenario:

1. Pull Request A is created. The postprocessor runs, modifying README.md to have libraries-bom 1.0.0. It's kept open.
2. Libraries BOM 1.1.0 is released
3. Pull Request B is created. The postprocessor runs, modifying README.md to have libraries-bom 1.1.0.
4. Pull Request B is merged.
5. Now Pull Request A is in conflict state at libraries BOM version in README.md.

In this scenario, adding "owlbot:run" label should resolve the conflict in Pull Request A.

@BenWhitehead Do you also think the annoyance of this OwlBot postprocessor is at the conflicts? Or do you observe something worse?

[BenWhitehead]

In my mind it's less about maneuvering around how to get a conflicted PR unstuck, and more the fact that docs updates that should happen along with a dependency bump are not isolated to that dependency bump PR. Instead every PR that happens to run between the time of release and the time of the dependency bump PR will have this proposed change.

[suztomo]

Thanks.

Idea memo: java postprocessor should upgrade the libraries-bom version only when a pull request is upgrading the libraries-bom version in samples. (Or just files in samples)

Todo on me: read the postprocessor code to determine the logic of README updates.

[suztomo]

Current setup:

• The postprocessor's entrypoint.sh calls write_templates.sh
• write_templates.sh calls owlbot.py in the repository. Note that this owlbot.py plays an important role to bring OwlBot changes from google3 from its staging directory.
• owlbot.py calls java.common_templates
• java.common_templates uses _common_template_metadata(), which looks up the latest Libraries BOM version:

    metadata["latest_bom_version"] = latest_maven_version(
        group_id="com.google.cloud",
        artifact_id="libraries-bom",
    )
  

My current idea: somehow we update the templates only when it's touching README or samples directory.

• We need to update templates when owlbot-postprocessor file changes
• Maybe pass an environment variable from entrypoint.sh to the Python common_templates function?
  Monorepo loops the logic. Ensure reset the value for each module.
• What's the best way to find affected files in a pull request? git diff --name-only origin/main?

[chingor13]

Is this still an issue (it's OOSLO)? Most of the libraries have moved to the monorepo.

[suztomo]

This is still an issue. (I don't think we need SLO for this issue.)