11 Apr 13:06

github-actions

e3a0c6d

3.0.1 Latest

Latest

Changelog

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which *is* always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.

We now properly handle the case where pe_client_tools_version is a tag,
by using that version as the location of the file in addition to the
filename.

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2 (a77cf5b)

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method if windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2 (738e6f5)

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2

Due to the timing of our LTS releases and our new major branches, PE 2016.5.0 and
PE 2016.5.1 did not get the windows2008r2 powershell fix that was done in PE-18351.
This means we need to not attempt to install fricitonlessly if it is pe 2016.5.(0|1)
if the agent platform is windows2008r2.
This PR adjust the install_via_msi? method and refactors the logic in there to clean
it up a bit (it is getting tough to easily read).
It breaks the method down to three lines:
1. If the agent is older then PE 2016.4.0.
2. If the agent is windows2008r2 and is less then...

Assets 2

04 Apr 08:25

github-actions

2.16.1

2cd0dda

2.16.1

Changelog

2.16.1 (2024-04-04)

Full Changelog

Implemented enhancements:

(PE-37704) Allow for SLES-11 (Intel) builds to be installed in PE 2021.7.x for testing #259 (shubhamshinde360)

Merged pull requests:

Bump yard from 0.9.35 to 0.9.36 #258 (dependabot[bot])
Bump rack from 2.2.8 to 2.2.8.1 #257 (dependabot[bot])
Bump yard from 0.9.34 to 0.9.35 #256 (dependabot[bot])
Bump activesupport from 7.1.3 to 7.1.3.2 #255 (dependabot[bot])
Bump scooter from 4.5.0 to 4.5.4 #254 (dependabot[bot])

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which *is* always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.

We now properly handle th...

Assets 2

07 Feb 19:08

github-actions

3.0.0

3bfe913

3.0.0

Changelog

3.0.0 (2024-02-07)

Full Changelog

Implemented enhancements:

Bump beaker from 4.40.2 to 4.41.1 #248 (dependabot[bot])
Bump scooter from 4.4.0 to 4.5.0 #242 (dependabot[bot])

Fixed bugs:

Bump beaker from 4.41.1 to 4.41.2 #249 (dependabot[bot])
Bump activesupport from 7.1.1 to 7.1.2 #240 (dependabot[bot])

Merged pull requests:

Bump rspec from 3.12.0 to 3.13.0 #253 (dependabot[bot])
Bump activesupport from 7.1.2 to 7.1.3 #251 (dependabot[bot])
Bump actions/setup-java from 3 to 4 #245 (dependabot[bot])
Bump actions/github-script from 6 to 7 #241 (dependabot[bot])

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by...

Assets 2

05 Dec 17:21

github-actions

2.16.0

59ff51f

2.16.0

Changelog

2.16.0 (2023-12-05)

Full Changelog

Merged pull requests:

(maint) Use unversioned AIX pe_repo class #244 (nmburgan)
Update rake requirement from ~> 13.0.6 to ~> 13.1.0 #239 (dependabot[bot])
Bump activesupport from 7.1.0 to 7.1.1 #238 (dependabot[bot])
Bump activesupport from 7.0.8 to 7.1.0 #237 (dependabot[bot])
Bump actions/checkout from 3 to 4 #236 (dependabot[bot])
Bump activesupport from 7.0.7.2 to 7.0.8 #235 (dependabot[bot])

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which *is* always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.

We now properly handle the case where pe_client_tools_version is a tag,
by using ...

Assets 2

29 Aug 13:09

github-actions

2.15.0

895742c

2.15.0

Changelog

2.15.0 (2023-08-29)

Full Changelog

Implemented enhancements:

(PE-36725) Update Aix's pe_repo class name #233 (cthorn42)

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which *is* always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.

We now properly handle the case where pe_client_tools_version is a tag,
by using that version as the location of the file in addition to the
filename.

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2 (a77cf5b)

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method if windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2 (738e6f5)

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2

Due to the timing of our LTS releases and our new major branches, PE 2016.5.0 and
PE 2016.5.1 did not get the windows2008r2 powershell fix that was done in PE-18351.
This means we need to not attempt to install fricito...

Assets 2

24 Aug 20:58

github-actions

2.14.1

ebaceb2

2.14.1

Changelog

2.14.1 (2023-08-24)

Full Changelog

Merged pull requests:

Bump activesupport from 7.0.7 to 7.0.7.2 #231 (dependabot[bot])
Bump activesupport from 7.0.6 to 7.0.7 #230 (dependabot[bot])

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which *is* always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.

We now properly handle the case where pe_client_tools_version is a tag,
by using that version as the location of the file in addition to the
filename.

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2 (a77cf5b)

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method if windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2 (738e6f5)

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2

