Automatic release of tags from Travis to npm

[PowerKiKi]

Following this #91 (comment), it would be nice to have automatic release of tags from Travis to npm to reduce bus factor for this project.

Here is an example on how to automatically publish tags as release which should be easy to adapt for this lib. But I cannot create a PR for it since I don't know the credentials to be encoded: https://github.com/Ecodev/fab-speed-dial/blob/123e63c7faeef1d469618dcefb4a111d82fc817f/.travis.yml#L32-L47

So, to copy tag version into our package, package.json would look like:

{
  "scripts": {
    "postbuild": "node scripts/copy-artifacts.js && cd dist/ngx-avatar && git describe --tags --always | xargs npm version --no-git-tag-version",
  }
}

And for Travis to actually pusblish, .travis.yml would be similar to:

    - stage: publish npm package
      if: tag is present
      script:
        - npm run build
      before_deploy:
        - rm .gitignore
        - cd dist/ngx-avatar
      deploy:
        provider: npm
        edge: true
        email:
          secure: YOUR ENCRYPTED EMAIL HERE
        api_token:
          secure: YOUR ENCRYPTED API TOKEN HERE
        on:
          tags: true

[odahcam]

I think this is very important and with Reviews and Checks in Pull Requests we can rely in this automatic system to publish new package versions for us.

We can even go further and create a configuration for auto releasing dev versions of the repo, so users can test nightly builds and access new features before major release and before our intervention.

[PowerKiKi]

auto releasing dev versions

IMHO I wouldn't go that far. I feel it could be creating new expectations for users and more maintenance work in the build system for us. And I'd would rather spend our precious time on fixing bugs/adding useful features than maintaining something that might not be used by many people.

[odahcam]

I like the dev builds because they are free of responsability and they saved me many times when a user asked for something I couldn't get ready for a release and I just said "oh there's that build, probably buggy, but you can try it out, blah blah...", hehe. Build, tag and publish daily the develop branch is pretty easy I must say, but that's just and idea. I just wanna make clear that I support continuous deployment for the master branch and we should pursue that.

[HaithemMosbahi]

Hi @PowerKiKi @odahcam,
I was planning to do this and I believe now it's a must to avoid blocking this project in the future.
I like your suggestions, I will add one more thing: I believe we need to have good test coverage for the core features of the component before starting the auto release process.

[PowerKiKi]

There is two different approaches to auto release. First is to release every commit that pass tests entirely automatically. Second it that we, humans, decide whenever we feel like to create and push a tag, and then Travis release that tag.

I'm in favor of the second option, keeping humans in control of when the release happens. Mostly because I don't have experience with the first solution, and because keeping controls give us a chance to manually tests things before releasing. So that it is not an absolute requirement to wait for better test coverage (although test coverage is always a great thing of course).

Which alternative did you imagine ?

[odahcam]

I also prefer the second one, which can be easily achieved with GitHub Actions and the Releases from GitHub based on manual tagging. Auto-release would also have the challenge of auto-generating release tags. So second is easier and faster and will already help now.

[odahcam]

I have an workflow for publishing packages with Releases integration via GH Actions on this repo: https://github.com/zxing-js/text-encoding/blob/master/.github/workflows/npmpublish.yml

[PowerKiKi]

I have no experience with GitHub Action, so I'll leave it to you then. I suppose we would also move test from Travis to GitHub Action then ? That's fine by me.

I notice your Action is using yarn, not npm. I also prefer yarn and we could migrate this project to yarn, but it should be done properly (removing package-lock.json and updating angular.json). I can take care of that if you agree.

[odahcam]

I like yarn, so I do agree.

I suppose we would also move test from Travis to GitHub Action then

Actually we can let that tests running there too. The action will only run tests before publishing a package. But yes, we can move from Travis with no problems, but I do find Travis environment a little more robust for testing, so I wouldn't say we should move from it so soon.

I'm taking a little of my free time this week to relax a little, but I can implement the Action here in the next days. I'll prepare a PR.

[PowerKiKi]

@odahcam did you do something for automatic release ? I couldn't find anything in current code or PR.

[odahcam]

Sorry I did not implement anything here yet. But here's some example of how I'm doing in another repository: https://github.com/zxing-js/text-encoding/blob/master/.github/workflows/npmpublish.yml

Please ask me any questions about this config and I will answer ASAP!

[odahcam]

@HaithemMosbahi can you add the NPM required security key (auth token) for publishing on the repository and share it's name (usually NPM_TOKEN) in here?