Consider auto-publishing workflow for every PR

[arboleya]

Problem

Currently, we can have auto-publishing tags for the PRs we chose using this flag:

fuels-ts/.github/workflows/pr-release.yaml

Line 11 in 5daeea4

# if: false

This is manual and error-prone; one must always turn it on and off.

Another problem is that published tags are left behind; the registry is massive.

click to see screenshot

Solution

We should consider cleaning this up and automating this workflow.

One idea is to turn on auto-publishing for every PR automatically.

• Every PR gets an auto-publishing tag that lasts for its lifetime and auto-updates on each commit
• After the PR is merged or deleted, all published tags for that PR are deleted from the registry

[petertonysmith94]

We're unable to unpublish our published package versions automatically with ease (less than 72 hours published) due to our package hierarchy (which was tested in #2377).

This could be alleviated if we migrate to using a single fuels package:

• Consider merging all packages into fuels #2493

Marking as blocked until we are able to unpublish NPM package versions and should be revisited after:

• Consider merging all packages into fuels #2493
• Unpublish NPM versions #2377

[arboleya]

IIUC and this won't be possible, perhaps we could close this issue.

[petertonysmith94]

IIUC and this won't be possible, perhaps we could close this issue.

I think it might be possible after:

• Consider merging all packages into fuels #2493

[arboleya]

Considering we can't unpublish versions, I wonder if we should go the simple way and run our installation checks on existent tags, like the next tag (before release) or latest (after release).

[petertonysmith94]

Considering we can't unpublish versions, I wonder if we should go the simple way and run our installation checks on existent tags, like the next tag (before release) or latest (after release).

That does seem reasonable - I'd be good if we could test out the functionality before we go into release. Maybe there is a way to test out the functionality locally.

Would we deprecate fuels-ts/.github/workflows/pr-release.yaml?

[arboleya]

I don't think so, or not necessarily.

The ability to publish PRs in isolation is handy.

[petertonysmith94]

I don't think so, or not necessarily.

The ability to publish PRs in isolation is handy.

Wonderful!

IMO - the following workflow doesn't work well:

fuels-ts/.github/workflows/pr-release.yaml

Lines 10 to 11 in 5daeea4

	# comment out if:false to enable release PR to npm
	# if: false

I believe a more manual approach, using the workflow_dispatch event might alleviate some of the issues we have. This could do away with the requirement of toggling the # if: false in a commit.

[arboleya]

I agree, but are we still in the scope of this issue? 🙂

Otherwise, could we close this and perhaps create a new one based on your suggestion?