Code Monkey home page Code Monkey logo

trigger-circleci-pipeline-action's Introduction

Note

This GitHub Action does not yet support CircleCI projects that are integrated with the CircleCI GitHub App. If your CircleCI project URL looks like this: https://app.circleci.com/projects/organizations/circleci%, you are integrating with the CircleCI GitHub App and this GitHub Action is not yet supported. Contact [email protected] with any questions/feedback. If your CircleCI project URL looks like this: https://app.circleci.com/projects/project-dashboard/github/, you are using CircleCI's OAuth App integration and this GitHub Action is supported.

Trigger CircleCI Pipeline

Trigger your CircleCI pipelines from any event on GitHub with GitHub Actions.

How to Use

  1. Create a GitHub Action's workflow for the desired CircleCI pipeline.

    Do this by adding a workflow YAML file (we'll use main.yml) to ./.github/workflows.

    A release trigger is shown in this example. Try any of the GitHub events for triggering workflows: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows

    Select a custom name and id for the step for additional contextual metadata in your CircleCI pipeline

on:
  release:
    types: [published]
jobs:
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: <customize name>
        id: <customize id>
        uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}
  1. Create an encrypted secret named CCI_TOKEN containing the Personal API Token that will be used to trigger the pipelines. This is suggested to be a machine user.

  2. Add the Pipeline Parameter definitions to your CircleCI config. This data will be entered by the GitHub Action when triggered.

    Add the following to the top of your .circleci/config.yml file. Ensure you are specifying version 2.1

    version: 2.1
    parameters:
      GHA_Actor:
        type: string
        default: ""
      GHA_Action:
        type: string
        default: ""
      GHA_Event:
        type: string
        default: ""
      GHA_Meta:
        type: string
        default: ""
  3. Use the Pipeline Parameter data to run workflows conditionally.

    See: Examples

Inputs

Optional input parameters that allow you to specify additional metadata.

GHA_Meta

required: false

description: An optional additional metadata parameter. Will be available on the CircleCI pipeline as GHA_Meta.

jobs:
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: <customize name>
        id: <customize id>
        uses: CircleCI-Public/[email protected]
        with:
          GHA_Meta: "<custom data>"
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

target-slug

required: false

description: The CircleCI project slug of the target project (ex: github/<org>/<repo>). If not specified, the slug of the current GitHub repository will be used.

jobs:
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: <customize name>
        id: <customize id>
        uses: CircleCI-Public/[email protected]
        with:
          target-slug: "gh/<org>/<repo>" # Will trigger the pipeline for external project
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

Outputs

Field Data Type Description
id string (uuid) The unique ID of the pipeline.
state string (Enum: "created" "errored" "setup-pending" "setup" "pending") The current state of the pipeline.
number integer (int64) The number of the pipeline.
created_at string (date-time) The date and time the pipeline was created.

Things To Know

GitHub Actions runs alongside native CircleCI integration.

By default, when a repository is connected to CircleCI, if the workflows within that project's configuration does not specify any conditionals or filters that would otherwise prevent execution, the workflow will execute on every push event by default.

This may mean it is possible to accidentally run a job twice, once on the push event from CircleCI, as well as other events triggered by the GitHub Action.

To prevent double execution

If you are relying on GitHub Actions to provide all of your API triggers, ensure that each of your CircleCI configuration's workflows contains a conditional limiting it's execution to only the GitHub Action trigger.

Example

workflows:
  # This workflow is set to be conditionally triggered,
  # only via the GitHub Action.
  # With no other unfiltered workflows, normal push events will be ignored.
  test:
    when: << pipeline.parameters.GHA_Action >>
    jobs:
      - test

trigger-circleci-pipeline-action's People

Contributors

bjohnso5 avatar circleci-secops avatar headfox avatar jsirois avatar kelvintaywl avatar kyletryon avatar mattlewis92 avatar nick-fields avatar nrakochy avatar pepesenaris avatar peterhewat avatar rosieyohannan avatar sebastian-lerner avatar whatisdot avatar zackse avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

trigger-circleci-pipeline-action's Issues

Request: `pull_request_target` support

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

This GitHub action requires access to a CCI_TOKEN. Because of GitHub's security, forks do not have access to secrets. So the CircleCI job will not trigger when the pull_request event is used:

Failed to trigger CircleCI Pipeline
  Error: Error: Request failed with status code 403
  Error: Request failed with status code 403

To resolve this, I thought of using the pull_request_target event, where CI runs with the base of the branch so secrets can be securely shared. Then checking out the HEAD of the PR to trick CircleCI into using this ref:

on:
- pull_request: 
+ pull_request_target:

jobs:
  # https://github.com/marketplace/actions/trigger-circleci-pipeline
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
+     - uses: actions/checkout@v3
+       with:
+         ref: ${{ github.event.pull_request.head.sha }}
      - uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

