Skip to content

feat: Add reusable scorecards-analysis-reusable.yml workflow#700

Merged
ppkarwasz merged 2 commits into
masterfrom
feat/scorecards-reusable
May 12, 2026
Merged

feat: Add reusable scorecards-analysis-reusable.yml workflow#700
ppkarwasz merged 2 commits into
masterfrom
feat/scorecards-reusable

Conversation

@ppkarwasz
Copy link
Copy Markdown
Member

Similar to #699, adds a reusable Scorecard analysis workflow and refactors scorecards-analysis.yml to call it.

Unlike the CodeQL workflow, which only relies on actions from GitHub-owned organisations (github and actions), this one uses a third-party action (ossf/scorecard-action) that needs to be upgraded in a timely manner. The usual process is:

  1. A new version of the action is released.
  2. The action is reviewed in infrastructure-actions and the new SHA is added to the authorized ones.
  3. The old SHA is scheduled for removal.

We need to perform the upgrade between steps 2 and 3, so we should configure Dependabot to bump this action weekly with a 7-day cooldown (step 2 occurs within 7 days of a new release).

Similar to #699, adds a reusable Scorecard analysis workflow and
refactors `scorecards-analysis.yml` to call it.

Unlike the CodeQL workflow, which only relies on actions from
GitHub-owned organisations (`github` and `actions`), this one uses a
third-party action (`ossf/scorecard-action`) that needs to be upgraded
in a timely manner. The usual process is:

1. A new version of the action is released.
2. The action is reviewed in `infrastructure-actions` and the new SHA
   is added to the authorized ones.
3. The old SHA is scheduled for removal.

We need to perform the upgrade between steps 2 and 3, so we should
configure Dependabot to bump this action weekly with a 7-day cooldown
(step 2 occurs within 7 days of a new release).
@garydgregory
Copy link
Copy Markdown
Member

Same answer as the other PR: Please, no.

I am not a fan of this style of GitHub usage (see Log4j's impossible to understand for a mere mortal set up). I don't want have to be, or other maintainers to become GHA experts. This usage would force a hierarchical set up for builds at the GHA level, and I see the complexity as outweighing any value.

@ppkarwasz
Copy link
Copy Markdown
Member Author

If this reassures you, I can keep track of the codeql-analysis, scorecards-analysis and dependency-review analysis failures and act on them.

In recent history I only found a couple of CodeQL failures that were due to committing Java code that does not compile, nothing that needs tinkering nor modification of the workflow.

@garydgregory
Copy link
Copy Markdown
Member

I am sorry, but It doesn't reasure me at all. This makes the build more complilcated and harder to maintain. -1.

@ppkarwasz
Copy link
Copy Markdown
Member Author

As discussed in #699, I will merge this and test it in Collections only.

@ppkarwasz ppkarwasz merged commit 8e38ea1 into master May 12, 2026
15 checks passed
@ppkarwasz ppkarwasz deleted the feat/scorecards-reusable branch May 12, 2026 22:35
@garydgregory
Copy link
Copy Markdown
Member

I hope this goes no further, as I've complained before, the extra complication and level of indirection adds no value IMO.

@ppkarwasz
Copy link
Copy Markdown
Member Author

It should become easier in time: when apache/infrastructure-asfyaml#94 is implemented, we will no longer need to run CodeQL explicitly, but we'll use whatever “default” configuration GitHub provides.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants