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

Support parallel execution of tasks #48

Closed
drewwells opened this issue Dec 22, 2015 · 11 comments · Fixed by #50
Closed

Support parallel execution of tasks #48

drewwells opened this issue Dec 22, 2015 · 11 comments · Fixed by #50
Assignees
Milestone

Comments

@drewwells
Copy link

In a situation where multiple tools are used, it is convenient to allow them to build independently of each other. For instance, I may want to run gulp and go build independently. I could specify that I want these run in parallel in the yaml config:

script:
  - gulp
    parallel: true
  - go build -o api && ./api
    parallel: true
verbose: true
@zabawaba99 zabawaba99 added this to the v1.1.1 milestone Dec 22, 2015
@zabawaba99
Copy link
Collaborator

So if one of the parallel processes fails, I would imagine the entire builds fails and everything else is cancels. Is this what you would expect as well @drewwells ?

@drewwells
Copy link
Author

I'm not too familiar with the tool, but the screencast looked like it repeated commands even on failure go test failure for instance. So if one failed, it would report the failure but the other command would continue to run. The failed command would be rerun after the next change.

@drewwells
Copy link
Author

Possibly that's why the screencast ordered the arguments as they did, go vet failure was preventing go test from running? Parallel execution wouldn't necessarily have that dependency chain since the scripts could be totally unrelated.

@zabawaba99
Copy link
Collaborator

Right not if one command fails all subsequent commands do not run. In order to preserve that maybe we can have something like

script
  - parallel
    - gulp
      go build -o api && ./api
    echo "some command that runs after the paralleled commands"

That way, if the group of parallel commands exits successfully then the second command can be executed, otherwise it never gets run.

cc/ @Tonkpils

@Tonkpils
Copy link
Owner

I actually like the parallel: true approach and explicitly state that any commands with that option will not cause the build to fail.

One thing I thought we discussed is possibly having groups of parallel scripts, which may be a scope creep but would be easier to implement with the parallel: true approach.

@drewwells
Copy link
Author

I like that idea of not failing the build for one parallel. Something that is really important to look at is how this interacts with non-parallel tasks. Those should likely run first and fail the build even if parallel ones are coming later. This gives the developer the power to make sure certain things run before any other tasks run.

script:
  -   npm install
  -   somenpmtool
      parallel: true

This should run npm install first before the parallel tasks work. So the developer can create some dependency management even with parallel tasks.

@Tonkpils
Copy link
Owner

I had a discussion with @zabawaba99 and we came up with a sensible solution for an initial implementation of this feature.

The initial issue with having parallel commands is the order in which the commands happen. Given a file:

script:
  - foo
  - bar
    parallel: true
  - baz
    parallel: true
  - omg

If omg fails, should the entire build stop? What happens with the parallel commands?

We've decided to create another section/label called runners which by default will run the commands in parallel. The runners section would run after the script, or aliased label builders, section.

The names are TBD but this gets the point across.

As an example:

builders:
  - npm install
runners:
  - gulp
  - go build -o foo && ./foo

@zabawaba99
Copy link
Collaborator

Couldn't have written it better myself @Tonkpils .

@drewwells
Copy link
Author

Yeah, I think sequential ones should all be executed first. If any fail, the whole thing fails.

I like the idea of grouping parallel tasks 👍

zabawaba99 added a commit that referenced this issue Jan 26, 2016
Closes issue #48

The snag.yml now accepts a 'Runners' tag. This tag represents a group
of commands that are meant to be run in parallel after the build stage.

Each process will be given a chance to start and will then get backgrounded
to allow other processes to run. The output of each command is streamed to
stdout prefix with the pid of the logging command
zabawaba99 added a commit that referenced this issue Jan 26, 2016
Closes issue #48

The snag.yml now accepts a 'Runners' tag. This tag represents a group
of commands that are meant to be run in parallel after the build stage.

Each process will be given a chance to start and will then get backgrounded
to allow other processes to run. The output of each command is streamed to
stdout prefix with the pid of the logging command
zabawaba99 added a commit that referenced this issue Jan 26, 2016
Closes issue #48

The snag.yml now accepts a 'Runners' tag. This tag represents a group
of commands that are meant to be run in parallel after the build stage.

Each process will be given a chance to start and will then get backgrounded
to allow other processes to run. The output of each command is streamed to
stdout prefix with the pid of the logging command
@zabawaba99
Copy link
Collaborator

Closed by #49 and #50.

Give it a shot @drewwells and let us know!

@drewwells
Copy link
Author

can do, looks good!

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

Successfully merging a pull request may close this issue.

3 participants