However, the triggering branch still points to master:

image

Describe the solution you'd like

Any suggestion on how to resolve this? I guess this logic would need to be adapted:

const ref = context.ref;
const headRef = process.env.GITHUB_HEAD_REF;
const getBranch = () => {
if (ref.startsWith("refs/heads/")) {
return ref.substring(11);
} else if (ref.startsWith("refs/pull/") && headRef) {
info(`This is a PR. Using head ref ${headRef} instead of ${ref}`);
return headRef;
}
return ref;
};

Teachability, documentation, adoption, migration strategy

An addition to the README would be sufficient.

What is the motivation / use case for changing the behavior?

It should work for forks.

Bug: Transcompiled Source Not Added With Commit Hook

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

The pre-commit hook transcompiles the ECMA scripts into JavaScript, but doesn't add it while the commit is in progress. I can't find any documentation or conversation about this, so it's unclear if this is intentional.

Minimum reproduction code

n/a

Steps to reproduce

  1. Checkout the main branch
  2. Run git checkout -b some-other-branch
  3. Make an edit to the index.js file and run git commit -am "make a source change" to run the pre-commit hooks

Expected behavior

???

The pre-commit hook suggests that the build should be included with the commit that is in progress, but it does not add the files in the dist/ directory.

GitHub Action Version

latest

Request: Set the user that initiated the trigger

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

No response

Describe the solution you'd like

I would like the ability to manually provide the user that triggered the GH Actions workflow run.

Currently the person that created the API key is attributed to the workflow run. I can see in the code that the x-attribution-actor-id header is being set but according to this that only works on your internal tools. I mention that because I considered using curl to trigger the workflow runs.

Teachability, documentation, adoption, migration strategy

Ideally would be an additional input that would provide us some flexibility on setting this value (possible for workflows to be triggered by bots) but would happy with it pulling the username from the github context.

What is the motivation / use case for changing the behavior?

Currently all the workflow runs that are triggered show as the person that generated the API key which is is confusing and doesn't look great for us when other teams use the tool.

Request: Additional Output - Workflow URL

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

No response

Describe the solution you'd like

I would like the action to have an additional output that is the URl to the workflow that is triggered.

Teachability, documentation, adoption, migration strategy

My workflow creates a comment on the PR that triggered the action and I would like to include a link to the workflow within CircleCI.

I am going to attempt to build the url from the existing outputs but I feel that will be prone to breaking.

What is the motivation / use case for changing the behavior?

Please see above

Request: Wait-for-pipeline input variable

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Although currently you could write up a requester that would query for the status of the job, e.g.:

      - name: Trigger CircleCI
        id: circle-ci
        uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}
      - name: Wait for CircleCI
        uses: mydea/action-wait-for-api@v1
        with:
          timeout: 3600
          url: https://circleci.com/api/v2/project/gh/owner/projectjob/${{ steps.circle-ci.outputs.number }}
          expected-status: 200
          expected-response-field: status
          expected-response-field-value: success

It is hard to generalize to check for other statuses like failed, etc.

Describe the solution you'd like

Instead it would be nice to have the code be re-used to wait for the pipeline to complete, e.g.:

      - name: Trigger CircleCI
        id: circle-ci
        uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}
        with:
          wait_for_pipeline: true

Bug: Triggering via issue_comment Action Kicks Off Workflow For Incorrect Commit/Branch

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

When I attempt to trigger a workflow in CircleCI from this GitHub Action on the created issue_comment event it works properly, but then starts the workflow on the incorrect branch within CircleCI. It appears to start the pipeline for the commit at HEAD of main rather than on the branch/commit in the Pull Request that triggered the action.

Minimum reproduction code

https://gist.github.com/jblacker/4f8b3d87b3b0b60a00c166e05d6ced81

Steps to reproduce

  1. Create a workflow pipeline in CircleCI using the conditions in the "other" section below
  2. Use the example in my gist to create a GitHub Action that triggers said pipeline on CircleCI
  3. Create a new branch that's not the default and open a PR
  4. Write the comment on the PR "/deploy-staging"
  5. Check CircleCI you'll see that it triggered main (or whatever your default is) rather than the head of the current branch of the PR.

Expected behavior

I would have expected the branch that the PR is for to be triggered in CircleCI.

GitHub Action Version

1.0.5

Other

Here's the trigger on the CircleCI side of things:

when:
      or:
        - and:
          - equal: [<<pipeline.parameters.deploy_branch>>, <<pipeline.git.branch>>]
          - equal: [<<pipeline.parameters.deploy>>, true]
        - and:
          - <<pipeline.parameters.GHA_Action>>
          - equal: [<<pipeline.parameters.GHA_Event>>, "issue_comment"]
          - equal: [<<pipeline.parameters.GHA_Meta>>, "DEPLOY_STAGING"]

