improved caching

[AkarshSahlot]

Logic for caching prior is:
Choose a completely new entry in the cache only if:
The build is taking place on the primary branch,
Build duration is more than 3 minutes (env.duration > 180),
The step is executed self-sufficiently (always()).
The updated version improved the cache by:
Efficient use of bazel-disk caching to improve performance.
Broadening the restore-keys to increase the possibility of cache hits.
Performing simultaneous builds to reduce the total build time.
overall speedup bazel CI builds

[smolkaj]

Why are we adding a LICENSE file and a dubious README..md file to the workflows folder?

[jafingerhut]

Why are we adding a LICENSE file and a dubious README..md file to the workflows folder?

If I understand correctly, the LICENSE and README.md file might be from a software package that helps one run Github Actions workflows on a local development system. If so, I agree that they should be removed from this PR, leaving only the modified ci-build-proto.yml file (which I have not attempted to understand or review the changes proposed here).

[AkarshSahlot]

Why are we adding a LICENSE file and a dubious README..md file to the workflows folder?

If I understand correctly, the LICENSE and README.md file might be from a software package that helps one run Github Actions workflows on a local development system. If so, I agree that they should be removed from this PR, leaving only the modified ci-build-proto.yml file (which I have not attempted to understand or review the changes proposed here).
I have deleted all unnecessary files including act, license and readme.

[jafingerhut]

Removing these comments seems like the wrong thing to do, unless you know that they are obsolete or wrong. If they are correct, they were written by someone who wanted to remember the reason that the lines of code were added, and why they were written in this way. That is valuable information, and should not be discarded.

[AkarshSahlot]

Ok I will add them back

[jafingerhut]

There are many more such comments removed elsewhere in your PR. My comment applies to all of those changes, not only the ones that I directly commented on.

[jafingerhut]

Please, please look at the diffs of your PR on the Github web site to see if it is what you think it should be. Without doing that, you might be proposing changes in the PR that you forgot you made, or never even intended to make.

[AkarshSahlot]

ok I will add back all those changes in comments

[smolkaj]

@AkarshSahlot thanks for looking into improving cache performance! Fast CI builds are super useful to allow quickly operating on PRs when they don't build the first time around.

From what I understand, the main improvement here is to enable Bazel disk caching?

A few questions:

• How much of a speed up does this buy us in practice? Looks like the CI builds are already relatively fast....looking over https://github.com/p4lang/p4runtime/actions, somewhere in the 1 - 3 min range.
• Last time I checked, the problem with --disk_cache was that it would make the cache grow without bounds, so our GitHub Actions would eventually start failing. References: improve --experimental_local_disk_cache bazelbuild/bazel#4870 Implement automatic garbage collection for the disk cache bazelbuild/bazel#5139 Maybe by now there exists native Bazel support for garbage collection? If not, what is our strategy?

[chrispsommers]

@AkarshSahlot bump?

[smolkaj]

Closing this PR since it currently seems to be stale.
Please don't hesitate to reopen if you'd like to push this over the finish line, @AkarshSahlot.