Dexter  Goodwin

Dexter Goodwin

1660407300

Semantic-release-action: GitHub Action for Running Semantic-release

semantic-release-action

GitHub Action for running semantic-release. Respects any semantic-release configuration file in your repo or the release prop in your package.json. Exports environment variables for you to use in subsequent actions containing version numbers.

Usage

See action.yml.

Referencing the major version is (recommended by GitHub).

steps:
  # Reference the major version of a release
  - uses: codfish/semantic-release-action@v2
  # Reference a specific commit
  - uses: codfish/semantic-release-action@c4074285a1651e4fecab9c14974d5e01b4625edf
  # Reference a minor version of a release
  - uses: codfish/semantic-release-action@v1.10
  # Reference a branch
  - uses: codfish/semantic-release-action@master

Note: Whenever you use a custom docker-based GitHub Action like this one, you may notice in your run logs, one of the first steps you'll see will be GA building the image for you. You can speed up runs by pulling pre-built docker images instead of making GitHub Actions build them on every run.

steps:
  # Reference a docker image from GitHub Container Registry
  - uses: docker://ghcr.io/codfish/semantic-release-action:v2
  # Reference a docker image from Dockerhub
  - uses: docker://codfish/semantic-release-action:v2

If you're security conscious, you can pin the docker image down to a specific digest instead of using an image tag, which is a mutable reference.

steps:
  # Reference a docker image from GitHub Container Registry (example for v2.0.0)
  - uses: docker://ghcr.io/codfish/semantic-release-action@sha256:91ea452696d93a34a30aff20b34614b75e8fddc82b598fc8fa57c3ac07e6d6da

Inspect the image version you want here to find the digest. If you prefer pulling from Docker Hub, check here.

Basic Usage

steps:
  - uses: actions/checkout@v2

  - uses: codfish/semantic-release-action@v2
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Using output variables set by semantic-release-action:

steps:
  - uses: actions/checkout@v2

  # you'll need to add an `id` in order to access output variables
  - uses: codfish/semantic-release-action@v2
    id: semantic
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - run: echo ${{ steps.semantic.outputs.release-version }}

  - run: echo "$OUTPUTS"
    env:
      OUTPUTS: ${{ toJson(steps.semantic.outputs) }}

  - uses: codfish/some-other-action@v1
    with:
      release-version: ${{ steps.semantic.outputs.release-version }}

Example: Only run an action if a new version was created.

steps:
  - uses: actions/checkout@v2

  # you'll need to add an `id` in order to access output variables
  - uses: codfish/semantic-release-action@v2
    id: semantic
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - name: docker push version
    if: steps.semantic.outputs.new-release-published == 'true'
    run: |
      docker tag some-image some-image:$TAG
      docker push some-image:$TAG
    env:
      TAG: v$RELEASE_VERSION

Using environment variables set by semantic-release-action:

steps:
  - uses: actions/checkout@v2

  - uses: codfish/semantic-release-action@v2
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - run: |
      echo $RELEASE_VERSION
      echo $RELEASE_MAJOR
      echo $RELEASE_MINOR
      echo $RELEASE_PATCH

If you're not publishing to npm and only want to use this action for GitHub releases, the easiest approach would simply be to add "private": true, to your package.json.

Why

It's fairly easy to run semantic-release as a "host action," aka something that runs directly on the VM.

steps:
  - run: npx semantic-release
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

If you're just publishing a node package, then this could still work well for you. The problem I found with this is when I was in projects where I had subsequent steps/actions in which I wanted to know whether a new version was cut.

Use Case: For instance, in an application where I'm using semantic-release to manage GitHub releases, but also building and pushing docker images. Dockerhub has a nice GitHub integration to handle this for us, but some other registries do not. If I need to cut a new release, then update a docker registry by adding a new tagged build, I'll want to run semantic-release and then build a docker image, tag it with a version and push it up. In my case I like to push up tags for latest, the semver (i.e. v1.8.3), and just the major the version (i.e. v1).

