workflows

GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.

We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.

Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.

For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

Today, we are adding a couple of new improvements to required workflows in GitHub Actions.

• Blocking direct push: Direct pushes are now blocked on branches of the repositories where required workflows are enforced. To push to a branch where required workflows are enforced at the organizational level, create a pull request to make the necessary changes. If you want to allow direct pushes for a particular repository, you must remove the repository as a target from respective required workflows.
  
  
• Ability to configure required workflows from refs: Required workflows can now be referenced using any branch, tag, or commit SHA from the repository containing the workflow file, during its configuration. This helps you to freeze your required workflow file to a fully validated golden version and gives you the flexibility to move to latest version after testing it thoroughly. The branch, tag, or commit can be specified in the workflow path text field similar to how it is specified for actions within a workflow yaml.
  

Link to Documentation

Note: Required workflows is currently in beta.

Previously, GitHub Actions gets a GITHUB_TOKEN with both read/write permissions by default whenever Actions is enabled on a repository.
As a default, this is too permissive, so to improve security we would like to change the default going forward to a read-only token. You can still flip it to read/write if needed.

This change will not impact any existing enterprises, organizations or repositories. Here is how the defaults are set going forward.

1. Enterprises: New enterprises will have read-only token.
2. Organizations owned by Enterprise: New organizations will inherit the permissions from parent enterprise.
3. Organizations not owned by Enterprise: New organizations will have read-only token.
4. Repositories owned by organization: New repositories will inherit permissions from parent organization.
5. Repositories owned by personal account: New repositories will have read-only token.

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 can be accessed across the workflow using a new vars context.
The following example shows how configuration variables can be used in a workflow.

jobs:
  display-variables:
    runs-on: ${{ vars.RUNNER }}
    steps:
    - 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 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.

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