Bug: Can not set GHA_Meta

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Fails when using setting the GHA_Meta input

 /home/runner/work/_actions/CircleCI-Public/trigger-circleci-pipeline-action/v1.0.2/dist/index.js:12739
    Object.assign("GHA_Meta", metaData);
           ^
  
  TypeError: Cannot assign to read only property '0' of object '[object String]'
      at Function.assign (<anonymous>)
      at /home/runner/work/_actions/CircleCI-Public/trigger-circleci-pipeline-action/v1.0.2/dist/index.js:12739:10
      at /home/runner/work/_actions/CircleCI-Public/trigger-circleci-pipeline-action/v1.0.2/dist/index.js:12772:3
      at Object.<anonymous> (/home/runner/work/_actions/CircleCI-Public/trigger-circleci-pipeline-action/v1.0.2/dist/index.js:12775:12)
      at Module._compile (internal/modules/cjs/loader.js:959:30)
      at Object.Module._extensions..js (internal/modules/cjs/loader.js:995:10)
      at Module.load (internal/modules/cjs/loader.js:815:32)
      at Function.Module._load (internal/modules/cjs/loader.js:727:14)
      at Function.Module.runMain (internal/modules/cjs/loader.js:1047:10)
      at internal/main/run_main_module.js:17:11

Minimum reproduction code

https://gist.github.com/pepesenaris/e069b56e42aefcc4c5a4f356782db519

Steps to reproduce

Just setting a value in GHA_Meta

Expected behavior

Allows to pass the GHA_Meta input key

GitHub Action Version

1.0.2

Other

No response

Request: How to trigger for a different branch

Is there an existing issue that is already proposing this?

Is your feature request related to a problem? Please describe it

# Circle CI will build master and all PRs anyway, we just need to trigger non-default branches
name: Trigger CircleCI Build on Beta and Release Branch

on:
  push:
   branches:
   - beta
   - release


jobs:
  trigger-build:
    runs-on: ubuntu-latest

    steps:
      - name: Trigger CircleCI
        id: trigger-circle-ci
        uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: ${{ secrets.CIRCLE_TOKEN }}

should trigger CircleCI for the Branch the GitHub Action was triggered for

Describe the solution you'd like

  • The action should have an option "current-branch:true" ajd determine the branch from the GItHub Event
  • Optional Parameter for the Action to set a branch manually

Teachability, documentation, adoption, migration strategy

...

What is the motivation / use case for changing the behavior?

Make GitHub Action & Circle CI Integration smooth

Bug: Getting error code 400 when calling circleci from github actions

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

On release publish we are triggering circleci from github actions, But sometime we are getting error code 400 when calling circleci from github actions, this is occurring randomly not every time,
After recreating the release it works fine.

This is happening because we are getting Triggering branch as empty string even though we trigger this github action on release publish, After republishing the release we are getting Triggering tag with tag value and works as expected.

Please refer to the screenshot- On the right side the job failed when release published Triggering branch is empty
On the left side job passed after recreating the release and published, we are getting Triggering tag with the actual tag value
screenshot1

We are using CircleCI-Public/[email protected] to trigger circleci from github actions

Minimum reproduction code

https://github.com/fundingasiagroup/indo-banking-service/blob/master/.github/workflows/release.yml

Steps to reproduce

When the release is published github actions are not triggered facing error code 400
https://github.com/fundingasiagroup/indo-banking-service/actions/runs/6389570633/job/17341892137

Expected behavior

Github action should trigger circleci job always as expected

GitHub Action Version

1.0.5

Other

No response

Bug: Branch name incorrect on pull_request evented actions

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Triggering branch: refs/pull/4781/merge

Minimum reproduction code

https://github.com/CircleCI-Public/trigger-circleci-pipeline-action

Steps to reproduce

No response

Expected behavior

Expect the branch name to be "correct". It must be obtained through different sources based on the event type that triggers the action:

https://www.techiediaries.com/get-current-branch-name-github-actions-github_ref-bash/

Further, sometimes it can be fetched from github.event.ref (for instance in the case of the delete event).

GitHub Action Version

1.0.4

Other

No response

Request: Add Test Cases

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Currently the only way to validate expected behavior is by running this action for a project. Given that most company projects are private, this creates challenges for sharing information on an initiative like this.

Describe the solution you'd like

By adding jest, we can write test cases for validating expected behavior.

Using CircleCI, we can add jobs to this project that run for each commit pushed. PRs can be configured to only allow merging if all checks in CircleCI pass.

Teachability, documentation, adoption, migration strategy

Increased reliability will inspire confidence in proposed features and released versions.

What is the motivation / use case for changing the behavior?

This will help reduce the risk of blocking defects making their way into a released version of the Action.