I want to know 1) if semantic-release cut a new version and 2) what the version is.

There's a number of ways to handle this, but the most elegant way I found to do it was to abstract it into it's own custom action. It abstracts away whatever logic you need to figure out what that new release number is.

This also scales well, just in case I want to add some flexibility and functionality to this action, I can easily leverage it across any project.

Configuration

You can pass in semantic-release configuration options via GitHub Action inputs using with.

It's important to note, NONE of these inputs are required. Semantic release has a default configuration that it will use if you don't provide any.

Also of note, if you'd like to override the default configuration and you'd rather not use the inputs here, the action will automatically use any semantic-release configuration defined in your repo (.releaserc, release.config.js, release prop in package.json)

Note: Each input will take precedence over options configured in the configuration file and shareable configurations.

Input VariableTypeDescription
branchesArray, String, ObjectThe branches on which releases should happen.
pluginsArrayDefine the list of plugins to use. Plugins will run in series, in the order defined, for each steps if they implement it
extendsArray, StringList of modules or file paths containing a shareable configuration.
additional_packagesArray, StringDefine a list of additional plugins/configurations (official or community) to install. Use this if you 1) use any plugins other than the defaults, which are already installed along with semantic-release or 2) want to extend from a shareable configuration.
dry_runBooleanThe objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, success and fail.
repository_urlStringThe git repository URL
tag_formatStringThe Git tag format used by semantic-release to identify releases.

Note: Any package specified in extends or additional_packages will be installed automatically for you as a convenience, allowing you to use this action without adding new dependencies to your application or install deps in a separate action step.

Note: additional_packages won't get used automatically, setting this variable will just install them so you can use them. You'll need to actually list them in your plugins and/or extends configuration for semantic-release to use them.

Note: The branch input is DEPRECATED. Will continue to be supported for v1. Use branches instead. Previously used in semantic-release v15 to set a single branch on which releases should happen.

Example with all inputs

steps:
  - run: codfish/semantic-release-action@v2
    with:
      dry_run: true
      branches: |
        [
          '+([0-9])?(.{+([0-9]),x}).x',
          'master',
          'next',
          'next-major',
          {
            name: 'beta',
            prerelease: true
          },
          {
            name: 'alpha',
            prerelease: true
          }
        ]
      repository_url: https://github.com/codfish/semantic-release-action.git
      tag_format: 'v${version}'
      extends: '@semantic-release/apm-config'
      additional_packages: |
        ['@semantic-release/apm@4.0.0', '@semantic-release/git']
      plugins: |
        ['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/github', '@semantic-release/apm', '@semantic-release/git']
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Outputs

semantic-release-action sets both output variables and environment variables because why not? Allows users the ability to use whichever they want. I don't know or understand every use case there might be so this is a way to cover more cases.

Docs: https://help.github.com/en/articles/metadata-syntax-for-github-actions#outputs

Output Variables:

Output VariableDescription
new-release-publishedEither 'true' when a new release was published or 'false' when no release was published. Allows other actions to run or not-run based on this
release-versionThe new releases' semantic version, i.e. 1.8.3
release-majorThe new releases' major version number, i.e. 1
release-minorThe new releases' minor version number, i.e. 8
release-patchThe new releases' patch version number, i.e. 3
release-notesThe release notes of the next release.

Environment Variables:

Environment VariableDescription
NEW_RELEASE_PUBLISHEDEither 'true' when a new release was published or 'false' when no release was published. Allows other actions to run or not-run based on this
RELEASE_VERSIONThe new releases' semantic version, i.e. 1.8.3
RELEASE_MAJORThe new releases' major version number, i.e. 1
RELEASE_MINORThe new releases' minor version number, i.e. 8
RELEASE_PATCHThe new releases' patch version number, i.e. 3
RELEASE_NOTESThe release notes of the next release in markdown.

Maintenance

