github actions to make tar files for releases of automatic-actions

[sbe-arg]

makes a release just for automatic-actions with the tar files required to open prs in https://github.com/marvinpinto/action-automatic-releases

[Enase]

No reason to define tags-ignore node

If you define only tags/tags-ignore or only branches/branches-ignore, the workflow won't run for events affecting the undefined Git ref. If you define neither tags/tags-ignore or branches/branches-ignore, the workflow will run for events affecting either branches or tags.

documentation link

[Enase]

Before creating a release, it's important to ensure that the tag doesn't already exist. Otherwise, the automatic-releases plugin will overwrite the tag and delete the previous release.

Option 1 - Check for Tag:

      - name: Check for Tag
        run: |
          TAG="our release version goes here"
          if git show-ref --tags --verify --quiet "refs/tags/${TAG}"; then
            echo "Tag ${TAG} exists"
            exit 1
          else
            echo "Tag ${TAG} does not exist"
          fi

Option 2 - Use different approach (see next comment)

[Enase]

I have identified a few drawbacks to this release process concept:

• It requires the developer to manually check and update the current released version.
• There is a possibility of accidentally adding an empty line at the end of a file, which can cause the workflow to fail.

Regardless of the decision made regarding these issues, it would be beneficial to create a RELEASE.md file and provide detailed information about the release process.

Proposal:
Retrieve the most recent tag version and utilize the semver to increment the release version based on the release type, which can be one of 'patch', 'minor', or 'major'. This incremented version will then be used as the destination release version.

Code sample:

      - run: npm i semver
      - name: "Define release version"
        uses: actions/github-script@v6
        env:
          RELEASE_TYPE: 'patch'
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const semver = require('semver')
            const { RELEASE_TYPE } = process.env
            const owner = context.repo.owner
            const repo = context.repo.repo  # Warning: in our case it should be different repo as I know

            const tagsRaw = await github.graphql(`
              query lastTags ($owner: String!, $repo: String!) {
                repository (owner: $owner, name: $repo) {
                  refs(first: 2, refPrefix: "refs/tags/", orderBy: { field: TAG_COMMIT_DATE, direction: DESC }) {
                    nodes {
                      name
                      target {
                        oid
                      }
                    }
                  }
                }
              }
            `, {
              owner,
              repo
            })

            const latestTag = tagsRaw.repository.refs.nodes[0]
            if (!latestTag) {
              return core.setFailed('Unable to locate the latest tag. Please ensure that you have an existing tag in place before attempting to create a new one.')
            }
            core.info(`Using latest tag: ${latestTag.name}`)
            if (semver.valid(latestTag.name) === null) {
              return core.setFailed(`Invalid latest tag: "${latestTag.name}"`)
            }

            if (!['patch','minor','major'].includes(RELEASE_TYPE)) {
              return core.setFailed(`Invalid release type: "${RELEASE_TYPE}"`)
            }
            const newVersion = semver.inc(latestTag.name, RELEASE_TYPE)
            core.info(`Using new tag: ${newVersion}`)
            if (semver.valid(newVersion) === null) {
              return core.setFailed(`Invalid new tag: "${newVersion}"`)
            }
            core.exportVariable('PREVIOUS_VERSION', latestTag.name)
            core.exportVariable('RELEASE_VERSION', `v${newVersion}`)

[Enase]

Just run: yarn run lintfix:eslint and yarn run lintfix:prettier from repo root in order to fix CI issues

[sbe-arg]

@Enase mi energy and motivation to fix this is low.
we either disable commit linting entirely or I won't do further testing on this.

Too much wiggle around.
This structure was poorly designed. where once you merge a PR future checks fail.
The CI should block merging a PR with the wrong commit message or should have autofixed commit messages so linting does not break after each pr.

Ill leave it with you.
You can open a fresh pr with the changes you consider Ill just approve your prs.

I have moved most of my repos to this action I made this week https://github.com/marketplace/actions/simple-tags-and-releases its 20 lines of code and does not require much support.
Offers the minimal functionality I need with uploading single files and passing and creating tags from a source file.