Due to the timing of our LTS releases and our new major br...

Assets 2

09 Aug 21:34

github-actions

2.14.0

e94f8c4

2.14.0

Changelog

2.14.0 (2023-08-09)

Full Changelog

Merged pull requests:

Bump beaker from 4.40.1 to 4.40.2 #224 (dependabot[bot])
Bump activesupport from 7.0.4.3 to 7.0.6 #223 (dependabot[bot])
Update fakefs requirement from ~> 2.4, < 2.5.0 to ~> 2.4, < 2.6.0 #222 (dependabot[bot])

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which *is* always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.

We now properly handle the case where pe_client_tools_version is a tag,
by using that version as the location of the file in addition to the
filename.

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2 (a77cf5b)

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method if windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via...

Assets 2

08 Aug 20:40

github-actions

2.13.0

63daf3e

2.13.0

Changelog

2.13.0 (2023-08-08)

Full Changelog

Implemented enhancements:

(PE-36506) Use AIX 7.2 packages for 2023 STS stream #226 (donoghuc)

Fixed bugs:

(RE-15688) Add working nodeset for beaker-rspec tests #227 (yachub)

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they need to know the exact filename.

This case incidentally *worked* (or appeared to work) on Linux
platforms, because they never actually refer to the package by
filename. Instead, they install the package by setting up a repo config,
which *is* always named after pe_client_tools_sha, and never
pe_client_tools_version. In that case, the Linux platforms would
actually install the previous version of the package by SHA, from before
it had been tagged.

We now properly handle the case where pe_client_tools_version is a tag,
by using that version as the location of the file in addition to the
filename.

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2 (a77cf5b)

Merge pull request #66 from cthorn42/main/master/PE-20086_msi_install_method_for_2016.5.(0|1)_if_windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method if windows2008r2

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2 (738e6f5)

(PE-20086) PE 2016.5.(0|1) should install via msi method for windows2008r2

Due to the timing of our LTS releases ...

Assets 2

12 May 17:04

github-actions

2.12.0

6408e5d

2.12.0

Changelog

2.12.0 (2023-05-12)

Full Changelog

Implemented enhancements:

(RE-15478) Update actions and release workflow #217 (yachub)
(RE-15111) Add Mend Scanning #211 (yachub)
(RE-14819) Retry failed curls before trying to gunzip them #203 (e-gris)

Merged pull requests:

Update beaker-puppet requirement from ~> 1.0 to >= 1, < 3 #218 (dependabot[bot])
Allow beaker 5 #215 (bastelfreak)
Update fakefs requirement from ~> 0.6, < 0.14.0 to ~> 2.4, < 2.5.0 #214 (dependabot[bot])
Update simplecov requirement from = 0.18.5 to = 0.22.0 #209 (dependabot[bot])
Update activesupport requirement from ~> 5.0 to ~> 7.0 #192 (dependabot[bot])
Update rake requirement from ~> 12.3.3 to ~> 13.0.6 #185 (dependabot[bot])

worker - History

Details

LATEST - 27 Jun, 2017 (25db20df)

(GEM) update beaker-pe version to 1.18.0 (25db20d)
Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current (d0924c9)

Merge pull request #75 from ericwilliamson/task/master/QENG-5095-frictionless-agent-use-current

(QENG-5095) Use `current` endpoint for frictionless agent

(QENG-5095) Use current endpoint for frictionless agent (416efbf)

(QENG-5095) Use `current` endpoint for frictionless agent

Previous to this commit, the url constructed for frictionless agent
installs attempted to use the hosts `pe_ver` variable for getting the
exact URL of the simplified install script. This was causing issues with
PEZ builds due to the different pe_ver in the filename (for downloading
the tarball) and the actual pe version.
This commit updates the url to just use the `current` endpoint instead
of the version, which mimics our install documentation. This won't
really remove the ability of installing an older version via this method
considering the logic for adding pe_repo classes didn't support passing
a specific pe_ver / agent version to pe_repo.

(HISTORY) update beaker-pe history for gem release 1.17.0 (38b5acd)
(GEM) update beaker-pe version to 1.17.0 (544c858)
Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install (6958c09)

Merge pull request #74 from ericwilliamson/bug/master/qeng-5040-run-puppet-after-mono-install

(QENG-5040) Run puppet after simplified mono install

Merge pull request #73 from samwoods1/maint (cf2ad91)

Merge pull request #73 from samwoods1/maint

(maint) Fix parallel agent install

(QENG-5040) Run puppet after simplified mono install (01b9617)

(QENG-5040) Run puppet after simplified mono install

