Skip to content

GitHub Actions – Support for configuration variables in workflows

Today, we are adding support for configuration variables in GitHub Actions 🎉

Previously, you needed to store this configuration data as encrypted secrets in order to reuse values in workflows.
While extremely secure, this method did not allow for easy storage and retrieval of non-sensitive configuration data such as compiler flags, usernames, server names etc.

Configuration variables allows you to store your non sensitive data as plain text variables that can be reused across your workflows in your repository or organization.
You can define variables at Organization, Repository or Environment level based on your requirement.

Configuration variables

Configuration variables can be accessed across the workflow using a new vars context.
The following example shows how configuration variables can be used in a workflow.

    runs-on: ${{ vars.RUNNER }}
    - name: Use variables
      run: |
        echo "Repository variable : ${{ vars.REPOSITORY_VAR }}"
        echo "Organization variable : ${{ vars.ORGANIZATION_VAR }}"

Note: Variables feature is in public beta

Learn more about configuration variables

Today, we are announcing public beta of required workflows in GitHub Actions 🎉

Required workflows allow DevOps teams to define and enforce standard CI/CD practices across many source code repositories within an organization without needing to configure each repository individually. Organization admins can configure required workflows to run on all or selected repositories within the organization.

Required workflows at the organization level

Required workflows will be triggered as required status checks for all the pull requests opened on the default branch, which blocks the ability to merge the pull request until the required workflow succeeds.
Individual development teams at the repository level will be able to see what required workflows have been applied to their repository.

Required workflows run at repo

In addition to reducing duplication of CI/CD configuration code, required workflows can also help companies with the following use cases:

  • Security: Invoke external vulnerability scoring or dynamic analysis tools.
  • Compliance: Ensure that all code meets an enterprise’s quality standards.
  • Deployment: Ensure that code is continuously deployed in a standard way.

Learn more about required workflows

See more

Code scanning can now be easily setup with a few button clicks, and without committing a workflow file to the repository.

Code scanning's new default setup feature automatically finds and sets up the best CodeQL configuration for your repository. This will detect the languages in the repository and enable CodeQL analysis for every pull request and every push to the default branch and any protected branches. Default setup currently supports analysis of JavaScript (including TypeScript), Python, and Ruby code. More languages will be supported soon, and all other languages supported by CodeQL continue to work using a GitHub Actions workflow file.

The new default setup feature is available for CodeQL on repositories that use GitHub Actions. You can use default setup on your repository's "Settings" tab under "Code security and analysis" (accessible by repository admins and security managers).

Screenshot of code scanning's new _default setup_

The options to set up code scanning using an Actions workflow file or through API upload from 3rd party CI/CD systems remain supported and are unchanged. This more advanced setup method can be useful if you need to alter the default configuration, for example to include custom query packs. Default setup configurations can also be converted to advanced setups if your analysis requirements change.

Default setup is currently available at the repository level. We are actively working on future features at the organization level so you can easily set up code scanning at scale across large numbers of repositories.

This has shipped to and will be available in GitHub Enterprise Server 3.9. To learn more, read the documentation on setting up code scanning for a repository.

See more