Request: Use refHead by default

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

When merging a PR, $GITHUB_REF contains the name of the target branch, not source branch, which can create inconsistency.

Describe the solution you'd like

It should be alright to use $GITHUB_HEAD_REF by default, if it is present of course. As the Github Actions documentation states :

GITHUB_HEAD_REF : The head ref  or source branch of the pull request in a workflow run. This property is  only set when the event that triggers a workflow run is either pull_request or pull_request_target. For example, feature-branch-1.

It seems to be a more reliable way of checking if we're in a PR than checking if $GITHUB_REF starts with refs/pull/...

Teachability, documentation, adoption, migration strategy

This will be the default behavior, so it should be stated in the doc, but no or almost no changes for the users since it covers only the case of merging a Pull Request

What is the motivation / use case for changing the behavior?

When you plug an action to the pull_request closed event, you expect the instructions to run on the source branch when your PR is closed, including when it's closed by merging the source branch.
The exemple in my case was the destruction of an ephemeral environment, based on the branch the PR is based on. So, when merging the branch, the destroyed environment is the one corresponding to the source branch (main, for example), which shouldn't be destroyed.

Also, I think it's not right to have such an inconsistency in the different behaviors (which is mostly caused by github actions, I agree on this).

Request: Commit Message not displayed in CircleCI (unlike native GitHub integration where commit messages are displayed)

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

When I execute workflows via GitHub Actions, it does not display the commit message, like it does when I execute with the direct integration. You can see both here:

2024-02-06_10-52-54

Describe the solution you'd like

I'd like to see the commit message, not just the git hash to identify what code is being tested.

Teachability, documentation, adoption, migration strategy

Ideally, users would just start to see the commit message as they do in the direct integration.

What is the motivation / use case for changing the behavior?

This will help users more quickly identify what is being tested, rather than forcing them to check their git log to see which commit SHA corresponds to which commit message.

Request: Ability to approve circleci jobs

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

No response

Describe the solution you'd like

Can we also have the ability to auto approve workflows based on github events as well? For example, we have the following workflow:

workflows:
  version: 2
  build:
    jobs:
      - server_unit_tests
      - server_integration_test
      - frontend_tests
      - e2e_tests_trigger:
          type: approval
      - e2e_tests:
          requires:
            - e2e_tests_trigger

Instead of triggering the pipeline, can we also have this action auto approve based on github actions? My goal is to have the job auto approve based on a label merge

Teachability, documentation, adoption, migration strategy

on:
  pull_request:
    types: [labeled]
jobs:
  trigger-circleci:
    if: ${{ github.event.label.name == 'merge' }}
    runs-on: ubuntu-latest
    steps:
      - name: <customize name>
        id: <customize id>
        uses: CircleCI-Public/[email protected]
        with:
          - APPROVAL_TRIGGER=e2e_tests_trigger
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

What is the motivation / use case for changing the behavior?

Need a way for merge queues to be able to auto trigger circleci approval jobs

Bug: Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: CircleCI-Public/[email protected]. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Minimum reproduction code

https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/

Steps to reproduce

No response

Expected behavior

New updated node

GitHub Action Version

1.1.0

Other

No response

Request: Allow to specify API version for triggering URL `url`

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

I am trying to use trigger-circleci-pipeline-action to trigger my pipeline with my private API endpoint.

Though I could set CCI_HOST succesfully, still got 404.

Later I found my private API endpoint is like https://circleci.xxx.com/api/v1.1/project/gh/[ORG]/[REPO]/pipeline

And found this line fixed the version as v2 for the triggering URL. It seems that there is no way to set my private endpoint as triggering url for now.

const url = `https://${host}/api/v2/project/gh/${repoOrg}/${repoName}/pipeline`;

Describe the solution you'd like

Is it possible to add a new env variable like CCI_VER?

Or maybe a env variable CCI_URL to allow user to set the complete endpoint?

Teachability, documentation, adoption, migration strategy

    steps:
      - name: Trigger Cicle CI Building Pipeline
        id: trigger_building_pipe
        uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: $
          # or CCI_VER: v1.1
          CCI_URL: https://circleci.xxx.com/api/v1.1/project/gh/[ORG]/[REPO]/pipeline

What is the motivation / use case for changing the behavior?

Support private endpoint more generally

Bug: Wrong description in the setup guide about trigger name

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

The current documentation uses old names that misguide people to encounter error while using this action.

Minimum reproduction code

https://github.com/CircleCI-Public/trigger-circleci-pipeline-action

Steps to reproduce

Just follow the setup guide given by this repo or at the github action marketplace.

Expected behavior

Replace to use the correct names.

- name: Trigger CircleCI Pipeline
  uses: CircleCI-Public/[email protected]

GitHub Action Version

1.0.2

Other

No response

