adarlan / plankton Goto Github PK

Each job must be scheduled when the number of running jobs is less than the limit.

When a job is scheduled, all of the jobs that depends on it with condition service_health must also be able to be scheduled.

Plankton always create a .plankton directory inside the workspace.
When it is running from within a container, this directory is created with root user.
So, to delete it on the host, you must be a sudo user.

How to run the container with the same user on the host?

I have tried these options:

• --user 1001:1001
• -v /etc/passwd:/etc/passwd:ro
• --group-add docker

But did not work.

Instead of implement profiles, it's better to implement an option to specify the target jobs.
Plankton will only run the target jobs and the jobs they depends on, directly or indirectly.

When all of the target jobs have a final status,
any other service/job running is stopped.

The pipeline succeeds only if all of the target jobs succeed.
The final status of any other job does not matter.

If no target job is specified,
all the jobs are considered target jobs.

If a job is a dependency for other jobs with the condition service_healthy or service_started,
it can not be defined as target job.
It will always be stopped when no more jobs depends on it based on these conditions.

Create methods such as:
followUntilStarted()
followUntilHealthy()

These methods should be started in separate threads

https://labs.play-with-docker.com/

The Plankton container id got from inside the container is not the same as outside

Example:

services:
  foo-[for each item in examples]:
    image: alpine
    entrypoint:
      - cd ${item}
      - ls -a

It can loop through a directory files or through a file lines.
It automatically adds the variable item or whatever it is called (for each name in names.txt)

When the job is started, it should start a timeout countdown thread.
When this thread is finished, the job must be interrupted.

It does not mean "stop the container".
It means stop whatever the job is doing, such as pulling or building image.

When a job depends on an abstract jobs (those with name starting with .), this dependency should be replaced by all the concrete jobs that extends the abstract job.