Make the new release available to those binding to the major version tag: Move the major version tag (v1, v2, etc.) to point to the ref of the current release. This will act as the stable release for that major version. You should keep this tag updated to the most recent stable minor/patch release.

git tag -fa v2 -m "Update v2 tag" && git push origin v2 --force

Reference: https://github.com/actions/toolkit/blob/master/docs/action-versioning.md recommendations

Download Details:

Author: Codfish
Source Code: https://github.com/codfish/semantic-release-action 
License: MIT license

#javascript #github #action 

What is GEEK

Buddha Community

Semantic-release-action: GitHub Action for Running Semantic-release
Dexter  Goodwin

Dexter Goodwin

1660407300

Semantic-release-action: GitHub Action for Running Semantic-release

semantic-release-action

GitHub Action for running semantic-release. Respects any semantic-release configuration file in your repo or the release prop in your package.json. Exports environment variables for you to use in subsequent actions containing version numbers.

Usage

See action.yml.

Referencing the major version is (recommended by GitHub).

steps:
  # Reference the major version of a release
  - uses: codfish/semantic-release-action@v2
  # Reference a specific commit
  - uses: codfish/semantic-release-action@c4074285a1651e4fecab9c14974d5e01b4625edf
  # Reference a minor version of a release
  - uses: codfish/semantic-release-action@v1.10
  # Reference a branch
  - uses: codfish/semantic-release-action@master

Note: Whenever you use a custom docker-based GitHub Action like this one, you may notice in your run logs, one of the first steps you'll see will be GA building the image for you. You can speed up runs by pulling pre-built docker images instead of making GitHub Actions build them on every run.

steps:
  # Reference a docker image from GitHub Container Registry
  - uses: docker://ghcr.io/codfish/semantic-release-action:v2
  # Reference a docker image from Dockerhub
  - uses: docker://codfish/semantic-release-action:v2

If you're security conscious, you can pin the docker image down to a specific digest instead of using an image tag, which is a mutable reference.

steps:
  # Reference a docker image from GitHub Container Registry (example for v2.0.0)
  - uses: docker://ghcr.io/codfish/semantic-release-action@sha256:91ea452696d93a34a30aff20b34614b75e8fddc82b598fc8fa57c3ac07e6d6da

Inspect the image version you want here to find the digest. If you prefer pulling from Docker Hub, check here.

Basic Usage

steps:
  - uses: actions/checkout@v2

  - uses: codfish/semantic-release-action@v2
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Using output variables set by semantic-release-action:

steps:
  - uses: actions/checkout@v2

  # you'll need to add an `id` in order to access output variables
  - uses: codfish/semantic-release-action@v2
    id: semantic
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - run: echo ${{ steps.semantic.outputs.release-version }}

  - run: echo "$OUTPUTS"
    env:
      OUTPUTS: ${{ toJson(steps.semantic.outputs) }}

  - uses: codfish/some-other-action@v1
    with:
      release-version: ${{ steps.semantic.outputs.release-version }}

Example: Only run an action if a new version was created.

steps:
  - uses: actions/checkout@v2

  # you'll need to add an `id` in order to access output variables
  - uses: codfish/semantic-release-action@v2
    id: semantic
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - name: docker push version
    if: steps.semantic.outputs.new-release-published == 'true'
    run: |
      docker tag some-image some-image:$TAG
      docker push some-image:$TAG
    env:
      TAG: v$RELEASE_VERSION

Using environment variables set by semantic-release-action:

steps:
  - uses: actions/checkout@v2

  - uses: codfish/semantic-release-action@v2
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

  - run: |
      echo $RELEASE_VERSION
      echo $RELEASE_MAJOR
      echo $RELEASE_MINOR
      echo $RELEASE_PATCH

If you're not publishing to npm and only want to use this action for GitHub releases, the easiest approach would simply be to add "private": true, to your package.json.

Why

It's fairly easy to run semantic-release as a "host action," aka something that runs directly on the VM.

