Use latest GitHub actions

probonopd commented 3 months ago

Use latest GitHub actions to prevent from this

probonopd commented 3 months ago

Argh...

Error: Unable to resolve action actions/checkout@latest, unable to find version latest. Unable to resolve action actions/upload-artifact@latest, unable to find version latest

Is there a way to always use supported versions of these actions without having to keep track of them manually?

TheAssassin commented 3 months ago

Is there a way to always use supported versions of these actions without having to keep track of them manually?

There are tools to automate this, e.g., Renovate, Dependabot (the latter of which is included in GitHub, I think).

probonopd commented 3 months ago

Why can't anything be simple. Like, included GitHub Actions that just do their job without nagging to be manually updated. Oh well, maybe I should open a feature request with GitHub to support @latest.

TheAssassin commented 3 months ago

Well, technically you can point to the branch, too. "latest" is not an identifier known to GitHub or the repository. The question is, do you really want this? I wouldn't. You need to update those things every couple of years. Dependabot generates a PR, you just need to click merge. That's very much acceptable to me personally.

probonopd commented 3 months ago

I am just annoyed by the many messages they are showing in the GUI (above). And I am way too lazy to look up the latest release for each of their actions all of the time in the hundreds(!) of my repositories. This gets tedious rapidly.

I would like to have these things completely maintenance free, never having to worry about them again. (Ideally they would never change this basic stuff, but apparently they do.)

Apparently they run whatever version they want anyway, showing you these ugly warnings. I want them to just run whatever version but without the warnings.

Things like Dependabot are additional dependencies (and hence, complexities) themselves, and afaik also need someone to merge their pull requests manually.

you can point to the branch, too

@main "works", but possibly they have changed something there. Why are we getting now for i686:

Run actions/upload-artifact@main
With the provided path, there will be 4 files uploaded
Artifact name is valid!
Root directory input is valid!
Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (40[9](https://github.com/AppImage/type2-runtime/actions/runs/10265962033/job/28403264114#step:7:10)) Conflict: an artifact with this name already exists on the workflow run

One could argue that things like this are the reason why one doesn't want to use @main, and indeed, I would like to use the latest released version, but I don't feel like updating that in my hundreds of repos all the time.

Reference:

https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#example-using-versioned-actions

andy5995 commented 1 month ago

Things like Dependabot are additional dependencies (and hence, complexities) themselves, and afaik also need someone to merge their pull requests manually.

Yes, but it's not too bad. checkout doesn't have major version changes very often, for example. Let me know if you'd like me open a PR with a dependabot.yml file and we can try that for a while. Or you can just steal this one. I'm not sure the 'docker' section is needed though.

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file

probonopd commented 1 month ago

Well. I have hundreds of repositories, many of which suffer from this issue. So I am looking for a zero-maintenance solution in which I don't have to keep track of or have to update GitHub Actions versions.

andy5995 commented 1 month ago

That would certainly be awesome. I asked ChatGPT about it:

Yes, it’s possible to create a GitHub workflow that triggers when a pull request (PR) is opened and searches for specific changes, such as modifications to the actions/checkout action in YAML workflow files. You can implement this using a combination of GitHub Actions events, pull_request triggers, and GitHub's API or some scripting logic to detect changes.

Here’s a high-level approach:

Steps for the Workflow:

Trigger on PR Opening or Synchronization: Set up the workflow to trigger when a pull request is opened or updated.
Check for YAML File Changes: Inspect the files changed in the pull request. You’ll want to check whether any .yml files in the .github/workflows/ directory have been modified.
Search for actions/checkout: If YAML files have been changed, parse the diff or the full content to see if actions/checkout has been added, removed, or modified.
Auto-Merge Logic: If the PR only modifies the actions/checkout text and all status checks have passed, use GitHub's API to automatically merge the pull request.

Workflow Example

Here’s an outline of how you could set this up in a GitHub Actions workflow YAML file:

name: PR Workflow Monitor

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-pr:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Check for workflow changes
        id: check_files
        run: |
          # Find changes to workflow files
          git diff --name-only origin/main..HEAD | grep '\.github/workflows/.*\.yml' || echo "no-changes" > no-changes.txt
          if [ -f no-changes.txt ]; then
            echo "No workflow changes found"
            exit 0
          fi

      - name: Search for 'actions/checkout'
        if: steps.check_files.outputs.changes_detected == 'true'
        run: |
          # Search for actions/checkout in the diff of the workflow files
          if git diff origin/main..HEAD | grep 'actions/checkout'; then
            echo "actions/checkout change detected"
            echo "actions_checkout=true" >> $GITHUB_ENV
          else
            echo "actions_checkout=false" >> $GITHUB_ENV
          fi

  auto-merge:
    needs: check-pr
    runs-on: ubuntu-latest
    if: env.actions_checkout == 'true' && github.event.pull_request.head.repo.default_branch == 'main'
    steps:
      - name: Merge the PR
        uses: peter-evans/enable-pull-request-automerge@v2
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          pull-request-number: ${{ github.event.pull_request.number }}

Explanation:

Trigger on Pull Requests: The workflow starts when a PR is opened or synchronized.
Check for Workflow Changes: The git diff command checks for changes in the .github/workflows/ directory. If no workflow files are modified, the workflow exits.
Search for actions/checkout: The git diff output is searched for the string actions/checkout. If it's found, a flag is set in the environment.
Auto-Merge Logic: The second job depends on the first job and runs only if actions/checkout was detected. The peter-evans/enable-pull-request-automerge action enables auto-merge for the PR if all conditions are satisfied.

Auto-Merge Condition

You can modify the auto-merge condition to ensure that it only happens if all required status checks are passing. If your repository requires status checks (e.g., tests, linting), they will need to pass before GitHub will auto-merge the PR.

Alternative: Custom Script

Instead of using git diff, you could also write a custom script in Python or Node.js to inspect the changes more thoroughly and make the decision programmatically.

This workflow should give you the basic framework to implement this feature.

andy5995 commented 1 month ago

Updated Workflow Example:

      - name: Check if the PR was opened by Dependabot
        id: dependabot_check
        run: |
          if [ "${{ github.actor }}" == "dependabot[bot]" ]; then
            echo "PR was opened by Dependabot"
            echo "dependabot=true" >> $GITHUB_ENV
          else
            echo "PR was not opened by Dependabot"
            echo "dependabot=false" >> $GITHUB_ENV
          fi

probonopd commented 1 month ago

I do appreciate AI generated ideas, but only once they have been verified by a human to actually work ;-)

andy5995 commented 1 month ago

I do appreciate AI generated ideas, but only once they have been verified by a human to actually work ;-)

On the peter-evans/enable-pull-request-automerge repo (used in the workflow example above), there's an example for using it with dependabot pull requests, so I assume this has been verified by at least one human, and maybe used by others.

https://github.com/peter-evans/enable-pull-request-automerge?tab=readme-ov-file#dependabot-example

Though it does state at the top of the README that "The same functionality exists in the GitHub CLI" along with some details.

AppImage / type2-runtime