Build with an Azure free account. Get USD200 credit for 30 days and 12 months of free services.

Start free today

Deploying packages with GitHub Actions

Play Deploying packages with GitHub Actions

The Discussion

  • User profile image
    Nice video! I think it could help to update the title that this video demonstrates deploying packages to Github package store. I think people might read it and assume it's publishing to NPM which is not new or as interesting.

    Some points:

    1. Simplified Authentication
    I think could be emphasized more is that because the workflow is publishing to Github and by default a GITHUB_TOKEN environment variable is make available to process it simplifies authentication. This used to be a cumbersome manually configuration step where you had to create a token from NPM, then set it as secret on your repo so that it could be accessed by the build and use some weird tricks like
    npm set //${NPM_TOKEN} to allow authenticated requests to NPM.

    2. Preventing publish of forks
    I was a little skeptical about the "if: github.repository_owner == 'aaronpowell'" line. This seems like a common task. I thought perhaps they could add some first-class support to it like "--disable-on-forks" or something.

    The referenced article said "it won’t have access to secrets.GITHUB_TOKEN, and as such the job would fail to publish". I didn't understand this. I thought every pipeline on github would have it's own GITHUB_TOKEN it's just that the token given to the fork wouldn't have permissions to publish to your package store.

    3. Repeated steps of the build
    The article called out having to get node dependencies twice because it split the build / publish into two jobs. I know the video was focused on package publishing and not workflow efficiency this seems like a significant problem since it would almost double the time of pipeline (duplication the most expensive process). I wonder if they could add some references on how to eliminate this problem.

    For example on other CI tools such as CircleCI they have a shared file system across the jobs so the first job can install dependencies and build and you can give this a stable working directory to reference in future jobs. And those later jobs such as "package" can rely on these dependencies already being installed. This guarantees the same bits moving across the workflow which is a nice property. Perhaps Github actions have a similar ability i'm not aware of but it would be nice to call out.

    Keep up the great work!

Add Your 2 Cents