Request: Define Outputs

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Triggering a pipeline works as expected, but there's no way to consume and use the response in following steps. To do that, we need the action to define outputs for the job.

Describe the solution you'd like

Descriptions taken from the CircleCI API documentation:

outputs:
  id:
    description: The unique ID of the pipeline.
  state:
    description: The current state of the pipeline.
  number:
    description: The number of the pipeline.
  created_at:
    description: The date and time the pipeline was created.

Teachability, documentation, adoption, migration strategy

Descriptions taken from the CircleCI API documentation.

Outputs

Field Data Type Description
id string (uuid) The unique ID of the pipeline.
state string (Enum: "created" "errored" "setup-pending" "setup" "pending") The current state of the pipeline.
number integer (int64) The number of the pipeline.
created_at string (date-time) The date and time the pipeline was created.

What is the motivation / use case for changing the behavior?

Adds a backwards-compatible feature that enables teams to use the pipeline ID and date created in downstream workflow actions.

Bug: Unexpected argument(s): GHA_Actor, GHA_Event, GHA_Tag, GHA_Action

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

After having encountered the same issues as described here: #2 and #4, I finally got my github action to trigger my CircleCI workflow.

Unfortunately, my CircleCI workflow then gives me the following error:

Unexpected argument(s): GHA_Actor, GHA_Event, GHA_Tag, GHA_Action

circleci_parameters_error

Minimum reproduction code

https://github.com/CircleCI-Public/trigger-circleci-pipeline-action

Steps to reproduce

  1. Follow the example 02-Trigger-Workflow-On-Release but update the action as described in #2
  2. Create a release to trigger the workflow.

Expected behavior

No errors should occur in the CircleCI Workflow, the parameters should be the ones forwarded by the GitHub Action.

GitHub Action Version

1.0.2

Other

No response

Bug: Node 12

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Warnings by GitHub Actions are telling me that CircleCI-Public/[email protected] is still using Node 12 which Actions is deprecated and requires Node 16.

Attached Screenshot
Screenshot 2023-03-07 at 13 12 02

Minimum reproduction code

no url public

Steps to reproduce

  1. Create a workflow that depends on CircleCI-Public/[email protected]
  2. Execute workflow

Expected behavior

To not have any deprecation warnings and be able to use newer versions of Node.

GitHub Action Version

1.0.6

Other

No response

Bug: ref not being persisted after checkout

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Triggering a CircleCI job against an opened PR sends over a SHA1 ref that CircleCI can't find.

Minimum reproduction code

https://github.com/tmountjr/l0-express

Steps to reproduce

  1. Create new branch (feature-1) and commit code. GH action not run.
  2. Create PR from feature-1 to main. GH action is run and successfully triggers CircleCI.
  3. CircleCI run fails with the following message:
Using SSH Config Dir '/home/circleci/.ssh'
git version 2.35.1
Cloning git repository
Cloning into '.'...
Warning: Permanently added the ECDSA host key for IP address '140.82.113.3' to the list of known hosts.
remote: Enumerating objects: 25, done.        
remote: Counting objects: 100% (25/25), done.        
remote: Compressing objects: 100% (14/14), done.        
remote: Total 25 (delta 5), reused 24 (delta 4), pack-reused 0        
Receiving objects: 100% (25/25), 103.51 KiB | 20.70 MiB/s, done.
Resolving deltas: 100% (5/5), done.
Checking out branch
fatal: reference is not a tree: 7c9319c338312cd6720fc85e0d05263a65172370

exit status 128

