| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This makes the catalog_memory benchmark print a message about
2.1.0 being required and then exit with -1 unless the ruby version
is >= than 2.1.0.
|
|
This adds a command that processes the dumped heap information
produced by "catalog_memory" benchmark (or other similar heap-dumps).
The result is a .dot file that can be rendered.
This tool is useful when tracking a memory leak.
|
|
|
|
This makes it possible for a benchmark scenario that wants
additional details to run a smaller portion of the benchmark to
configure these by defining a class called BenchmarkerTask (currently
only used by the evaluations benchmark). The separation from the
Benchmarker class is that this class is loaded when rake generates a
list of tasks, and it is not wanted to load each full benchmark in turn
to generate this list. (Over time, the BenchmarkerTask can be expanded
on to perform other task generation duties).
It is now possible to run all of the evaluations benchmarks,
profile all, run one particular micro benchmark, or just its parse or
evaluation part by suffixing the name with _parse or _eval. As an
example rake benchmark:evaluations:run[assert_type_eval] runs only the
evaluation part of the assert_type micro benchmark in evaluations. (This
is especially useful when running profiling.
For profiling, the parameter warm_up_runs is always included.
|
|
Arguments are needed to be able to run one detail of a benchmark.
The evaluations benchmark makes use of this, all others ignore the
arguments.
|
|
This adds a benchmark that runs a series of puppet manifests that
are measured individually for parse and evaluation time. Each
manifest is measured 100x each for parse and evaluation. The benchmark
total time includes running all of them (including overhead of
measuring the details). Details are output as average of all runs
per detail where parsing and evaluating is output as separate entries.
The sample file written is for the total average.
|
|
As this is an error/warning, the output should be put to STDERR instead
of STDOUT so it can be easily filtered.
|
|
|
|
If rspec isn't installed, rake will fail because the parallel.rake file
cannot be loaded.
The fix is to only define the task if rspec/facter can be loaded.
|
|
Adding a 'parallel:spec' task that will group specs and then run those
groups in a parallel set of processes.
By default, parallel:spec will bunch the specs into groups of
approximately 1000 and concurrently run each group up to the number of
processors reported by facter.
The task takes two parameters: process_count and group_size.
Running with a process_count of 1 (parallel:spec[1]) will behave like
the existing 'spec' task, except it will still group the tests and
recycle the spec running process between groups. This has the added
benefit of limiting the spec running process' working set, at the cost
of being a little slower.
|
|
The benchmark generate tasks are only for internal use by the other
tasks that users should use (run and profile). Putting a descritpion on
it, though, made it visible in `rake -T` and `rake -D`. This removes it
so that users aren't confused.
|
|
Because of the way puppet initializes, we can't safely re-initialize in
the same process. In order to run all of the scenarios we need to make
sure there is a new process for each one. This changes from having the
"all" tasks re-run rake for each of these instead of just making them
dependencies of the "all" task.
|
|
The JMeter format is to use milliseconds to express time. This changes
the timestamp and elapsed time to be in millis.
|
|
In order to make it easy to bulk collect the benchmark data there needs
to be a single command to run all of the scenarios. This adds
`benchmark:all:run` and `benchmark:all:profile` to achieve this.
|
|
This adds a JMeter format CSV log of the benchmark runs. This log will
allow us to track the performance over time via Jenkins and the
Performance plugin.
|
|
zaphod42/feature/master/pup-753-generate-benchmarking-manifests
(PUP-753) Benchmark puppet compiling w/many modules
|
|
|
|
There were two different places calling setup for the benchmarker. This
consolidates it down to one. Unfortunately, the setup method depends on
the generate method having been run already and so it not analogous to
the `setup` task. This meant that setup is actually called in the
`generate` task.
|
|
The constant for the default format string changed between 1.8.7 and
1.9.3. This adds a check for the ruby version so that it can get the
correct constant.
|
|
There were a few require statements that got left behind when the
benchmark implementation was moved from the rake tasks to its own
file. There was also a vestige of an attempt at using Open3 for
executing some commands. This removes those unneeded require statements.
|
|
Since the scenario execution is just defined by a ruby class that lives
in the scenario directory, the scenario tasks can now be generated. This
extracts the description of a scenario into a file (`description`) and
generates a set of rake tasks for each scenario that is in the
benchmarks directory.
This also removes the top-level benchmark task because right now all
scenarios will be using the same class name (Benchmarker), which would
cause name collisions when there are multiple scenarios being run in the
process.
|
|
The code for setting up and running the benchmark is very specific to
this particular scenario and also too large to keep in a rake file. This
extracts it out into a file that lives inside the scenario. This should
turn into a common interface that all benchmark scenarios can implement
and should allow the maintenance of scenarios to remain separated and
the creation of new ones to be vastly simplified.
|
|
This adds a new rake task "benchmark:many_modules:profile" that will run
a single case of the many_modules benchmark and profile it using
ruby-prof. The profile data is written to a file in the PWD that can
then be viewed using kcachegrind (or qcachegrind on OSX).
|
|
This sets up a scenario in which we are benchmarking the puppet compiler
with a large number of modules, but very simple manifests. The generated
modules have 2 manifests each an public and an internal. The site.pp for
the environment simply includes all of the modules' public classes. The
public classes in turn include their own internal class. The internal
class then places a single "notify" resource in the catalog.
This also ends up laying down a general structure for benchmark
scenarios. Each scenario has support files under `bencmarks/<name of
scenario>` and has a rake namespace under the `benchmark` namespace.
Each namespace should have at least tasks for `generate` and `run`.
|
|
The -fd flag makes the spec output very verbose, but doesn't really
provide any benefit for us. It does, however, cause builds to take a
significant amount of extra space.
|
|
|
|
This also creates two new rake tasks for generating the documentation:
doc:api and doc:all. The doc:api is to generate the published docs,
which omits portions of the code that hasn't been tagged. doc:all just
outputs everything.
|
|
It is useful to have some information about the artifact creation, so
that we can track it down later.
|
|
With changes to the way that the jenkins builds work we no longer need
to poll the downstream jobs to find errors.
This also cleans up the acceptance_artifacts task to use the rake
commands rather than relying on the shell so much.
|
|
The ci:check_for_downstream task would fail to find a job if it was
queued behind a currently running job as this are not listed in the
'builds' section. The first queued item is listed under queueItem, and
this change checks there. I have not found a way to query jobs queued
beyond the first.
|
|
And allow this to be overridden by an environment variable.
|
|
Cleans up the base Rakefile by extracting out the ci tasks into
tasks/ci.rake.
|
|
gem.rake is no longer used in 3.0.x because of the new workflow using the
packaging repo. It was still required in 2.7.x because 2.7.x still shipped with
sbin files and the gem.rake did some magic with moving sbin to bin. This commit
removes the rake task.
|
|
* 2.7.x:
(#7422) Support arrow syntax with metaparams
rm packaging artifacts in rpm spec, debian rules
Fix build targets for 2.7.x
Preserve timestamps when installing files
Replace dashes with dots for gem version
Conflicts:
ext/build_defaults.yaml
ext/debian/rules
ext/redhat/puppet.spec.erb
tasks/rake/gem.rake
|
|
When switching out to using git-describe for versioning from
source, gem versioning breaks because dashes are not allowed.
This simple fix replaces the dashes with dots, which are.
Note that in a merge-up to 3.0.x, this commit will conflict.
Default to 'ours' in a merge-up, this file does not even exist
in 3.0.x and shouldn't.
Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
|
|
The apple package task in tasks/rake is superceded
by the packaging repo task of the same name and
functionality. This commit removes it; it should
have been removed with the original set of packaging
changes to use the packaging repo.
Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
|
|
This commit removes several tasks that as far as
I can tell are no longer used, and the remaining
tasks out of the rake subdir in tasks.
Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
|
|
This commit adjusts the packaging artifacts for the difference
in directories between 2.7.x and 3.x, which doesn't have sbin
and test. Because of this we also switch to using the packaging
gem task and remove the existing one.
|
|
Conflicts:
Rakefile
ext/redhat/puppet.spec.erb
lib/puppet/defaults.rb
spec/integration/defaults_spec.rb
tasks/rake/apple.rake
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
Also add a file_mapping.yaml file for apple packaging.
|
|
|
|
* 2.7.x:
(#15464) Exclude gem command from bundler
Revert "Revert "Merge branch 'ticket/2.7.x/15464_a_gemfile_would_improve_contributor_on-boarding' into 2.7.x""
Conflicts:
README_DEVELOPER.md
lib/puppet.rb
tasks/rake/gem.rake
|
|
'ticket/2.7.x/15464_a_gemfile_would_improve_contributor_on-boarding' into 2.7.x""
This reverts commit 76ef99b3ea5baeeaa3482d0b3617a1b799c7028c.
|
|
'ticket/2.7.x/15464_a_gemfile_would_improve_contributor_on-boarding' into 2.7.x"
This reverts commit 8919d749c7f5973ab16c7db2b3a64fd1af8bf6b1, reversing
changes made to 97f742d70603f626dc40000aae72c299603282c6.
|
|
Without this patch applied the version string of Puppet is dynamically
set from the `git describe` tag in the Rakefile using monkey patching.
This is problematic because this causes a constant to be re-defined
which issues a warning in Ruby.
This patch fixes the problem by implementing the Puppet.version= module
method. The Rakefile will now set the Puppet version by using `require
'puppet/version'` and calling `Puppet.version = %x{git describe ...}`
Using a module method also has the benefit of making it easier to
intercept and mock Puppet version specific behavior.
From this point forward, the method Puppet.version should but used to
obtain the version string instead of the constant Puppet::PUPPETVERSION.
|
|
|
|
Facter 2.0.0rc is less than 2.0.0, so >= 2.0.0 will never be satisfied using
the current Puppet gem dependencies. This commit updates those dependencies to
have rc in the version, which will be correctly handled by modern rubygems and
ignored by older rubygems. The rc can be removed once the releases are final
and we no longer want users to be depending on rc releases.
|
|
(maint) Make Puppet's gem package task the same name as other Puppetlabs' projects
|
|
|
|
|
