🐛 [bug]: using v1 gives node16 deprecation warnings

[joernott]

🐛 What happened?

We start seeing deprecation warnings aboud node16 when using raven-actions/actionlint@v1:

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/cache@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

🔬 How to reproduce?

Call actionlint action

🏗️ Code Sample / Log

[...]
  actionlint:
    needs: ['init', 'begin_report_phase']
    if: ${{ always() && needs.init.outputs.actionlint_skip != 'true' }}
    runs-on: ${{ fromJSON(inputs.runs_on) }}
    steps:
      - name: Install npm on private runner
        if: ${{ inputs.runs_on != '"ubuntu-latest"'}}
        run: |
          NPM=$(type -p 'npm'||true)
          if [ -z "${NPM}" ]; then
            echo -e "\033[0;35m###  Installing npm ###\033[0m"
            sudo DEBIAN_FRONTEND=noninteractive apt-get -qq update
            sudo apt-get -qq install npm
          fi

      - name: Checkout
        id: checkout
        uses: actions/checkout@v4

      - name: Run actionlint
        id: actionlint
        uses: raven-actions/actionlint@v1

🌌 Environment (actionlint action)

1.0.3

🌌 Environment (actionlint)

1.6.26-Linux-X64

🌌 Environment (GitHub Runner OS)

Linux

📷 Screenshots

No response

📈 Expected behavior

actions/cache is upgraded to v4 to remove the warning

📎 Additional context

No response

📜 Code of Conduct

• I agree to follow this project's Code of Conduct.

[mvanduijker]

It should have been fixed with this #20
We have to wait for a new release.

[DariuszPorowski]

Will review, bump deps, test and release new one around end of 1st week of March.

[mvanduijker]

any way I can help to get this released?

[pakosak]

any update on the release @DariuszPorowski ?

[DariuszPorowski]

@mvanduijker @pakosak currently this PR is a blocker: #22
After will solve it, then breaking change (v2 release) will happen with switch to node20

[kxc171]

@DariuszPorowski - Any plans to still cutover a v2 tag for this yet (or update the existing v1 tag)? This would be really nice to address since at this point GH has started forcing Node20 as on June 3rd. https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/

[DariuszPorowski]

@kxc171 done :) v2 released :)

[rindeal]

@DariuszPorowski Great, but this time around could you use tags only for specific versions like 2.0.0 and branches for v2, v3, ...? This will make hotfixes like node16 -> node20 much easier.

[DariuszPorowski]

@rindeal, thanks for the suggestion. I started thinking to skip any major tags at all and do only semver, going further looking for GitHub feature like github/roadmap#592

[rindeal]

@DariuszPorowski

I started thinking to skip any major tags at all and do only semver, going further looking for GitHub feature like github/roadmap#592

Just doing semver tags and no v2, ... branches would prevent anyone from automatically receiving hotfixes.

The new feature you mentioned is 2 years old, has been rescheduled twice and currently has no ETA set. So we have at least a good year and likely more before it starts rolling out. Also we don't know whether it will have or not an autoupdate feature like the v2 branches. Until then, I think there are many users who trust you and would appreciate having the convenience of a v2 branch with fixes automagically applied, just like in the official actions/*.

[joernott]

I'm not too fond of the idea of a v2 branch and rather stick with moving a v2 tag (and a v2.x tag) on the main branch when doing a release. Of course, that can be automated by using GitHub actions. I have one action that creates a release___patch branch and a PR assigned to someone to review. Once, that is done and the branch is merged, another action does the tagging and release.

[rindeal]

I'm not too fond of the idea of a v2 branch and rather stick with moving a v2 tag (and a v2.x tag) on the main branch when doing a release. Of course, that can be automated by using GitHub actions. I have one action that creates a release___patch branch and a PR assigned to someone to review. Once, that is done and the branch is merged, another action does the tagging and release.

The complexity you just described is exactly what one gets when abusing the Git tag feature in such an attempt to mimic a branch. Git tags are intended to be created once, then signed and sealed forever. If you're looking for moving Git references, branches are the feature that fits the bill. Git 101. 🙄