$CIRCLE_SHA1 is set to 7c9319c338312cd6720fc85e0d05263a65172370 but that ref does not exist on the repo (running git log doesn't show that). I believe that ref is generated by the "fetch" phase of the checkout action with this command (taken from the details of the successful GH action):

/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +7c9319c338312cd6720fc85e0d05263a65172370:refs/remotes/pull/1/merge

Expected behavior

Either the checkout phase of the CircleCI pipeline should use the refs/pull/1/merge ref directly rather than a hash, or the GH action should commit the new ref to the repo (if possible) or send over a different SHA1 so that the CircleCI pipeline can use $CIRCLE_SHA1 properly.

Worth noting that, after the Circle run failed and I restarted with SSh, when I run the git fetch command from the GH pipeline in the SSH container the git checkout --force -B "$CIRCLE_BRANCH" "$CIRCLE_SHA1" command succeeds.

GitHub Action Version

1.0.4

Other

CircleCI config.yml file:

version: 2.1

parameters:
  GHA_Actor:
    type: string
    default: ""
  GHA_Action:
    type: string
    default: ""
  GHA_Event:
    type: string
    default: ""
  GHA_Meta:
    type: string
    default: ""

jobs:
  show_env_vars:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - run:
          name: echo CIRCLE_PULL_REQUEST
          command: echo $CIRCLE_PULL_REQUEST
      - run:
          name: echo CIRCLE_PULL_REQUESTS
          command: echo $CIRCLE_PULL_REQUESTS
      - run:
          name: echo CIRCLE_TAG
          command: echo $CIRCLE_TAG
      - run:
          name: echo GH_META
          command: echo $GH_META
      - run:
          name: echo CIRCLE_BRANCH
          command: echo $CIRCLE_BRANCH
      - run:
          name: echo CIRCLE_SHA1
          command: echo $CIRCLE_SHA1
      - run:
          name: run git log
          command: git log

workflows:
  version: 2.1
  build_and_deploy:
    jobs:
      - show_env_vars:
          filters:
            tags:
              only: /^v\d+.*/
            branches:
              only: /.*/

Output of the git log command from a failed run (restarted with SSH):

commit a7decbb6888239afabedff6d7e309df133578208 (HEAD -> main, origin/main, origin/HEAD)
Author: Tom Mount <[email protected]>
Date:   Fri May 13 10:10:10 2022 -0400

    add sha1 and git log commands

commit c78dde9ddaed52c9c34b2df64b3442f58b1c67c3
Author: Tom Mount <[email protected]>
Date:   Fri May 13 10:09:09 2022 -0400

    push up pipelines

commit 8838f6fadd4d1ae02612be942346ce9f68348133
Author: Tom Mount <[email protected]>
Date:   Thu May 12 17:28:44 2022 -0400

    initial commit

Bug: Major reference is not resolvable

It is common for Github actions to be able to reference by the major/major.minor versions, e.g.:

  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger CircleCI
        uses: CircleCI-Public/trigger-circleci-pipeline-action@v1

However tags or branches for v1 and v1.1 are missing

Bug: CircleCI checkout fails when triggered on pull_request_review

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

I am not 100% sure this is a bug or perhaps more of a feature-request, but am filing an issue on behalf of a customer ๐Ÿ™‡

Given the following Github workflow config:

name: Trigger CircleCI

on:
  pull_request_review:
    types: [submitted]
jobs:
  trigger-circleci:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - name: on PR review
        id: circleci_on_github_pr_review
        uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

When a PR is approved, this GitHub Action is triggered.
However, we see the following error on the subsequent CircleCI pipeline when checkout as the branch value for TriggerPipeline API is refs/pull<PR number>/merge:

Checking out branch
fatal: reference is not a tree: 74f97585e2e344a232fa48ea118bedf8ee6fd94f

exit status 128

Ref: https://app.circleci.com/pipelines/github/kelvintaywl-cci/circleci-gha-explore/8/workflows/cddf2112-2c4a-4828-986a-97dca5cb6e15/jobs/3?invite=true#step-101-81

Based on the TriggerPipeline API documentation, I wonder if the branch value should be:

- refs/pull/<PR number>/merge
+ pull/<PR number>/merge

Minimum reproduction code

kelvintaywl-cci/circleci-gha-explore#2

Steps to reproduce

No response

Expected behavior

I am expecting that the CircleCI pipeline's job to be able to checkout successfully.

GitHub Action Version

1.0.5

Other

No response

Request: Example of triggering CircleCI when adding a label to a pull request

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

It would be nice to add more examples shown.
In particular, I think it may be nice to show other examples beyond the usual actions.

Describe the solution you'd like

Hence, as an example (no pun intended), it may be nice to share an example of triggering CircleCI pipelines when a PR label is added.

Teachability, documentation, adoption, migration strategy

Shares with users how to set up such cases.

What is the motivation / use case for changing the behavior?

Extend the usage examples of this GitHub Action for triggering CircleCI pipelines.

Request:

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Currently it doesn't report the status of triggered pipeline (different repo, different branch) on my github PR (similar to github checks).

May I know if there is any way to also report the status on github PR?

Describe the solution you'd like

Would like to see the result of triggered pipeline on github PR

Teachability, documentation, adoption, migration strategy

NA

What is the motivation / use case for changing the behavior?

It will help to see the reports of triggered pipeline & take necessary action.

Bug: Example in documentation causes yaml error

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

This example shown in the documentation on how to avoid double execution does not work:

workflows:
  # This workflow is set to be conditionally triggered,
  # only via the GitHub Action.
  # With no other unfiltered workflows, normal push events will be ignored.
  when: << pipeline.parameters.GHA_Action >>
  test:
    jobs:
      - test

It causes the CircleCI pipeline to fail with:

#!/bin/sh -eo pipefail
# ERROR IN CONFIG FILE:
# [#/workflows/when] only 0 subschema matches out of 2
# 1. [#/workflows/when] expected type: Mapping, found: String
# |   SCHEMA:
# |     type: object
# |   INPUT:
# |     << pipeline.parameters.GHA_Action >>
# 2. [#/workflows/when] subject must not be valid against schema {\"description\":\"cannot use both 'when' and 'unless'\",\"allOf\":[{\"required\":[\"when\"]},{\"required\":[\"unless\"]}]}
# |   SCHEMA:
# |     not:
# |       description: cannot use both 'when' and 'unless'
# |       allOf:
# |       - required:
# |         - when
# |       - required:
# |         - unless
# |   INPUT:
# |     << pipeline.parameters.GHA_Action >>

Minimum reproduction code

https://gist.github.com/realnc/796e8302d6e546c95fd4e274b9686091

Steps to reproduce

No response

Expected behavior

when: << pipeline.parameters.GHA_Action >> should prevent the workflow from running rather than resulting in the pipeline to fail.

GitHub Action Version

1.0.4

Other

No response

Bug: No CCI_HOST Causes Error

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

#42 introduced an environment variable CCI_HOST that can be used to change the hostname for requests to something other than circleci.com.

After attempting to use the latest version of the action, we encounter an error if CCI_HOST is not defined as an env in the action:

Preparing CircleCI Pipeline Trigger
Org: [REDACTED]
Repo: [REDACTED]
Triggering CircleCI Pipeline for [REDACTED]
Triggering URL: https://undefined/api/v2/project/gh/[REDACTED]/[REDACTED]/pipeline
Triggering branch: main
Parameters:
{"GHA_Actor":"whatisdot","GHA_Action":"run-deployment-steps","GHA_Event":"workflow_dispatch","GHA_Meta":"qa1"}
Failed to trigger CircleCI Pipeline
Error: Error: getaddrinfo EAI_AGAIN undefined
Error: getaddrinfo EAI_AGAIN undefined

Minimum reproduction code

(no changes required)

Steps to reproduce

  1. Update the GitHub Action reference to the main branch
  2. Trigger a build that uses the action

Expected behavior

The action should default to using circleci.com for the API host name.

GitHub Action Version

main branch

Request: Add ability to trigger another org's circleci pipeline

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

No response

Describe the solution you'd like

It seems like the current implementation is parsing repoOrg and repoName from the payload's repository URL and using those to invoke circleCI's v2 endpoint

// https://github.com/CircleCI-Public/trigger-circleci-pipeline-action/blob/main/dist/index.js#L12707
const [, , repoOrg, repoName] = pattern.exec(payload.repository.url);
...
...
// https://github.com/CircleCI-Public/trigger-circleci-pipeline-action/blob/main/dist/index.js#L12755
const url = `https://circleci.com/api/v2/project/gh/${repoOrg}/${repoName}/pipeline`;

Allow a user to optionally specify REPO_ORG and REPO_NAME as the job's env variables which would take precedence over the default parsing.

on:
  pull_request:
    types: [opened, reopened, synchronize, assigned, edited]
jobs:
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: CircleCI Trigger on Pull Request
        id: <customize id>
        uses: CircleCI-Public/[email protected]
        env:
          REPO_ORG: "organization-name"
          REPO_NAME: "repo-name"
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

Teachability, documentation, adoption, migration strategy

REPO_ORG and REPO_NAME are optional env variables that you can pass in as env variable to the job
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsenv

What is the motivation / use case for changing the behavior?

This action links two tools, which is more likely to be prevalent on teams that work across different github orgs.

Request: Allow triggering without setting GHA_* parameters

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

I'm using this action to implement "start a CircleCI build on a branch when a PR is opened" (similarly to this StackOverflow answer). I'd like this to work with my existing build without needing to add four parameters whose values I plan to completely ignore. Would it be possible to add a boolean flag that lets me say "don't send the parameters" so I don't have to edit my config.yml in every repo where I plan to use this? I'm happy to implement this myself if it would be expected.

Sorta related to #5.

Describe the solution you'd like

A new action input like include-gha-parameters with a default of true, where if you set it to false the parameters are not included.

Teachability, documentation, adoption, migration strategy

The input can be documented in the README.

What is the motivation / use case for changing the behavior?

I don't need these parameters and would like to be able to use this action without changing the CircleCI config in my repos.

Bug: Triggering pipeline returns 404; but green on CCI

Is there an existing issue for this?

  • I have searched the existing issues

Current behavior

Right now I am changing our CCI setup to trigger through a GH Action. This is to allow us to disable these system tests via a specific label. Now, this appears to be working for anything that runs directly on GH.

Using the action from this repo (Also upgraded manually to 1.1, please refactor the example!), I have changed our config.yml file to check if GH_Action matches. This appears to work; as now the tests don't run, and my new job that checks if it doesn't match runs succesfully:
image

Now my problem is that, the only reason these fail, is because the action itself returns a 404...
image

The action setup is as simple as it gets:

name: Run CircleCi tests
on:
  pull_request:
    types: [opened, synchronize, reopened]
jobs:
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: run system tests
        id: cci_system_tests
        uses: CircleCI-Public/[email protected]
        env:
          CCI_TOKEN: ${{ secrets.CIRCLE_CI_TOKEN }}

So I am not entirely sure how this is supposed to work.

Minimum reproduction code

Please see above

Steps to reproduce

No response

Expected behavior

It should correctly trigger the test with the right parameters, so that it can run the tests, and report back in the PR action if they are passing or not.

GitHub Action Version

1.1.0

Other

No response

Request: Allow pointing to private circleci endpoint

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

When triggering a workflow the action wants to hit a static endpoint set at

const url = `https://circleci.com/api/v2/project/gh/${repoOrg}/${repoName}/pipeline`;
.

Describe the solution you'd like

It would nice to be able to override this URL for use in private enterprise situations where a circleci instance is hosted privately.

Teachability, documentation, adoption, migration strategy

NA

What is the motivation / use case for changing the behavior?

The motivation is to be able to use this useful action in a private github repo/circleci scenario.

Request: CCI_Context Parameter

Is there an existing issue that is already proposing this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe it

Currently, there is no way for us to specify the CircleCI Context when triggering a pipeline with this Action. It's possible to set a string representing the name of the CircleCI Context in the GHA_Meta parameter when triggering the pipeline, but that prevents us from sending any additional data through to the workflows.

Describe the solution you'd like

An additional optional parameter named CCI_Context that, when set, will add this parameter to the POST request that triggers the CircleCI Pipeline. This is then used to set the name of the CircleCI Context.

action.yml

We would need an additional input defined:

inputs:
  # ...
  CCI_Context:
    required: false
    description: 'An optional CircleCI context to use when running jobs. Will be available on the CircleCI pipeline as CCI_Context.'

src/lib/CircleCIPipelineTrigger.ts

We adjust this to get a new input and add it to the list of parameters when it is present:

    # (constructor)
    this.cciContext = getInput("CCI_Context");

    # (triggerPipeline)
    if (this.cciContext.length > 0) {
      this.parameters.CCI_Context = this.cciContext;
    }

Teachability, documentation, adoption, migration strategy

Migration Strategy

Since the parameter is optional, teams would only need to opt-in to using it in a newer version of this Action.

Documentation

The following changes could be made to the README.

(under the "How to use" section)

  1. Add the Pipeline Parameter definitions to your CircleCI config. This data will be entered by the GitHub Action when triggered.

    Add the following to the top of your .circleci/config.yml file. Ensure you are specifying version 2.1

    version: 2.1
    parameters:
      GHA_Actor:
        type: string
        default: ""
      GHA_Action:
        type: string
        default: ""
      GHA_Event:
        type: string
        default: ""
      GHA_Meta:
        type: string
        default: ""
      CCI_Context:
        type: string
        default: ""

(under the "Inputs" section)

CCI_Context

required: false

description: An optional CircleCI context to use when running jobs. Will be available on the CircleCI pipeline as CCI_Context.

jobs:
  trigger-circleci:
    runs-on: ubuntu-latest
    steps:
      - name: <customize name>
        id: <customize id>
        uses: CircleCI-Public/[email protected]
        with:
          CCI_Context: protected-context-name
        env:
          CCI_TOKEN: ${{ secrets.CCI_TOKEN }}

What is the motivation / use case for changing the behavior?

Keys/secrets in CircleCI could be exposed in certain scenarios:

  1. Bad actor commits a change to expose service account keys/secrets in CircleCI when the workflow is ran.
  2. Bad actor pushes commit and triggers the pipeline with their branch, exposing the secret.
  3. Bad actor takes the secret and runs additional operations for bad actor purposes.
  4. Operations are successful until admins are made aware and roll the token.

OpenID Connect (OIDC) solves this issue by introducing a trust relationship between two services, so that only a public key is shown when making service-to-service communication. This would address the issue, but currently CircleCI does not have an OIDC provider to accept inbound requests.

We could use CircleCI Context names in combination with GitHub Environments and GitHub branch protection rules to isolate the service account that is allowed to perform operations on specific GitHub Environments.

  1. Bad actor commits a change to a GitHub Action that tries to expose a service account key/token/secret in CircleCI when it is ran.
  2. Bad actor pushes commit and tries to trigger the pipeline via GitHub Action in their branch.
  3. Results in failure when the GitHub Environment uses protected branches.

(or)

  1. Bad actor commits a change to a GitHub Action that tries to expose a service account key/token/secret in CircleCI when it is ran.
  2. Bad actor pushes commit that tries to run sensitive actions in CircleCI with the protected CircleCI Context name.
  3. Results in failure because the (non protected) GitHub Environment CCI_TOKEN does not have permission to use the CircleCI Context.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.