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

Some good changes in Job module #10

Merged
merged 6 commits into from
Jul 25, 2018

Conversation

tallysmartins
Copy link
Member

@tallysmartins tallysmartins commented Jul 5, 2018

  • Support to wait-for, added to command of the docker-compose.yml
  • Remove run_times from measurements results
  • Refactor Job module and add some tests

@tallysmartins tallysmartins changed the title Test suite Test suite and some refactoring Jul 5, 2018
@tallysmartins tallysmartins changed the title Test suite and some refactoring WIP: Test suite and some refactoring Jul 6, 2018
- Job.start_job/2 now receive a function to execute jobs, so we can write tests easily
without make the full processing of a job
- Turning private methods into public so we can test the complex logic of processing
a job to ensure everything is working

Signed-off-by: Tallys Martins <tallysmartins@gmail.com>
Signed-off-by: Tallys Martins <tallysmartins@gmail.com>
@tallysmartins tallysmartins changed the title WIP: Test suite and some refactoring Test suite and some refactoring Jul 16, 2018
@tallysmartins tallysmartins changed the title Test suite and some refactoring Some good changes in Job module Jul 16, 2018
@tallysmartins tallysmartins changed the title Some good changes in Job module WIP: Some good changes in Job module Jul 16, 2018
- Now, when a docker dependencie is specified, it can define a *wait-for*
attribute in the config.yml file. This attribute will be used to listen the
service port for TCP conections, assuming that its ready if it responds in a
given timeout. There is a script wait-for.sh in the runner-container to make
this check. For example, if a dependencie is given
with wait-for: 5432, the command for the runner service in the docker-compose
is overriden with 'wait-for localhost:5432 -- mix run bench/bench_helper.exs`.
Otherwise, if no dependence is given or the param wait-for is not given, the
default command 'mix run bench/bench_helper' is returned.

Signed-off-by: Tallys Martins <tallysmartins@gmail.com>
@tallysmartins tallysmartins changed the title WIP: Some good changes in Job module Some good changes in Job module Jul 17, 2018
@PragTob
Copy link
Member

PragTob commented Jul 18, 2018

Sorry I seem to have missed this one not getting a notification for it :'(

Copy link
Member

@PragTob PragTob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I somehow missed this - must have clicked away the notification or something 😊 . Comments inline

whatsapp image 2018-06-03 at 16 40 21

lib/runner.ex Outdated

config = Config.from_string_map(config)
job = Job.start_job(id, repo_slug, branch, commit, config)
job = Job.start_job(job, opts)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like we're missing opportunity to use the great pipe here :) |>

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

revision |> fix() ✔️

branch: branch,
commit: commit,
config: config
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not immedeatly obvious what the benefit of building the job struct here is. Not sure it should be or how to make it better. Just an observation. I think we do it so that we have a job struct to work with rather than the data map. Then it's also weird though why some of the fields are called slightly different - we're in control of all those field names right? Or am I missing something? Then we should probably call them all the same, then creating a job struct from it is also much easier.

branch: branch,
commit: commit,
config: config
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see you moved the responsibility. I think that's a good thing, that the job module just deals with job structs here so I like it 👍

Copy link
Member Author

@tallysmartins tallysmartins Jul 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah.. regarding the field names, I created an issue #11 to make them compatible later

}
end

defp build_runner_command_from_deps(deps) do
command =
Enum.reduce(deps, "", fn {_dep_name, dep_params}, acc ->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think renaming acc to something like command here helps the readability as it makes it more obvious the accumulator is hopening the command or maybe the wait_command something like that

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed! ✔️

config: config
}
timeout = Keyword.get(opts, :timeout, Confex.fetch_env!(:runner, :job_timeout))
task_fun = Keyword.get(opts, :task_fun, &run_job/1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure if having the task_function be part of the options is the best solution here. Having it be part of the options sort of suggests to me that it's viable to pass something different in there. In reality we just want to have it for testing purposes.

I think using a default argument like runner_function \\ &fun works in our favor here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed! ✔️

@@ -45,4 +19,253 @@ defmodule ElixirBench.Runner.JobTest do
assert job.context.worker_num_cores in 1..64
assert job.context.worker_os in [:Linux, :Windows, :macOS]
end

describe "start_job/6" do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't start_job/6 anymore (parameter number has changed)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed!

end
end

describe "get_benchmars_output_path/1" do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should also probably be benchmarks :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed! ✔️


compose_config =
Job.get_compose_config(job)
|> Antidote.decode!()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

usually one starts the pipe with a simple value (job in this case)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed!


assert %{"runner" => %{"environment" => %{"MYSQL_URL" => "root@localhost"}}} = services
end
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was unsure if your changes in build_services were ok in retaining behaviour, but these tests help my confidence - thank you 👍

Copy link
Member Author

@tallysmartins tallysmartins Jul 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can make it more explicit and put the entire config within a pattern match like I did in test "return docker-compose setup for simple job" do, wdyt?

assert %{} = Job.format_measurement(nil, "insert_mysql")
assert %{} = Job.format_measurement(%{"a" => "b"}, "insert_mysql")
end
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where are we testing that we drop all that big measurement data? It's also not quite sure for me where that happens in the code as it's not that explicit, so I think we could improve the code and tests there :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is the format_measurements/2 I added a comment on it to explicit say that we are interested in just the statistics data

Signed-off-by: Tallys Martins <tallysmartins@gmail.com>
Signed-off-by: Tallys Martins <tallysmartins@gmail.com>
Copy link
Member

@PragTob PragTob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good, just a couple things 👏

@@ -63,12 +55,11 @@ defmodule ElixirBench.Runner.Job do
end
end

defp ensure_no_other_jobs! do
def ensure_no_other_jobs! do
%{active: 0} = Supervisor.count_children(ElixirBench.Runner.JobsSupervisor)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think we can easily keep this private and test as part of the start_job logic as it raises in the error case so no other logic is actually triggered.

@@ -93,11 +84,12 @@ defmodule ElixirBench.Runner.Job do
end
end

defp get_benchmars_output_path(%Job{id: id}) do
def get_benchmars_output_path(%Job{id: id}) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be called brnchmarks still with the k :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️ changed

# Delete key that is not allowed in docker-compose otherwise it will break.
# This function iterates recursively over the services map and nested maps to delete the
# key for all services.
defp delete_non_docker_tag(services, tag) when is_map(services) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good name change 👍

assert %{log: "success", status: 0} = job
end

test "not start job if there is other job running" do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah I see you already added the test here you just need to make the function private again I think

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup

Signed-off-by: Tallys Martins <tallysmartins@gmail.com>
Copy link
Member

@PragTob PragTob left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

img_20171221_144657_bokeh 1

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

Successfully merging this pull request may close these issues.

None yet

2 participants