Skip to content

Ability to fallback to a different branch on failure #105

Closed
@znarf

Description

@znarf

This is a feature request. Because it's an advanced feature, I understand that it might not be directly implemented but some smaller features would unlock it.

Use case

At Open Collective, we have 2 main repositories, one for our API and one for our Frontend. In our CI, we have e2e tests which are requiring a checkout of both API and Frontend to run.

  • In the most simple scenario, we run a checkout of master in both projects
  • In the most common scenario, we run the e2e tests on feature branches of the API, and they run fine with the master Frontend because they don't require any modifications of the Frontend
  • In an advanced scenario, if a feature needs a modification on both API and Frontend, we're using by convention the same exact branch name on API and Frontend (ie: feat/new-events-page) and we want the e2e test to use checkouts of these branches.

Status Quo

We're using some magic script that is implementing the functionality using downloaded tarballs (didn't write that!) .
https://github.com/opencollective/opencollective-api/blob/master/scripts/ci_checkout_frontend.sh

GitHub Actions to the rescue

We would like to use a nicely written GitHub Action for that. My initial implementation would be:

      - name: Checkout (frontend - matching branch)
        uses: actions/checkout@v2-beta
        with:
          repository: opencollective/opencollective-frontend
          path: opencollective-frontend
          ref: ${{ github.ref }}

      - name: Checkout (frontend - master)
        if: failure()
        uses: actions/checkout@v2-beta
        with:
          repository: opencollective/opencollective-frontend
          path: opencollective-frontend
          ref: master

opencollective/opencollective-api#3031
https://github.com/opencollective/opencollective-api/pull/3031/checks?check_run_id=343540511

It's almost working but unfortunately the first command is sending a CI failure and we can't proceed normally after.

Feature Request

  1. Ability to skip the failure signal if the checkout doesn't work
      - name: Checkout (frontend - matching branch)
        uses: actions/checkout@v2-beta
        with:
          repository: 'opencollective/opencollective-frontend'
          ref: ${{ github.ref }}
          silentFailure: true
  1. Ability to know if the checkout with a given id failed
      - name: Checkout (frontend - matching branch)
        uses: actions/checkout@v2-beta
        id: checkout-matching-branch
        with:
          repository: 'opencollective/opencollective-frontend'
          ref: ${{ github.ref }}
          silentFailure: true

      - name: Checkout (frontend - master)
        if: steps.checkout-matching-branch.outputs.failure === 'true'
        uses: actions/checkout@v2-beta
        with:
          repository: 'opencollective/opencollective-frontend'
          ref: master

Activity

changed the title [-]Ability to fallback on a different branch on failure[/-] [+]Ability to fallback to a different branch on failure[/+] on Dec 11, 2019
chrispat

chrispat commented on Dec 12, 2019

@chrispat
Member

@znarf You can always set continue-on-error for the step and a failure will not cause the overall workflow to fail https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error.

For the second item we do have a feature on the backlog (no current timeframe) to have the outcome of a step be part of the steps context.

znarf

znarf commented on Dec 12, 2019

@znarf
Author

@chrispat Thank you for pointing on continue-on-error, I missed that. That could effectively replace the first item.

For the second item, I guess that should not be complicated to implement, I shared a proof of concept as Pull Request, let me know what you think.

chrispat

chrispat commented on Dec 12, 2019

@chrispat
Member

@znarf the second item is not something that really should be implemented in a single action, it would need to be implemented in the runner so it is consistently applied to all actions. We do have a feature on our backlog to add steps.<step id>.outcome to the context.

znarf

znarf commented on Dec 12, 2019

@znarf
Author

@chrispat all right, let me know if there is an open issue so I can have a look.

chrispat

chrispat commented on Dec 12, 2019

@chrispat
Member

@znarf unfortunately those issues are not in a public repo.

znarf

znarf commented on Dec 12, 2019

@znarf
Author

@chrispat Would the work be in https://github.com/actions/toolkit ? If yes, which of the packages https://github.com/actions/toolkit/tree/master/packages would be affected?

chrispat

chrispat commented on Dec 17, 2019

@chrispat
Member

@znarf the work has to happen in the runner which is they only place where state is stored between executions of different actions.

self-assigned this
on Jan 10, 2020
ericsciple

ericsciple commented on Jan 10, 2020

@ericsciple
Contributor

this should be a small change. i'll open an ADR soon.

11 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    Participants

    @znarf@mfn@chrispat@ximon18@negebauer

    Issue actions

      Ability to fallback to a different branch on failure · Issue #105 · actions/checkout