jvalkeal/build-zoo-handler

build-zoo-handler's Issues

Extract context properties fail with workflow dispatch

Was only implemented for repository dispatch so need to handle workflow dispatch as well.

Default user/email for tag-release

Use same defaults as with commit-changes

Add skeleton for label handling

As starting to use more github labels to maintain status for various
things like backports, etc it'd be nice to have gh action to handle as
much as it's possible to auto-create and manage labels for issues.

This initial work would be around to create feature where these labeling
rules could be created with atop of jexl with particular syntax.

Better error message for invalid dispatch-handler-config

Now you get something like Error: Unexpected token : in JSON at position 3607. Would be nice to see better error message.

It'd be nice to keep stats alive

Long running train build like in spring-cloud-dataflow, it'd be nice to see some kind of stats within build context like elapsed time how long a whole build takes, etc.

Workflow dispatch runner orchestrator

Once you get your multi repository product setup for gh actions, there's further things left like how could you fire a build of "everything"?

Simplest use case is to just fire up x number of workflow dispatches, in a correct order, waiting those workflows to succeed and eventually you should have last built repo. This is relatively simple for plain snapshot builds as you don't need to massage versions in a pom files(in case you're using maven).

For full release build this are more complex as we need to know a build version of a dependency project and that version is then a one which you'd need to massage poms in dependant projects.

Make zoo input error more clear

It's expected that Build zoo Handler Payload field is left empty if run manually. As that field should be base64 encoded json, should provide more output of a reason failure as otherwise workflow fails with Error: Unexpected token W in JSON at position 0.

Make better tests

Testing actions is not an easy job as i.e. testing octokit and things around is cumbersome. This is a long running issue to get better test coverage so that there would be less need to have a bunch of test repos to test things manually.

Support dispatch flow via workflow dispatch

If we find good use cases for this as you get user inputs and automatic branch checkout etc. Though we're kinda forced to have a field to pass on zoo payload via dedicated field.

Make dispatch repo targets optional

When defining dispatch settings, owner, repo, ref and workflow could be added to a context from a controller. Then those could be used
unless user defines those manually.

Ensure command run oks

We can check if commands exists, but it'd be nice if we could run a command and check that its exit status is 0. This would allow more sanity check from an env.

Upgrade typescript

Basically to latest version and to use new language features.

Workflow dispatch goes to loop

Accidentally fired worker workflow instead of a train/controller workflow and it went into a loop, oops!

In this case handler count is always staring from zero so loop checking doesn't work.

Support failing dispatch handling flow

Currently we just support hard coded repository_dispatch as:

dispatch-handler-config: >
  [
    {
      "if": "initial == true",
      "owner": "fakeowner",
      "repo": "fakerepo",
      "event_type": "build-zoo-handler-release"
    }
  ]

It'd be nice to have like action field and choose what happens like sending dispatch of failing.

dispatch-handler-config: >
  [
    {
      "if": "data.event == 'next-dev-version-failed'",
      "action": "fail",
      "fail": {
        "message": "hi, something went wrong"
      }
    }
  ]

This would allow to follow flow failure if repo is able to send back its failure.

Install buildpacks pack cli

Support passing properties from controller manual launch

If a dispatch flow needs to do something what can't be calculated automatically, only option really is to pass something when manually dispatching a workflow. This for example if train build need to do a milestone build, etc where version would need to be postfixed with -M1 or -RC1.

If we just use a dedicated field and inject list of properties into a context, other running actions can get those settings from there and do something more clever.

Add simple build branch/tag feature

Prevent running worker workflows manually

As these are meant to get executed from controller via api's, user can accidentally execute via UI. Should prevent these mistakes.