steps:
  - run: npx semantic-release
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

If you're just publishing a node package, then this could still work well for you. The problem I found with this is when I was in projects where I had subsequent steps/actions in which I wanted to know whether a new version was cut.

Use Case: For instance, in an application where I'm using semantic-release to manage GitHub releases, but also building and pushing docker images. Dockerhub has a nice GitHub integration to handle this for us, but some other registries do not. If I need to cut a new release, then update a docker registry by adding a new tagged build, I'll want to run semantic-release and then build a docker image, tag it with a version and push it up. In my case I like to push up tags for latest, the semver (i.e. v1.8.3), and just the major the version (i.e. v1).

I want to know 1) if semantic-release cut a new version and 2) what the version is.

There's a number of ways to handle this, but the most elegant way I found to do it was to abstract it into it's own custom action. It abstracts away whatever logic you need to figure out what that new release number is.

This also scales well, just in case I want to add some flexibility and functionality to this action, I can easily leverage it across any project.

Configuration

You can pass in semantic-release configuration options via GitHub Action inputs using with.

It's important to note, NONE of these inputs are required. Semantic release has a default configuration that it will use if you don't provide any.

Also of note, if you'd like to override the default configuration and you'd rather not use the inputs here, the action will automatically use any semantic-release configuration defined in your repo (.releaserc, release.config.js, release prop in package.json)

Note: Each input will take precedence over options configured in the configuration file and shareable configurations.

Input VariableTypeDescription
branchesArray, String, ObjectThe branches on which releases should happen.
pluginsArrayDefine the list of plugins to use. Plugins will run in series, in the order defined, for each steps if they implement it
extendsArray, StringList of modules or file paths containing a shareable configuration.
additional_packagesArray, StringDefine a list of additional plugins/configurations (official or community) to install. Use this if you 1) use any plugins other than the defaults, which are already installed along with semantic-release or 2) want to extend from a shareable configuration.
dry_runBooleanThe objective of the dry-run mode is to get a preview of the pending release. Dry-run mode skips the following steps: prepare, publish, success and fail.
repository_urlStringThe git repository URL
tag_formatStringThe Git tag format used by semantic-release to identify releases.

Note: Any package specified in extends or additional_packages will be installed automatically for you as a convenience, allowing you to use this action without adding new dependencies to your application or install deps in a separate action step.

Note: additional_packages won't get used automatically, setting this variable will just install them so you can use them. You'll need to actually list them in your plugins and/or extends configuration for semantic-release to use them.

Note: The branch input is DEPRECATED. Will continue to be supported for v1. Use branches instead. Previously used in semantic-release v15 to set a single branch on which releases should happen.

Example with all inputs

steps:
  - run: codfish/semantic-release-action@v2
    with:
      dry_run: true
      branches: |
        [
          '+([0-9])?(.{+([0-9]),x}).x',
          'master',
          'next',
          'next-major',
          {
            name: 'beta',
            prerelease: true
          },
          {
            name: 'alpha',
            prerelease: true
          }
        ]
      repository_url: https://github.com/codfish/semantic-release-action.git
      tag_format: 'v${version}'
      extends: '@semantic-release/apm-config'
      additional_packages: |
        ['@semantic-release/apm@4.0.0', '@semantic-release/git']
      plugins: |
        ['@semantic-release/commit-analyzer', '@semantic-release/release-notes-generator', '@semantic-release/github', '@semantic-release/apm', '@semantic-release/git']
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Outputs

semantic-release-action sets both output variables and environment variables because why not? Allows users the ability to use whichever they want. I don't know or understand every use case there might be so this is a way to cover more cases.

Docs: https://help.github.com/en/articles/metadata-syntax-for-github-actions#outputs

Output Variables:

Output VariableDescription
new-release-publishedEither 'true' when a new release was published or 'false' when no release was published. Allows other actions to run or not-run based on this
release-versionThe new releases' semantic version, i.e. 1.8.3
release-majorThe new releases' major version number, i.e. 1
release-minorThe new releases' minor version number, i.e. 8
release-patchThe new releases' patch version number, i.e. 3
release-notesThe release notes of the next release.

