Package publish workflow

[laudibert]

This is a proposition to add automatic package publish on master as well as a publish dry run on PRs.

I modified the validation workflow to add a follow-up job on it that will publish the package. It will fail if the version given has already been published. It will also only do a dry un on PRs.

The job requires NPM_TOKEN to be added as a secret on this repository.

I am aware that this may be up to debate, will be happy to do so.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: laudibert
To complete the pull request process, please assign drubin after the PR has been reviewed.
You can assign the PR to them by writing /assign @drubin in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[brendandburns]

I'm not sure that I'm in favor of automatic publishing of npms on push. I think publishing should be an intentional act.

I guess you could argue that rev-ing the version in package.json is intentional, but I like an explicit action to be taken.

Regardless, it also doesn't match up with the existing way that we use the version in package.json which is that the checked in version is always the next version, so this would end up with us publishing a new version before we were ready.

Additionally, we need to run a build (e.g. compile typescript to javascript) before we publish, I don't think your current workflow does this.

If you are open to it, can you refactor this as follows:

1. Don't delete test.yaml, leave it as-is, you can add the dry-run publish here if you want, though I'm not sure it adds much.
2. Add ci.yaml but set it as a workflow_dispatch so that it can be manually triggered.
3. [optional] figure out the right way to have a snapshot library on npm. I'm not sure the right approach, we could use semantic versioning (e.g. alpha1).

[laudibert]

Yes ok, understood. Yes I think that step 3 is important. I honestly got motivated to do this PR because I am waiting for my merged PR to be published on a version that I can use. Therefore I do think it is important to have some way to give a alpha/release candidate/snapshot version.

I'll look into it in the next few days.

[brendandburns]

In the meantime, would it be useful for me to cut a new version to pick up your PR? (which PR is it)

[laudibert]

That would be very nice, thank you. It's PR #753

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.