Publish/Update NPM packages with GitHub Actions

Ever had an NPM package that never get’s updated even though you make changes from time to time. I do! It’s time to make my life just slightly easier and automate the publish / update step with Github Actions.

Since the release of GitHub Actions several people I know have been raving about how good they are, so In an attempt to learn a little bit, and solve a problem I have, I thought I could try it out 🤓

Oh and here’s the official GitHub Actions docs: [GH Actions Docs]

Goal

It’s important to know what you want to do, before starting configuring (or… doing anything, really!). For me it’s going to be something quite simple, but very useful.

This is my starting point and what I want to achieve:

1. I have an open source package which is published to NPM
2. → NPM: react-native-value-picker
3. → Github: ugglr/react-native-value-picker
4. When I publish a new release on Github I want to update / re-publish this package to NPM, so my updates go live.

To do this manually we need to login in and publish/re-publish through the NPM CLI, something like this:

## Authenticating with npm
$ npm login

## Publish the package
$ npm publish

I know, I know, it’s not a massive amount of work to do those two steps each time I want to push out an update to the package, but we are learning something here as well 🚀

Prior to GitHub Actions in order to automate this task, I would have needed to involve a third party CI/CD solution, and on top, it’s free.

So let’s get started with the config.

Preparing our repo

The execution chains or jobs which we want to run inside of our GitHub Actions are called workflows.

So GitHub will look inside .github/workflows for workflows / execution chains so let’s make a .github folder inside of our root, this folder is commonly used if there are special configurations to the repository, like code owners. Further we need to make a folder inside our .github folder called workflows.

TLDR: When all is done you’ll have a a root/.github/workflows folder.

Like most CI/CD solutions GitHub Actions workflows are configured using a .yml file, and we need to put that that file into the workflow folder we created above. I named my yml-file npm-publish.yml and here’s a badly made folder-tree to make it more clear.

--> root
   |--> .github
      |--> workflows
         |--> npm-publish.yml // contains our workflow.
   |--> rest of app

#github #programming #javascript #react #software-development

What is GEEK

Buddha Community

Publish JS Package to NPM or Github

https://www.youtube.com/playlist?list=PLT5Jhb7lgSBOnwyukLUZb6X-WnliySCUL

#github #publish js packag #js package #npm

How to Set Up GitHub Actions to Publish a Monorepo to NPM

In my last post, I showed you how to create, test, and build a monorepo repository. In this article, I will show you how to automate the publishing of your monorepo to NPM using GitHub Actions.

What are GitHub Actions?

GitHub Actions allow for automating workflows based on repository events such as push, issue creation, or the creation of a new release.

Workflows are composed of jobs, which run concurrently by default. Each job should represent a separate part of your workflow described using steps.

For the propose of this article, we will have one job that will describe what steps must be followed to publish our package.

#publishing #github-actions #javascript #monorepo #npm

Publish NuGet Packages Using GitHub Actions

Unbelievable! One of the oldest NetLicensing Client libraries for C# (with the first GitHub push made on Oct 2, 2013) was not available in one of the essential package managers for .NET

Better late than never — so we decided to change this status quo, and today want to share with you our this walkthrough on how we published NetLicensing C## Client library to NuGet repository using GitHub Actions.

Background Info — GitHub Flow

Before moving forward, just a note about GitHub Flow workflow adopted for Labs64 projects hosted at GitHub.

“Pull Request” or “PR” is a very useful feature of the GitHub version control system and allowing efficient feature and bugfix development with the GitHub Flow.

The below diagram showing GitHub Flow adopted for Labs64 projects:

Any new feature or defect fix implementation is being done only in a dedicated feature branch. When branch implementation is ready to be integrated into the master branch, a Pull Request gets created. Using this PR, team members, working on a particular feature/enhancement/bug fix, can get feedback from other team members along the way.

This feedback is being used to make further changes and commits to the branch before finally merging the changes back up to the 'master' branch.

For the above GitHub Flow following workflows will be defined:

• CI — build and test push commits at Pull Request branches and master
• Release — package and publish C## library after successful CI run on 'master'

#tutorial #devops #c# #github #csharp #nuget #continious integration #github actions #nuget packages

How to Create a Custom GitHub Actions Using JavaScript — Beginner Level

In this blog, we are going to learn how to create our own custom GitHub action using javaScript.

Prerequisite

• Basic JavaScript Knowledge
• Basic Git & GitHub Knowledge

About GitHub Actions

Automate, customize, and execute your software development workflows right in your repository with GitHub Actions. You can discover, create, and share actions to perform any job you’d like, including CI/CD, and combine actions in a completely customized workflow.

Types of Actions

There are three types of actions: Docker container actions, JavaScript actions, and composite run steps actions.

JavaScript Custom Action

Let’s create a Custom GitHub Action using JavaScript by creating a public repo, once the repo is created, we can clone it to our local machine using VS Code or GitPod. You need to have Node.js 12.x or higher and npm installed on your machine to perform the steps described here. You can verify the node and npm versions with the following commands in a VS Code or GitPod terminal.

node --version 
npm --version

