Adding breaking change label to container

[javanlacerda]

Summary

It checks and adds the breaking-change label to the container that is created by the build-container action.
It also adds a label with the commit-hash to the container.

Release Note

Documentation

Example of a build with this configuration:

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 50.19%. Comparing base (cf238ac) to head (358a756).
Report is 219 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1809      +/-   ##
==========================================
- Coverage   57.93%   50.19%   -7.75%     
==========================================
  Files          50       70      +20     
  Lines        3119     4202    +1083     
==========================================
+ Hits         1807     2109     +302     
- Misses       1154     1858     +704     
- Partials      158      235      +77     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[haydentherapper]

Can we check if we need to create a PAT for this or if the default token is fine? We sometimes hit rate limits when querying GitHub. I’d rather not manage another token but just wanna check.

Cc @cpanato

[haydentherapper]

One other idea is to change this to fire on PR closure, like what’s documented in https://stackoverflow.com/questions/71523153/github-actions-on-pull-request-merged-with-specific-labels

You could then checkout from HEAD based on the git sha.

[haydentherapper]

Eh, that might not work - commit shas will differ after being squashed to merge to HEAD.

[javanlacerda]

I think it should be fine as I tested this same action in my fork and it worked properly. https://github.com/javanlacerda/fulcio/actions/runs/10997017464/job/30531560844. Just hadn't the authorization to push the image, what is expected.

[cpanato]

i see this and will reply tomorrow (25/sept/2024) sorry !

[jku]

We sometimes hit rate limits when querying GitHub

gh pr list does not use the "search" endpoint which I believe is the problematic one (since search rate limit is 30/minute instead of 5000/hour like others so temporary spikes can easily hit it) so I guess this is fine.

[cpanato]

if i run that locally it does not work, need to do a setup before

$ gh pr list --state all --search "sha:7920be28f7f58020c4da8ab9bb78554ad7cd67ea" --label "breaking-change"
X No default remote repository has been set for this directory.

please run `gh repo set-default` to select a default remote repository.

[javanlacerda]

hmmm, that's weird because it works on my fork. Maybe because we do the checkout at line 37?

[javanlacerda]

example here https://github.com/javanlacerda/fulcio/actions/runs/11242081243/job/31254992474

[cpanato]

ok, so maybe is a local thing, not related to the gh actions env. thanks for the clarification

[haydentherapper]

Thinking about how this will be used in PGI: Have you thought about how we will handle if multiple PRs are merged in a short period with only one labeled as a breaking change? Are we going to search back through all containers built after the last deployment?

[javanlacerda]

Yes! The project that will deploy it will be responsible for detecting it.

[javanlacerda]

Do you think we can merge it? @cpanato @haydentherapper

[haydentherapper]

Thanks for your work on this, this looks good! Just a couple small comments

@cpanato any remaining comments?

[haydentherapper]

Should this include git sha or git version?

[cpanato]

this when we release will be used, not sure if we want that format

[haydentherapper]

Do we need commit hash as a label? Looks like we include that as a tag already.

[cpanato]

if that does not hurt, it is an extra thing :)