We have introduced some UI changes to the pipelines page:

• The column previously named “Project” was renamed into “Pipeline”

  It displays pipeline name, pipeline number, and (only when looking at the All pipelines view) project name

• The column previously named “Trigger event” was renamed into “Checkout source”

  It continues to show the same information as before, but the avatar now shows the profile picture of the commit author, if that information is available. If it isn’t (this is currently the case for OAuth pipelines), the avatar does not show. To avoid this inconsistency, we plan on hiding the avatar also for other types of pipelines.

• A new column “Trigger event” was added

  It shows what event that triggered a pipeline (Push, Pull request, API, …). The avatar indicates who triggered the event, with a tooltip showing the username on hover.

• The headers of columns Pipeline and Trigger event each include tooltips, informing users that:

  1. it’s now possible to have multiple pipelines in the same project
  2. more GitHub trigger events options are now available

  These tooltips are visible to orgs that integrate with our GitHub OAuth app integration or GitHub App/GitLab/Bitbucket Data Center integrations. They are not visible to organizations that integrate with Bitbucket Cloud..

These changes are currently in preview, and additional improvements will be made in the coming weeks. If you have any feedback, please comment on this post on our community forum.

Runner Release 3.1.3

Machine Runner:

• Fixed a bug where an error downloading the task agent binary was not correctly propagated, causing the runner to get stuck without retrying the download and requiring a manual restart to unblock.

We’ve introduced a new project overview page, which allows users to get a quick sense of the health of their pipelines and see what changes have recently been deployed for a project all in one place. Users can access this page by clicking the Overview link from the Organization Home page or Projects page.

If you have any feedback on how we can improve this overview, please use the survey popup in the bottom right corner of the page to let us know!

The tab “VCS” in Organization Settings has been renamed into “VCS Connections”, and it now includes a section dedicated to the GitHub App integration.

If the CircleCI GitHub App is not installed, it provides an overview of the functionality enabled by the App.

If the CircleCI GitHub App is installed, it shows which GitHub organization it’s connected to, and lets admin access the configuration page

The settings button redirects to the GitHub installation page. The delete button opens a modal which requires additional user input to confirm uninstallation of the GitHub App. Both actions are restricted to organization admins only.

The queue orb was previously used to avoid multiple pipeline race conditions and conflicts. Serial-job provides native support for the functionality provided by the queue orb. Overtime we will expand the use cases we support to cover additional challenges like multi-job or workflows. The first release is serial-group for individual jobs.

This allows an individual job to be serialized across the organization, project or branch based on the parameters you provide. Serialization will ensure the jobs are executed in the order in which the pipelines are started via commit, api or other triggering method.

To learn more about your options see the documentation.

A growing number of GitHub OAuth customers have been looking to stop building their OAuth pipelines in favour of the new GitHub App pipelines which provide a broader range of triggering options.

This is currently a manual process, which requires making changes in GitHub.

To avoid users having to refer to the docs for instructions, we added a “delete” icon next to the OAuth trigger (Project Settings > Triggers), which opens a modal containing instructions for how to disable the OAuth trigger manually.

It is now possible to configure pipelines to be triggered only on pushes to non-draft Pull Requests.

Who Can Use This?

This functionality is available to all customers that use GitHub.

If your organization is currently integrated with GitHub only through OAuth, an admin must take the one-time action of installing the CircleCI GitHub App to enable this functionality.

Getting Started

1. Go to your project’s Project Settings > Pipelines, and ensure you have a “GitHub App” pipeline defined
2. Go to Project Settings > Triggers, and define a GitHub App trigger
3. In the “run on” menu, select “Pushes to open non-draft PRs”
4. Trigger your GitHub App pipeline by pushing to a non-draft PR

For more details on newly supported GitHub trigger events and example use cases, check out our documentation. For any questions or feedback, email benedetta@circleci.com.

The “Add Pipeline” form (Project Settings > Pipelines) now includes links to a Google Form that helps customers troubleshoot common issues related to GitHub App installation and permissions.

This bug has been fixed, and the note removed from the docs.

The “build forked pull request” setting in Project Settings > Advanced has been updated to clarify that it only applies to OAuth pipelines, not GitHub App pipelines.

This is an important clarification, given that organizations that use the GitHub OAuth App can now also run pipelines integrated via GitHub App to leverage new features.

The “only build pull request” setting in Project Settings > Advanced has been updated to clarify that it only applies to OAuth pipelines, not GitHub App pipelines.

This is an important clarification, given that organizations that use the GitHub OAuth App can now also run pipelines integrated via GitHub App to leverage new features.

The triggers table displayed in Project Settings > Triggers now includes two additional columns: “Pipeline to trigger” and “events”.

• Pipeline to trigger indicates the name of the pipeline associated with each trigger
• Events indicates which trigger events will cause the pipeline to run (e.g. “All pushes”, “PR opened”, “PR merged”, …)

Runner Release 3.1.2

Container Runner:

• Set resource requirements (requests and limits) on the orchestrator init container (https://github.com/circleci/runner-init). This change helps ensure the Pod is schedulable when resource quotas are applied.
• Added options to configure the image name for the orchestrator container. This can be used for hosting the image in a private registry or within an air-gapped environment on CircleCI server. Note this change requires version v101.1.3 of the Helm chart.

Pipelines can now be triggered on a wider range of GitHub events, including pull request events, giving you more control over when your builds run.

The full range of trigger options available are:

• All pushes
• Tag pushes
• Pushes to default branch
• PR opened or pushed to, default branch pushes, tag pushes
• PR opened
• PR merged
• PR marked ready for review
• “run-ci” label added to PR

This allows teams to trigger builds only when needed, reducing unnecessary spending.

Customizing Triggers for Different Pipelines

This functionality can be leveraged to configure different pipelines in the same project to run on specific events. For example:

• A “build-test-deploy” pipeline (config.yml) runs on “all pushes”
• A “benchmark” pipeline (benchmark.yml) runs on “PR opened”
• A “cleanup” pipeline (teardown-env.yml) runs on “PR merged”

We plan to expand the available events and conditions to choose from. Let us know what additional triggers your team needs by filling out this form, so we can prioritize adding them next.

Who Can Use This?

This functionality is available to all customers that use GitHub. If your organization is currently integrated with GitHub only through OAuth, an admin must take the one-time action of installing the CircleCI GitHub App to enable this functionality.

Getting Started

1. Go to your project’s Project Settings > Pipelines, and ensure you have a “GitHub App” pipeline defined
2. Go to Project Settings > Triggers, and define a GitHub App trigger
3. In the “run on” menu, select your preferred event
4. Trigger your GitHub App pipeline by performing the selected action on GitHub.

For more details and example use cases, check out our documentation.

For any questions or feedback, email benedetta@circleci.com.

Github App organizations can now take advantage of Github Checks. Customers often use GitHub checks to verify and validate that specific jobs or workflows have been completed before taking action like merging code.

GitHub App support within CircleCI allows customers to have multiple “pipelines” defined within a single project. Github doesn’t share this same capability or concept when it comes to GitHub Checks. GitHub checks the workflow name is the key and if workflows in two different pipelines share the same name they would overwrite each other’s status. CircleCI had to introduce a way to ensure that status updates were unique and identifiable by workflow across pipelines. Because of this, we introduced a pipeline definition ID in the workflow name for GitHub Checks for GitHub App integrations. These are non-mutable and allow the organization to build GitHub Check rules that are name-based.

NOTE: Some customers have both Github App and GitHub OAuth enabled on their application and may have both Github Status and GitHub checks enabled. Those customers will see GitHub Check updates for the GitHub App integration.

Runner Release 3.1.1

Container Runner:

• Fixed the volume for GOAT and task-agent binaries to be read-write. It was unnecessarily read-only and caused issues with the circleci-cli orb, which overwrites the circleci symlink with the CLI.

Runner Release 3.1.0

Container Runner:

• Version 3.1.0 introduces substantial performance and reliability improvements to container runner. These updates are designed to enhance the overall efficiency and stability of operations at scale. For more background and technical details on these changes, you can visit our Runner Init repository and documentation.
• To upgrade, ensure that the Helm chart is at least version v101.1.2. The chart is pinned to the major version tag of the runner, enabling automatic upgrades on redeployment. If you wish to remain on the existing architecture (3.0.x), you can do so by setting the tag to kubernetes-3.0. This version will continue to receive only critical bug fixes and security patches. You can check the configuration details in the Helm chart repository.