[kxc171]

Chiming in, while I do like the idea of leaning into immutable versions, there are benefits to having "fuzzy" versions available for fixes and security issues. While it does open the possibility for someone malicious to update a vX tag (since they are NOT immutable), this can be prevented by pinning to full commit SHA's, which is a common practice and something a lot of tooling (eg: Renovate) support updating.

This gives the best of both worlds by allowing users to pin to a known version (SHA) or continue to use a vX tag to continue getting updates.

Below is an example Workflow that could be used to easily create vX and vX.Y tags from a full vX.Y.Z version, which can easily be made at your own cadence using the GitHub Releases page (or just pushing it yourself haha). This won't work if you use branch/tag protection rules (you'd need to use your own PAT).

release.yaml

name: Release Action

on:
  push:
    tags:
      - 'v[0-9]+.[0-9]+.[0-9]+'

permissions:
  contents: write

jobs:
  release:
    name: Release action
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        id: checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # fetch all tags

      - name: Push version tags
        id: tags
        run: |
          MAJOR=$(echo "$GITHUB_REF_NAME" | cut -d . -f 1)
          MINOR=$(echo "$GITHUB_REF_NAME" | cut -d . -f 2)
          PATCH=$(echo "$GITHUB_REF_NAME" | cut -d . -f 3)

          git tag -f "$MAJOR" "$GITHUB_SHA"
          git tag -f "$MAJOR.$MINOR" "$GITHUB_SHA"
          git tag -f "$MAJOR.$MINOR.$PATCH" "$GITHUB_SHA"
          git push -f -u origin "$MAJOR"
          git push -f -u origin "$MAJOR.$MINOR"
          git push -f -u origin "$MAJOR.$MINOR.$PATCH"

          git show-ref --tags | grep "$GITHUB_SHA"

[rindeal]

Much security! Very force push! Wow.

[kxc171]

Much security! Very force push! Wow.

Unfortunately force pushing tags like that would be necessary in order to actually update existing tags.

That's one of the reasons GitHub (and others) recommend pinning to full length commit SHAs for Actions instead because it does prevent the possibility of a tag to be updated unknowingly. If security is your concern, you should be pinning to SHAs.

I don't think that should be the end-all-be-all solution to this though as not everyone needs to have that level of security and there are pros and cons to both approaches.

[rindeal]

Unfortunately force pushing tags like that would be necessary in order to actually update existing tags.

name: Release Action

on:
  push:
    tags:
      - 'v[0-9]+.[0-9]+.[0-9]+'

permissions:
  contents: write

jobs:
  release:
    name: Release action
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@HEAD
        with:
          fetch-depth: 0 # fetch all history

      - name: Create, update, and verify version branches
        run: |
          IFS='.' read -r MAJOR MINOR PATCH <<< "${GITHUB_REF_NAME}"

          for VERSION in "$MAJOR" "$MAJOR.$MINOR"; do
            echo "Processing version: $VERSION"
            git checkout -B "$VERSION" "$GITHUB_SHA"
            git push -u origin "$VERSION"
            
            if git branch -r | grep -q "origin/$VERSION"; then
              echo "Branch $VERSION created/updated and verified"
            else
              echo "Failed to create/update branch $VERSION"
              exit 1
            fi
          done

That's one of the reasons GitHub (and others) recommend pinning to full length commit SHAs for Actions instead because it does prevent the possibility of a tag to be updated unknowingly. If security is your concern, you should be pinning to SHAs.

I don't think that should be the end-all-be-all solution to this though as not everyone needs to have that level of security and there are pros and cons to both approaches.

Everyone knows. This discussion was about options for those not using SHAs. Specifically:

1. Whether to implement version branches
2. If implemented, whether to use tags or branches

As @DariuszPorowski noted, the GitHub team is planning to overhaul the Actions distribution to enforce immutable semver refs like in the npm registry. In the interim, we're limited to choosing between mutable git refs or hardcoded SHAs.

Anyway, this thread went off-topic and is now just beating a dead horse, perhaps it's time to lock it @DariuszPorowski?