Remove path parts from component label suffixes

[evan-bradley]

Component(s)

No response

Is your feature request related to a problem? Please describe.

In our "create component labels" script we have a few components that are just barely over GitHub's 50 character limit for labels. From a recent workflow run:

'extension/encoding/awscloudwatchmetricstreamsencoding' exceeds GitHubs 50-character limit on labels, skipping
'receiver/hostmetrics/internal/scraper/filesystemscraper' exceeds GitHubs 50-character limit on labels, skipping
'receiver/hostmetrics/internal/scraper/memoryscraper' exceeds GitHubs 50-character limit on labels, skipping
'receiver/hostmetrics/internal/scraper/networkscraper' exceeds GitHubs 50-character limit on labels, skipping
'receiver/hostmetrics/internal/scraper/pagingscraper' exceeds GitHubs 50-character limit on labels, skipping
'receiver/hostmetrics/internal/scraper/processesscraper' exceeds GitHubs 50-character limit on labels, skipping
'receiver/hostmetrics/internal/scraper/processscraper' exceeds GitHubs 50-character limit on labels, skipping
'receiver/hostmetrics/internal/scraper/systemscraper' exceeds GitHubs 50-character limit on labels, skipping

Describe the solution you'd like

For each of these, there are suffixes in the last part of the path that can be removed since the suffix is already present in the path and therefore it's clear what type of component it is.

So extension/encoding/awscloudwatchmetricstreamsencoding could become extension/encoding/awscloudwatchmetricstreams and receiver/hostmetrics/internal/scraper/filesystemscraper could become receiver/hostmetrics/internal/scraper/filesystem.

This would get us under the 50-character limit for now and wouldn't require too many changes to how the script operates.

Describe alternatives you've considered

Support a field in mdatagen that allows us to manually shorten these, then generate the authoritative list of labels from mdatagen. The 50-character limit could be enforced during the generation step.

Additional context

No response

[evan-bradley]

I came up with the following process to generate shorter label names. All components would have labels under the 50-character limit if we applied this.

LABEL_NAME=$(echo "${COMPONENT}" | sed -E 's%^(.+)/(.+)\1%\1/\2%')
OIFS=${IFS}

IFS='/'
for SEGMENT in ${COMPONENT}
do
    # If a component is named pkg/mypackage and the segment is mypackage, it will always match. Skip the last part of the path.
    r="/${SEGMENT}\$"
    if [[ "${COMPONENT}" =~ ${r} ]]; then
        break
    fi
    LABEL_NAME=$(echo "${LABEL_NAME}" | sed -E "s%^(.+)${SEGMENT}\$%\1%")
done

IFS=${OIFS}

if (( "${#LABEL_NAME}" > 50 )); then
    echo "'${LABEL_NAME}' exceeds GitHubs 50-character limit on labels, skipping"
    continue
fi

However, while this handles the path --> label conversion, we need something afterward that can do label --> path, which is much harder since our path names have inconsistencies that make it basically impossible to determine which parts of the path were removed from the label.

I think our best bet will be to change label generation from an on-demand process to something that is generated and checked in to the repo. If we have a file that contains each path and its corresponding label on each line, we could do a lookup when converting in either direction.

[PhilemonBrain]

@evan-bradley, I am new to Go but confident I can give this a good shot. Can I get it assigned to me?

[PhilemonBrain]

/assign

[evan-bradley]

Sure thing @PhilemonBrain. This will almost entirely consist of working in Bash/GitHub Actions/Makefiles, so no Go knowledge is necessary. 🙂

You'll want to take a look at the following:

1. Adding a target to the Makefile at the root of the repo that converts the paths in the .github/CODEOWNERS file to space-delimited text file, probably somewhere in the .github directory.
2. Adding a check to our build-and-test workflow in .github/workflows to the checks job that verifies this list is up-to-date, similar to checking for Go mod dependency changes or make gendistributions
3. Updating all workflows that deal with component labels to use this list for lookups.

Thanks in advance for looking at this!

[PhilemonBrain]

I would love to work on this, however, I sincerely think this might be a bit too much for me 🥲. Thanks @evan-bradley. I would pick another issue

[evan-bradley]

No problem, thanks for your interest!

[gabgg71]

@evan-bradley I would love to work on this. Could you please assign it to me?

[evan-bradley]

Can do. Thanks for looking into it!

[axw]

Thanks for fixing this @gabgg71!