Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make action more composable #181

Open
20k-ultra opened this issue Jul 8, 2022 · 6 comments
Open

Make action more composable #181

20k-ultra opened this issue Jul 8, 2022 · 6 comments

Comments

@20k-ultra
Copy link
Contributor

The goal of this action was to use draft releases but that requires this action only run on specific events. If we make the action more composable, people can use it for more workflows (events) than just push to master and pull requests.

The following is a solution that should allow people to make workflows that push final releases on any event and still allow you to make draft releases than finalize on another event...right now this is hard coded to only work on pull requests but below I outline how we can do it with any event.

By adding a new input finalize: boolean and not enforcing which events cause the action to finalize the user can craft a workflow to make a draft and than finalize on any combination of events. You can make a workflow file to:

  • push to master -> make a finalized release
  • tag commit -> make a finalized release
  • workflow_dispatch -> make a finalized release
  • open/sync PR -> make a draft release
    • push to master -> finalize the draft release built
  • push to master -> make a draft release
    • tag commit -> finalize the draft release built

Using expressions in your workflow, you can run the action with finalize: false if event.type == pr_opened or event.type == pr_sync. Than, have another step that only runs on merge to master with finalize: true. This works because when building a finalized release, the action already checks if it exists. If it finds a draft release it would just mark as final. If it found a finalized release than nothing happens. Else, new final release is built.

Here is an example workflow file that would mimic the draft PR workflow we want to keep:

on:
 pull_request:
    types: [opened, synchronize]
    branches:
      - master
 push:
    branches:
      - master

jobs:
  balena_cloud_build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: balena-io/deploy-to-balena-action@master
        if: ${{ github.event_name == 'pull_request' }}
        id: draft 
        with:
          balena_token: ${{ secrets.BALENA_TOKEN }}
          fleet: my_org/sample_fleet
          finalize: false
      - uses: balena-io/deploy-to-balena-action@master
        if: ${{ github.event_name == 'push' }}
        id: finalize
        with:
          balena_token: ${{ secrets.BALENA_TOKEN }}
          fleet: my_org/sample_fleet
          finalize: true

To just build a final release on push to master remove the expressions and put finalize: true. Swap the events for push to master and tag commit if you want to make releases on those events as well.

@20k-ultra
Copy link
Contributor Author

finalize: boolean could default to false.

@20k-ultra
Copy link
Contributor Author

The only blocker I see for this is that the action uses PR id and commit SHA to tag the release built. Having just a commit SHA to identify a release may not be enough because I can create 2 PRs with the same commit SHA but both would produce releases. When you go to finalize, which one do you pick ?

"If they are the same SHA than it's the same release"

This isn't true if the build pulls in files from a server. Someone could trick the action into finalizing a release that pulled files from a different server.

@thgreasi
Copy link
Member

finalize: boolean could default to false.

@20k-ultra I think we can default it to undefined and have it as an advanced user opt-in, in case they want control everything.
And of course in case that you haven't explicitly specified it, the the actions works like today, doing it's best guess and allowing your workflow yml to be super simple.
That should keep it as a non breaking change as well.

@klutchell
Copy link
Collaborator

klutchell commented Jul 11, 2022

This looks good to me @20k-ultra , but I think your example should be simplified

on:
 pull_request:
    types: [opened, synchronize]
    branches:
      - master
 push:
    branches:
      - master
      
jobs:
  balena_cloud_build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: balena-io/deploy-to-balena-action@master
        with:
          balena_token: ${{ secrets.BALENA_TOKEN }}
          fleet: my_org/sample_fleet
          finalize: github.event_name == 'push'

@20k-ultra
Copy link
Contributor Author

I really disliked having the step twice so thank you for realizing that Kyle!

@luandro
Copy link

luandro commented Nov 11, 2022

Should let manually add input to define draft and release tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants