8000 GitHub - UnlyEd/github-action-deploy-on-vercel at v0.0.11
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

UnlyEd/github-action-deploy-on-vercel

Use this GitHub action with your project
Add this Action to an existing workflow or create a new one
View on Marketplace

Repository files navigation

Unly logo Maintainability Test Coverage

GitHub Action integration test GitHub Action build test Update Code Climate test coverage

GitHub Action - Store variables between your jobs

Code snippet example (minimal example)

name: 'GitHub Action code snippet'
on:
  push:
    branches:
      - '*'
jobs:
  # On some job, do some stuff an persist variables meant to be re-used in other jobs
  compute-data:
    name: Compute data
    runs-on: ubuntu-18.04
    steps:
      # Do your own internal business logic...
      - name: Compute ressource
        run: |
          MAGIC_NUMBER=42
          echo "Found universal answer: $MAGIC_NUMBER"
          echo "Exporting it as ENV variable..."
          echo "MAGIC_NUMBER=$MAGIC_NUMBER" >> $GITHUB_ENV

      # XXX We recommend to export all your variables at once, at the end of your job
      - name: Export variable for next jobs
        uses: UnlyEd/github-action-store-variable@v2.1.0 # See https://github.com/UnlyEd/github-action-store-variable
        with:
          # Persist (store) our MAGIC_NUMBER ENV variable into our store, for the next jobs
          variables: |
            MAGIC_NUMBER=${{ env.MAGIC_NUMBER }}

  # In another job, read the previously stored variable and use it
  retrieve-data:
    name: Find & re-use data
    runs-on: ubuntu-18.04
    needs: compute-data
    steps:
      - name: Import variable MAGIC_NUMBER
        uses: UnlyEd/github-action-store-variable@v2.1.0 # See https://github.com/UnlyEd/github-action-store-variable
        with:
          # List all variables you want to retrieve from the store
          # XXX They'll be automatically added to your ENV
          variables: | 
            MAGIC_NUMBER
      - name: Debug output
        run: echo "We have access to $MAGIC_NUMBER"

If you want to see a real output, check out the output of our code snippet example here.

See the Examples section for more advanced examples.

What does this GitHub Action do?

You can use this action to store variables in a sort of "global store" for your GitHub Actions.

Then, you can read the variables that have been stored previously.

The variables stored can be read by any job within the same workflow.

N.B: When you read a variable, it is automatically added as an ENV variable and will erase any variable with the same name.

This behavior helps keeping the code cleaner by only manipulating (reading/writing) ENV variables. In v1, we had to read the variables from a JSON object, and it was ugly.

N.B: You can both read and write in the same action.

Why/when should you use it?

GitHub Actions doesn't allow to natively re-use variables between jobs.

If you need to re-use variables defined in a job in other (subsequent) jobs, then you can use this action.

Action's API

Inputs

Name Required Default Description
variables Write variable: VAR=VALUE - Read variable: VAR
delimiter ✖️ \r?\n Regex delimiter between each variable, defaults to normal line break
failIfNotFound ✖️ false If true, will throw an error (and crash CI) when attempting to read a variable that doesn't exist in the store

Outputs

There are no outputs for this action, reading variables automatically adds these variables in ${{ env }}.

For example, if you read a variable named VAR, you can then access it by using ${{ env.VAR }}.

Examples

1. Save one variable

- name: Export one variable
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    variables: FOO=BAR

2. Save many variables

- name: Export many variables
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    variables: |
      FOO=BAR
      STAGE=production

Pro-tip: We recommend always using the variables: | syntax (multi lines), because it's just simpler to add more variables later on.

3. Save one variable and read another

- name: Export one variable
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    # Writes "FOO" and reads "STAGE"
    variables: |
      FOO=BAR
      STAGE

4. Save many variables using a custom delimiter

- name: Export many variables
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    delimiter: ':'
    variables: FOO=BAR:STAGE=production

5. Retrieve one variable

- name: Import variable MAGIC_NUMBER
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    variables: FOO

6. Retrieve many variables

- name: Import variable MAGIC_NUMBER
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    variables: |
      FOO
      STAGE

7. Retrieve many variables using a custom delimiter

- name: Import variable MAGIC_NUMBER
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    delimiter: ';'
    variables: FOO;STAGE

8. Crash CI if variable doesn't exist

- name: Import variable MAGIC_NUMBER
  uses: UnlyEd/github-action-store-variable@v2.1.0
  with:
    failIfNotFound: true
    variables: WRONG_VARIABLE

N.B: If you want to crash only for some variables, then you can call 2 times the UnlyEd/github-action-store-variable and have failIfNotFound: true in one of them.

🤗 Community examples ❤️

Here are a few community-powered examples, those are usually advanced use-cases!


Advanced debugging

Learn how to enable logging, from within the github-action-store-variable action.

How to enable debug logs

Our GitHub Action is written using the GitHub Actions native core.debug API.

Therefore, it allows you to enable logging whenever you need to debug what's happening within our action.

To enable debug mode, you have to set a GitHub Secret, such as:

  • ACTIONS_STEP_DEBUG of value true

Please see the official documentation for more information.

Enabling debugging using ACTIONS_STEP_DEBUG will also enable debugging for all other GitHub Actions you use that are using the core.debug API.


Contributing

We gladly accept PRs, but please open an issue first, so we can discuss it beforehand.


Changelog

Changelog


Releases versioning

We follow Semantic Versioning. (major.minor.patch)

Our versioning process is completely automated, any changes landing on the main branch will trigger a new release.

  • MAJOR: Behavioral change of the existing API that would result in a breaking change.
    • E.g: Removing an input, or changing the output would result in a breaking change and thus would be released as a new MAJOR version.
  • Minor: Behavioral change of the existing API that would not result in a breaking change.
    • E.g: Adding an optional input would result in a non-breaking change and thus would be released as a new Minor version.
  • Patch: Any other change.
    • E.g: Documentation, tests, refactoring, bug fix, etc.

Releases versions:

  • We do not provide major versions that are automatically updated (e.g: v1).
  • We only provide tags/releases that are not meant to be changed once released (e.g: v1.1.0).

As utility, we provide a special latest tag which is automatically updated to the latest release. This tag/release is not meant to be used in production systems, as it is not reliable (might jump to the newest MAJOR version at any time).


License

MIT


Vulnerability disclosure

See our policy.


Contributors and maintainers

This project is being authored by:


[ABOUT UNLY] Unly logo

Unly is a socially responsible company, fighting inequality and facilitating access to higher education. Unly is committed to making education more inclusive, through responsible funding for students.

We provide technological solutions to help students find the necessary funding for their studies.

We proudly participate in many TechForGood initiatives. To support and learn more about our actions to make education accessible, visit :

Tech tips and tricks from our CTO on our Medium page!

TECHFORGOOD #EDUCATIONFORALL

0