pulsar-linter / linter-eslint-node

ESLint plugin for Atom/Pulsar Linter (v8 and above)
https://web.pulsar-edit.dev/packages/linter-eslint-node
MIT License
2 stars 0 forks source link

Pulsar Automated Release #7

Open scagood opened 1 year ago

scagood commented 1 year ago

Original issue: https://github.com/AtomLinter/linter-eslint-node/issues/43

We need to automate the publishing of releases to ppm. @confused-Techie made semantic-release-ppm.

We should look into using that.

confused-Techie commented 1 year ago

Since there's some interest around this repo now, I'll try to find some time to test this on my end as well, to get some of the kinks ironed out

scagood commented 1 year ago

🤔 Considering that https://github.com/AtomLinter/linter-eslint-node is now archived. Can we point pulsar-edit ~ linter-eslint-node to this repo?

Or does ppm support scoped packages? (I would make this @pulsar-linter/eslint)

confused-Techie commented 1 year ago

So we could go ahead and change where that package is pointing to. Since the backend does not currently support any scoped packages.

Really the hardest part would be figuring a secure way to do so.

scagood commented 1 year ago

Just looking at semantic-release-ppm src/publish.js:31

I assume we could use release-please, then on gh tag an action can just do something like:

curl -X POST -H "Authorization: $PULSAR_TOKEN "https://api.pulsar-edit.dev/api/packages/$PULSAR_NAME/versions"
confused-Techie commented 1 year ago

Just looking at semantic-release-ppm src/publish.js:31

I assume we could use release-please, then on gh tag an action can just do something like:

curl -X POST -H "Authorization: $PULSAR_TOKEN "https://api.pulsar-edit.dev/api/packages/$PULSAR_NAME/versions"

That very possibly could be the case. I'll be honest, testing more with my plugin gave me some issues, where the recommended code from semantic-releases docs don't work as expected and lead me down some rabbit holes. If we could have something as simple as that, then I'm more than happy to implement it instead.

Since really, under the new backend, very little needs to be done to publish a new release:

So I'll investigate release-please and see if we can make it work, as I'm rather unfamiliar with the project.

scagood commented 1 year ago

release-please makes a PR for the release.

Once that PR is merged it will:

  1. Make a change log for the release.
  2. Update the version in the package.
  3. Make a git tag
  4. Make a git release

From there we should just need to listen for the update and inform Pulsar of the change

This means something like this should work:

on:
  push:
    branches:
      - main
      - release-please
name: release-please
jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - id: release-please
        name: Make the Github Release and Tag
        uses: GoogleCloudPlatform/release-please-action@v3
        with:
          release-type: node

      - if: ${{ steps.release.outputs.release_created }}
        name: Inform Pulsar of the Release
        uses: actions/github-script@v6
        env:
          PULSAR_NAME: linter-eslint-node
          PULSAR_TOKEN: ${{ secrets.PULSAR_TOKEN }}
        with:
          script: |
            const { PULSAR_NAME, PULSAR_TOKEN } = process.env;
            await fetch(
              `https://api.pulsar-edit.dev/api/packages/${PULSAR_NAME}/versions`,
              {
                method: 'post',
                headers: { 'Authorization': PULSAR_TOKEN },
              },
            );