ci: better naming for various steps/jobs

[agilgur5]

Motivation

• partly inspired by ci: Improved readability of log of release actions #11670
  • as well as seeing users be confused by some steps
    • git diff --exit-code had some confusion in particular
  • and me just reading more closely and wanting better descriptions (as I am working on a few CI changes)
    • for example, I did not even realize that the steps after an E2E test failure were for debugging purposes until I read the CI code itself
      • GH runs some post action hooks etc, so thought that was just clean-up or something

Modifications

• add names to more steps & jobs in GH Actions Workflows

  • specific names for all git diff --exit-code as per above
  • names for Docs steps
  • names PR Title check steps
  • names for Snyk dependency scans workflow
  • CI workflow names:
    • all E2E test failure debugging steps per above
    • add a "get" (as in kubectl get) in front of the ones that just log out a resource for clarity as well
    • Java and Python SDK set-up/install steps
    • a few other clarifications / improvements
    • additions where there were no names

• also add some new lines and comments in a few places for clarity & readability

• reordering of fields

  • follow a consistent order of name -> if -> needs
  • then uses, steps, or run depending on the context

Verification

• Purely stylistic and DX changes, no semantic changes
• CI on this PR should pass with all the new names too 🙂

[agilgur5]

Ok top-level workflow names and job names don't look great when they're long. Gonna make some modifications...

Screenshot as an example for posterity:

[agilgur5]

Hmmm required checks evidently require the name to be exactly the same instead of the key 😕

See screenshot:

I'm going to revert the "Unit Tests" and "argoexec-image" name changes then, especially as those did not add altogether much

[Yaminyam]

Because the actions list is divided by the yaml file name, you should be aware that two actions with the same name may result in confusion.
I think it would be a good idea to delete the existing list when there are enough logs of newly changed docs actions and the old logs are no longer needed.

[agilgur5]

Because the actions list is divided by the yaml file name, you should be aware that two actions with the same name may result in confusion.

Well that's annoying and confusing 😕
To be fair though, I almost never use the Actions tab of the repo and normally just look at checks on commits and PRs.

I think it would be a good idea to delete the existing list when there are enough logs of newly changed docs actions and the old logs are no longer needed.

I don't know if this is actually possible 😐 This action hasn't been run in 10 months but still appears in the list.
If there is such a capability (idk), I don't have permissions to delete any of these unfortunately.

So not sure that we can actually do anything about this, it's a GitHub issue 😕

[Yaminyam]

That's right, this is a GitHub issue and discussions are continuing, but there is no response from GitHub.
https://github.com/orgs/community/discussions/26256

So the only way to delete the meaningless list from the workflow list is to delete all logs.
https://stackoverflow.com/questions/57927115/delete-a-workflow-from-github-actions/67000032#67000032

As shown in the photo above, github actions logs cannot be checked after 90 days anyway, so it is okay to delete all logs older than 90 days. I am using the script above to delete and manage logs that are no longer used due to changes in the yaml file.

[Yaminyam]

I often look at the actions tab, and the problem when the meaningless list becomes large is that you have to go in to check which of the workflows with the same name is currently in use.
When the number of workflows increases, it may be difficult to find a valid workflow because the workflows are sorted alphabetically.

[agilgur5]

So the only way to delete the meaningless list from the workflow list is to delete all logs.
https://stackoverflow.com/questions/57927115/delete-a-workflow-from-github-actions/67000032#67000032

I doubt I have permissions to do this, but maybe an Approver does.
These 2 actions can be pruned.

docs.yaml can't be pruned as it's the new file name here and the old gh-pages.yaml contains logs from everything other than this PR (future old logs)

[Yaminyam]

Even if a lot of logs are piled up, they cannot be accessed after 90 days or more, so I think it is okay to delete the existing logs because they become meaningless after 90 days after the 90-day pr is applied.
But ultimately, this is a matter for those in power to decide. :D

[agilgur5]

Even if a lot of logs are piled up, they cannot be accessed after 90 days or more

If this PR is merged, I would say it would be ok to delete gh-pages.yaml after 90 days (although PRs that are based on an old branch will still have it). The other 2 I linked above can be deleted already.
But I don't have permission to do this regardless

[terrytangyuan]

Please avoid unnecessary changes

[agilgur5]

Please avoid unnecessary changes

I would disagree that these are unnecessary. I had several iterations and trial-and-error testing on this, as can be seen in the commit log and first two comments.

It seemed like you mostly didn't like the reordering and may have misinterpreted those as removals?

Per my opening comment, that was a consistency change:

• reordering of fields
  • follow a consistent order of name -> if -> needs
  • then uses, steps, or run depending on the context

would be great if we had an automated formatter to sort fields in the same order, but I'm not sure that exists, so did so manually for now.
It's quite a bit easier on the eyes when they are consistent as opposed to all over the place, which makes it harder to follow and/or find the fields that I'm looking for. name first acts similarly to a comment, then if and needs are conditionals that say whether the rest is relevant (in code, the rest would be nested under these) or can be skipped.

Same as in-line comment

[agilgur5]

ah poop looks like this already ended up conflicting with #11782 (and another PR I think?). That was one of the reasons I asked for reviews over Slack as renames and reorderings can be really easy to conflict with 😭

[agilgur5]

Rebased and fixed merge conflicts! fingers crossed those are the last ones before this get merged 🤞

[terrytangyuan]

Build failed

[agilgur5]

Yea docs just timed out on checkout. That's happened a few times recently in CI actually. It's a known issue on GH Actions (and is actually the primary purpose of the retry action).
The other one is a test failure that I've actually never seen before (TestJSONVariables).

But my changes don't affect either of those, so those are flakes in context. I can do an empty commit but I was hoping you could retry those @terrytangyuan

[agilgur5]

one of the flakey hooks tests is failing now 😕