Previous to this commit, the new simplified mono install method was not
running puppet on the master node in a mono only scenario. If the
install included agents not of the masters OS, then puppet would of been
ran due to needing to add pe_repo classes. In the scenario of mono
master only, if puppet is not ran, then setup is not considered complete
due to exported resources, mcollective and facts not being setup yet.
This would cause numerous issues, such as no facts in puppetdb (so
anyaltic tests for example would fail) until a test somewhere in the
pipeline ran puppet agent on the master node.
This commit adds a call outside of the parallel agent run on non infra
agents due to the fact that with exported resources, the classifier
service will restart, so need to run the master first, then after that
all the agents can run.

(maint) Fix parallel agent install (19c1e64)

(maint) Fix parallel agent install
Parallel agent installs have been broken since f9cb3ca802ddc94a9a42dcbcfef96f7a76a19dff because the install command contained a working_dir that was unique per host.
This fixes that issue and also allows all agents to be installed in parallel regardless of OS or unique installer_cmd

1.16.0 - 26 May, 2017 (f8218db6)

(HISTORY) update beaker-pe history for gem release 1.16.0 (f8218db)
(GEM) update beaker-pe version to 1.16.0 (053b1ab)
PE-20610 Fix install failure on windows for old pe versions (6c5c614)

PE-20610 Fix install failure on windows for old pe versions

Added logic to use the old generic_install method on windows when
installing old pe versions that requires an msi install because of
powershell2 issue PE-18351. The newly added simple_monolithic_install
does not have a check for those conditions and proceeds with
frictionless installation on those hosts which fails.

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents (d69499e)

(PE-20589) After a simple monolithic install run puppet on non-infrastructure agents

Previously after agents were installed via simple mono install, we ran the agents
all at once. This include the master. Occasionaly there would be a change done to
the console services that would require a restart.
This would cause other agent runs to fail. So to not have that happen, we will run
only the non-infrastructure agents. That should be fine since part of the process
of installing PE should have the puppet runs included there.

1.15.0 - 11 May, 2017 (0fddaad5)

(HISTORY) update beaker-pe history for gem release 1.15.0 (0fddaad)
(GEM) update beaker-pe version to 1.15.0 (6cdb905)
(PE-20405) On frictionless installs ensure all hosts run prepare_hosts (f9cb3ca)

(PE-20405) On frictionless installs ensure all hosts run prepare_hosts

Previously when there was a frictionless install prepare_hosts was
only set on the master. This meant that agents were skipped and as
a result agents did not have a working_dir set.
This caused unix machines to install on just the root directory and
caused failures on windows.

1.14.0 - 10 May, 2017 (874a7998)

(HISTORY) update beaker-pe history for gem release 1.14.0 (874a799)
(GEM) update beaker-pe version to 1.14.0 (588c5ca)
Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag (e162d8e)

Merge pull request #69 from nicklewis/properly-install-pe-client-tools-from-tag

(maint) Properly install pe-client-tools when using a tag version

(maint) Properly install pe-client-tools when using a tag version (8b8e536)

(maint) Properly install pe-client-tools when using a tag version

Previously, installing pe-client-tools with a tag version would fail on
Windows/OS X and install the wrong package on Linux.

When installing pe-client-tools, we provide two options:
- pe_client_tools_sha: the commit SHA of the version to install
- pe_client_tools_version: the `git describe` of the version to install

pe_client_tools_version is always the name of the package to install.
But the *location* of the package differs based on whether the package
version corresponds to a tag or not. When the package isn't a tag
version, it's located in a directory named based on the SHA. But when it
is a tag version, it's located in a directory named after the tag.

When pe_client_tools_version was specified as a tag, we would look in
the directory named after the SHA (which was actually from a *previous*
build of the package, from before it was tagged) for a file named after
the tag. That file would never be there, since we had a mismatch of
directory and filename. For Windows and OS X, this caused a failure to
install, because they...

Assets 2

12 May 16:58

yachub

2.11.24

197bbe3

2.11.24

create beaker-pe 2.11.24 gem

Assets 2

Releases: puppetlabs/beaker-pe

3.0.1

Changelog

worker - History

Tags

Details

2.16.1

Changelog

2.16.1 (2024-04-04)

worker - History

Tags

Details

3.0.0

Changelog

3.0.0 (2024-02-07)

worker - History

Tags

Details

2.16.0

Changelog

2.16.0 (2023-12-05)

worker - History

Tags

Details

2.15.0

Changelog

2.15.0 (2023-08-29)

worker - History

Tags

Details

2.14.1

Changelog

2.14.1 (2023-08-24)

worker - History

Tags

Details

2.14.0

Changelog

2.14.0 (2023-08-09)

worker - History

Tags

Details

2.13.0

Changelog

2.13.0 (2023-08-08)

worker - History

Tags

Details

2.12.0

Changelog

2.12.0 (2023-05-12)

worker - History

Tags

Details

2.11.24