Environment Variables:

Environment VariableDescription
NEW_RELEASE_PUBLISHEDEither 'true' when a new release was published or 'false' when no release was published. Allows other actions to run or not-run based on this
RELEASE_VERSIONThe new releases' semantic version, i.e. 1.8.3
RELEASE_MAJORThe new releases' major version number, i.e. 1
RELEASE_MINORThe new releases' minor version number, i.e. 8
RELEASE_PATCHThe new releases' patch version number, i.e. 3
RELEASE_NOTESThe release notes of the next release in markdown.

Maintenance

Make the new release available to those binding to the major version tag: Move the major version tag (v1, v2, etc.) to point to the ref of the current release. This will act as the stable release for that major version. You should keep this tag updated to the most recent stable minor/patch release.

git tag -fa v2 -m "Update v2 tag" && git push origin v2 --force

Reference: https://github.com/actions/toolkit/blob/master/docs/action-versioning.md recommendations

Download Details:

Author: Codfish
Source Code: https://github.com/codfish/semantic-release-action 
License: MIT license

#javascript #github #action 

Desmond  Gerber

Desmond Gerber

1624347085

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

Oral  Brekke

Oral Brekke

1617437520

Deploying my portfolio website on Github Pages using Github Actions.

I recently deployed  my portfolio site and wanted to try out github actions and this is my experience of automating the deployment.

This article is more focused on how you can use the GitHub actions and how easy it is to deploy your code to GitHub pages rather than the portfolio site code.So every time you make an update or build to your website ,the changes are automatically reflected and this automated deploying process makes work much faster.

The way GitHub action works is you create actions in your repositories by creating one or more yaml files and these are called workflows.Workflows now can handle build tasks like CI CD. This means you use the action to test your code and push the site to the desired hosting platform (in this case GitHub pages ) when the main branch changes .

First step assuming that you have a GitHub account is to create a repository having your website code in it.Now I have a bootstrap website but in the future I do plan on adding node JS so I already added package.json.

#workflow #portfolio #github #github-actions #github-pages

Edison  Stark

Edison Stark

1603861600

How to Compare Multiple GitHub Projects with Our GitHub Stats tool

If you have project code hosted on GitHub, chances are you might be interested in checking some numbers and stats such as stars, commits and pull requests.

You might also want to compare some similar projects in terms of the above mentioned stats, for whatever reasons that interest you.

We have the right tool for you: the simple and easy-to-use little tool called GitHub Stats.

Let’s dive right in to what we can get out of it.

Getting started

This interactive tool is really easy to use. Follow the three steps below and you’ll get what you want in real-time:

1. Head to the GitHub repo of the tool

2. Enter as many projects as you need to check on

3. Hit the Update button beside each metric

In this article we are going to compare three most popular machine learning projects for you.

#github #tools #github-statistics-react #github-stats-tool #compare-github-projects #github-projects #software-development #programming

Juana  O'Keefe

Juana O'Keefe

1603830240

A better logs experience with GitHub Actions

It’s now even easier to review logs from your GitHub Actions workflow runs. We’ve introduced several improvements to make the experience more performant, precise, and pleasing to use.

Why these changes matter

When we think about successful automation, we aim to spend the least amount of time looking at what’s automated, so we can focus our attention on what’s relevant. But sometimes things don’t go as planned, and we are required to review what happened. That debugging process can be frustrating; that’s why we’re introducing a series of changes that will improve both performance and user experience:

  • Simplified the layout structure
  • Introduced a single and faster virtualized scrolling
  • The search is now more responsive
  • Better ANSI, 8-bit, and 24-bit color support
  • URLs are now interactive
  • A new full-screen view mode
  • A refreshed UI that improves readability and overall interactions

#features #product #actions #ci/cd #github actions #github