Skip to content

GitHub Actions: Ability to change retention days for artifacts and logs

You can now change the maximum retention days for artifacts and logs in GitHub Actions, allowing you to better manage your storage space and to comply with your organizational retention policies.

With custom retention days, you can delete artifacts and logs sooner than the existing default of 90 days. Optionally, for private, internal and GitHub Enterprise repositories, you can retain artifacts and logs for over a year.

Retention days can be defined in the Actions Settings or in the YAML at an enterprise, organization, repository, or an individual artifact level.

Here’s an example of changing retention days in Actions Settings and in the YAML:

- uses: actions/upload-artifact
  with:
    name: my-artifact
    path: ./my_path
    retention-days: 30

Learn more about custom artifacts and log retention days and visit the GitHub Actions community forum for questions.

npm automation tokens

npm is introducing a new setting for access tokens to support publishing to the npm registry from CI/CD workflows.

Previously, you could create an access token with one of two settings: read-only, and publish. A publish token allows you to publish packages, like the name implies, but if you have two-factor authentication (2FA) enabled on your account, you'll be prompted for your one-time passcode.

We recommend that people set up 2FA on their account for added security, but requiring a passcode means that all publishing must be done interactively. Many people want to automate their publish step with a CI/CD workflow.

Today, we've added a third option for access tokens: automation. You can create an automation token in your access token settings page.

Access token type selection

Using an automation token will not prompt for a one-time passcode, meaning that you can use it as a secret in your publish workflow. Now you can publish a package directly to the npm registry when you cut a release.

If you're a package maintainer, and you want to require that publishers to your package continue to use two-factor authentication and publish interactively, you can do that in the package settings. If you already required 2FA, there's no change to this behavior; automation tokens won't be accepted unless you allow them to be.

If you've been waiting to enable two-factor authentication on your npm account because it prevented you from publishing in an automated workflow, you can now set up an automation token and enable 2FA.

See more
View all changes