#github #github-tutorial #github-actions #github-trend

GitHub Actions to Securely Publish NPM Packages

GitHub Actions are growing in popularity ever since GitHub announced general availability for all developers and repositories on the GitHub platform. Fueled with some rate limits we’re seeing in the ecosystem—such as new billing and rate limits for open source from Travis CI—will further drive developers to migrate their software automations to GitHub Actions.

In this article, I’d like to show you how I’m using GitHub Actions to publish npm packages that I maintain in my open source projects. If you’re following the GitHub flow which consists of GitHub pull requests workflows, then this will further unify your experience around GitHub workflows for your teams and community contributors in your project.

What is GitHub Actions?

GitHub Actions is a technology developed by GitHub to provide developers with a way to automate their workflows around continuous integration—helping them build, deploy, schedule recurring tasks, and more. GitHub Actions is natively available and integrated into GitHub repositories and features many reusable workflows from community contributors, such as publishing npm packages, publishing docker images, running security tests, and more.

How do actions work in GitHub?

GitHub’s cloud infrastructure is running GitHub Actions for users by creating a workflow file in a GitHub repository directory named .github/workflows, describing the trigger, schedule for the job, and the actions the job should take using YAML.

What is a GitHub workflow?

A GitHub workflow is a set of jobs that would run based on a trigger or a cron-based schedule. A job consists of one or more steps that make up an automated workflow.

Setting up a Node.js project for GitHub Actions

Let’s add an initial GitHub Actions automation to a Node.js project. The GitHub Actions job will install all required npm packages, run tests, and eventually publish our project as an npm package that users can consume.

Our npm package is going to be a Command Line Interface (CLI) for you to browse the amazing list of talks from SnykCon 2020—Snyk’s first-ever global security event that took place in 2020.

The complete project is hosted on GitHub and here is a sneak peek at how the npm package looks like:

A complete GitHub CI workflow starts off with creating the following GitHub Action file at the root of the repository path: .github/workflows/main.yml

name: main

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x, 14.x]
    steps:
      - uses: actions/checkout@v2
      - name: Build on Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm run build --if-present
        name: Build
      - run: npm test
        env:
          CI: true

The above is very much a stock template for a build and test process of Node.js projects, doing the following:

1. The trigger is on every push, to every branch.
2. We run this action on Node.js versions 12.x and 14.x to ensure compatibility across both Node.js LTS versions.
3. The job then runs several steps that check out the git codebase, runs a secure and deterministic npm install phase, continues to run a build step if present, and finally runs tests.

As you push new commits to the repository, whether you are following a GitHub flow, or a GitHub pull request workflow, you’ll see new jobs queuing up in the repository’s Actions tab. Like the following, that shows our tests running for npm package snykcon:

Publishing npm packages with GitHub Actions

If all tests pass, and this automation workflow runs in our main branch, we could automate releasing new versions altogether!

When it comes to releasing packages, it’s a good idea to consider the security implications that concern such actions. Let’s review a few of them:

1. Malicious code: If a vulnerability is intentionally added by someone as part of the code contribution and you missed it, an automatic release when merging to your main branch means it will be available to users immediately. If you manually release immediately, there’s no difference either—however, the more time passes between merging pull requests and releases, it gives more time for the community to scrutinize and help flesh out such issues.
2. Vulnerable dependency: If a malicious person adds a dependency with known public vulnerability then this dependency will trickle into your users as it gets pulled during the install process. Using a free tool like Snyk to connect to your git repositories and add a status check to prevent you from releasing with vulnerable versions of dependencies, solves exactly this problem.
3. Malicious dependency through a lockfile: Have you considered what would happen if a contribution to update package.json dependencies would actually inject a malicious package into the lockfile, which nobody takes the time to review anyway, right? I wrote about why npm lockfiles can be a security blindspot for injecting malicious modules so make sure you deep dive into this if you hadn’t considered this attack vector.
4. Stealing your npm token: In the past, quite a few attempts of malicious packages circled around the notion of stealing a person’s npm token or other sensitive information that exists in environment variables.

The above isn’t meant to be a comprehensive list of security concerns, but it definitely highlights quite a few that we should be aware of.

Speaking of security highlights, do you find that list of possible security concerns an interesting and educational read? It’s a quick threat modeling process, which you can practice more regularly when you build out features. We wrote about it in our DevSecOps Process and there’s a good talk from SnykCon by Alyssa Miller on User Story Threat Modeling: It’s the DevSecOps Way. Check them out!

Let’s go back to our list and focus on the last security concern mentioned—stealing your npm token. Since this article is all about publishing npm packages, it means we need to make an npm token available to the GitHub Actions workflow and this has historically been frowned upon for the following reasons:

• npm capabilities: historically, releasing npm packages using an npm token, required your npm user to disable two-factor authentication. It’s not anymore and we’re going to learn how!
• Stealing a token from malicious packages install: if you make the npm token available in your CI as environment variables, then malicious packages that exist in your package dependency tree (beyond your own direct dependencies) may have access to it during, for example, the npm install process, which by default allows packages to run any arbitrary command.

#github #npm #node #javascript #developer