I tried:
# jenkins.pp
class jenkins {
yumrepo { "jenkins":
baseurl => "http://pkg.jenkins-ci.org/redhat",
descr => "Jenkins",
enabled => 1,
gpgcheck => 1,
gpgkey => "http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key",
}
#package {"jenkins": ensure => latest}
package {"jenkins": ensure => "1.509.1"}
}
include jenkins
But it still installs the latest release, and not the LTS version, which is 1.509.1
You use invalid base url.
Try http://pkg.jenkins-ci.org/redhat-stable/. More Info see: link and this.
Related
I have used the official puppet jenkins module. I have added jenkins jobs like this.
jenkins::job { 'test-build-job':
config => template("${templates}/test-build-job.xml.erb"),
}
when I run this command in puppet agent
puppet agent -tv
I get error like this:
Error: Failed to apply catalog: Validation of Exec[reload-jenkins] failed:
'java -jar /usr/lib/jenkins/jenkins-cli.jar -s http://localhost:8080
reload-configuration'
is not qualified and no path was specified. Please qualify the command or specify a path. (file: /etc/puppetlabs/code/environments/production/modules/jenkins/manifests/cli.pp, line: 42)
I'm getting error in cli.pp, and my cli.pp looks like
class jenkins::cli {
if $caller_module_name != $module_name {
fail("Use of private class ${name} by ${caller_module_name}")
}
$jar = "${jenkins::libdir}/jenkins-cli.jar"
$extract_jar = "jar -xf ${jenkins::libdir}/jenkins.war WEB-INF/jenkins-cli.jar"
$move_jar = "mv WEB-INF/jenkins-cli.jar ${jar}"
$remove_dir = 'rm -rf WEB-INF'
exec { 'jenkins-cli' :
command => "${extract_jar} && ${move_jar} && ${remove_dir}",
path => ['/bin', '/usr/bin'],
cwd => '/tmp',
creates => $jar,
require => Service['jenkins'],
}
file { $jar:
ensure => file,
require => Exec['jenkins-cli'],
}
$port = jenkins_port()
# The jenkins cli command with required parameter(s)
$cmd = "java -jar ${jar} -s http://localhost:${port}"
# Reload all Jenkins config from disk (only when notified)
exec { 'reload-jenkins':
command => "${cmd} reload-configuration",
tries => 10,
try_sleep => 2,
refreshonly => true,
require => File[$jar],
}
# Do a safe restart of Jenkins (only when notified)
exec { 'safe-restart-jenkins':
command => "${cmd} safe-restart && /bin/sleep 10",
tries => 10,
try_sleep => 2,
refreshonly => true,
require => File[$jar],
}
}
I'm trying debug CLI script, and Xdebug can't connect to PhpStorm.
I see error Operation now in progress (29). in Xdebug remote log.
I'm sure Xdebug configured right, but I don't know how to debug PhpStorm.
Summary from phpinfo() generated by https://xdebug.org/wizard.php
Tailored Installation Instructions
Summary
Xdebug installed: 2.6.1
Server API: Command Line Interface
Windows: no
Zend Server: no
PHP Version: 7.1.24
Zend API nr: 320160303
PHP API nr: 20160303
Debug Build: no
Thread Safe Build: no
OPcache Loaded: no
Configuration File Path: /usr/local/etc/php
Configuration File: /usr/local/etc/php/php.ini
Extensions directory: /usr/local/lib/php/extensions/no-debug-non-zts-20160303
You're already running the latest Xdebug version
Xdebug log
Log opened at 2019-02-19 11:59:37
I: Connecting to configured address/port: 46.201.50.194:9000.
W: Creating socket for '46.201.50.194:9000', poll success, but error: Operation now in progress (29).
E: Could not connect to client. :-(
Log closed at 2019-02-19 11:59:37
Xdebug config
xdebug
xdebug support => enabled
Version => 2.6.1
IDE Key => PHPSTORM
Supported protocols
DBGp - Common DeBuGger Protocol
Directive => Local Value => Master Value
xdebug.auto_trace => Off => Off
xdebug.cli_color => 0 => 0
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => On => On
xdebug.collect_params => 0 => 0
xdebug.collect_return => Off => Off
xdebug.collect_vars => Off => Off
xdebug.coverage_enable => On => On
xdebug.default_enable => On => On
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.extended_info => On => On
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => Off => Off
xdebug.gc_stats_output_dir => /tmp => /tmp
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => PHPSTORM => PHPSTORM
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.overload_var_dump => 2 => 2
xdebug.profiler_aggregate => Off => Off
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => Off => Off
xdebug.profiler_enable_trigger => Off => Off
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => /tmp => /tmp
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_addr_header => no value => no value
xdebug.remote_autostart => On => On
xdebug.remote_connect_back => Off => Off
xdebug.remote_cookie_expire_time => 3600 => 3600
xdebug.remote_enable => On => On
xdebug.remote_handler => dbgp => dbgp
xdebug.remote_host => 127.0.0.1 => localhost
xdebug.remote_log => /app/xdebug.log => no value
xdebug.remote_mode => req => req
xdebug.remote_port => 9000 => 9000
xdebug.remote_timeout => 200 => 200
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => Off => Off
xdebug.trace_enable_trigger => Off => Off
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => /tmp => /tmp
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3
Xdebug can't connect to PhpStorm because PhpStorm was not reachable by my external host ip.
How I debug it.
First I checked from docker container that PhpStorm listen port (9000 in my case)
nc -vz external_ip 9000
It got (tcp) failed: Connection refused
I try the same from the host and also got the error
Then I tried from host
nc -vz localhost 9000
And I got [tcp/*] succeeded!
So the problem in xdebug.remote_host not in PhpStorm probably
I found host ip in container
netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}'
Put it in xdebug.remote_host and now it works correctly
Thanks for #LazyOne
In my case I simply set the following xdebug conf:
xdebug.remote_connect_back=0
xdebug.remote_host=host.docker.internal
host.docker.internal should 'magically' find the host's IP (cf. documentation). Note that this requires Docker v18.03+ and currently only works on Mac and Windows hosts.
May be your xdebug.remote_port 9000 is using by php-fpm. You try changing other port. Example xdebug.remote_port=9001 and in launch.json file still port=9000
If someone doesn't want to hardcode or modify their docker, Dockerfile, or compose file (maybe someone is using a 2.x xdebug, it doesn't support environment variable). Adding the header X-Forwarded-For by using a header modifying extension on the browser so as to set $_SERVER['HTTP_X_FORWARDED_FOR'] is a very convenient approach. Don't forget the configuration xdebug.remote_connect_back=1.
Dockerfile
FROM php:7.1-apache
RUN yes | pecl install xdebug-2.5.5 \
&& echo "zend_extension=$(find /usr/local/lib/php/extensions/ -name xdebug.so)" > /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.remote_port=9000" >> /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.remote_enable=1" >> /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.remote_connect_back=1" >> /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.remote_log=/tmp/xdebug.log" >> /usr/local/etc/php/conf.d/xdebug.ini \
&& echo "xdebug.remote_autostart=off" >> /usr/local/etc/php/conf.d/xdebug.ini
ModHeader extension
xdebug.log
Log opened at 2021-07-06 16:06:59
I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to 172.17.0.1:9000.
W: Creating socket for '172.17.0.1:9000', poll success, but error: Operation now in progress (29).
E: Could not connect to client. :-(
Log closed at 2021-07-06 16:06:59
Log opened at 2021-07-06 16:07:40
I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Remote address found, connecting to 172.30.112.1:9000.
I: Connected to client. :-)
For me the fix to this error was simply clicking the phone icon in PhpStorm twice to disable and then re-enable listening for debug connections.
It shouldn't change anything but it worked because before that I fixed a bunch of other issues, one of them being that port 9003 was blocked by something else. Apparently PhpStorm doesn't warn when it can't use the specified port, so after resolving other issues it might be necessary to re-initiate listening for debug connections.
Have you configured the mapping from phpstorm in PHP->Server, you have to map the project file to the absolute path of the server eg. src -> "/var/www/html/test/src"
Also the xdebug file from the server that contains the ip address
I have opened "Windows Defender Firewall with Advanced Security" (Windows firewall settings) and have found that I have two rules, which appeared not clear from where, that block the phpStorm.
I disabled them - and the xDebugger started working for me.
We're trying to automate this task in our release process so that our scripts add a new released version in Jira. It will then iterate through a list of jira issues that have 'shipped' in this release and tag them with the Release Version we just added.
I can't seem to find any examples of adding a new Released Version in Jira [Project > Releases] via REST API.
Can you please share how you are handling this?
Add new Released Version via Jira API code snippet using ruby with httparty.
require 'httparty'
def self.create_version(version)
create_version_url = "https://jira2.server.com/rest/api/2/version"
#result = HTTParty.post(create_version_url,
:basic_auth => {:username => 'user', :password => 'password'},
:body => { :description => '',
:name => version,
:archived => false,
:released => true,
#:releaseDate => "2016-07-06",
:userReleaseDate => "6/Jul/2017",
:project => "project_name",
:projectId => "10102"
}.to_json,
:headers => { 'Content-Type' => 'application/json' })
puts #result
end
Set Fixed Version of jira issue:
def self.set_issue_fixedVersion(ticket,fixedVersion)
edit_issue_url = "https://jira2.<server>.com/rest/api/2/issue/#{ticket}"
#result = HTTParty.put(edit_issue_url,
:basic_auth => {:username => 'user', :password => 'password'},
:body => { "fields" => { "fixVersions"=> [{"name" => #{fixedVersion}}]}}.to_json,
:headers => { 'Content-Type' => 'application/json' })
puts #result
end
Could be something like this:
Create the new version: POST /version
You will also have to specify the project that the version belongs to
This will also make the version show up on the Project -> Releases page
Search for fixed issues, so you have their issue keys: POST /search
Possibly you can also get this list in another way, ie. from your version control system
Update the fixVersion of those issues with your new version: /PUT issue/{issueIdOrKey}
Release your version: PUT /version/{id}
In the body of your request specify the releaseDate and set released to true
I need to add the docker source list to apt before installing docker.
I have
apt::source { 'debian-jessie':
comment => 'This is the docker Debian jessie mirror',
location => 'http://apt.dockerproject.org/repo',
release => 'debian-jessie',
repos => 'main',
key_content => '58118E89F3A912897C070ADBF76221572C52609D',
key_server => 'keyserver.ubuntu.com',
ensure => present,
include_src => false,
include_deb => true,
}
which works, and also
package {'docker-engine':
ensure => present,
before => Class['docker'],
}
which works only after a second run (I use vagrant provision, but that's not relevant to the problem).
What I would like is making the whole thing work at the first provisioning by instructing puppet to execute apt::source before docker-engine, however adding it in require is not a valid syntax:
package {'docker-engine':
ensure => present,
before => Class['docker'],
require => [
Apt::source['debian-jessie'],
]
}
How to specify this dependency?
The rest of the file looks like this:
class { 'docker':
dns => '192.168.1.1',
manage_package => false,
use_upstream_package_source=> false,
# service_name => 'docker',
docker_command => 'docker',
package_name => 'docker-engine',
service_enable => true,
service_state => 'running',
extra_parameters => ["--insecure-registry=192.168.1.0/24"],
}
include 'docker'
file { "/lib/systemd/system/docker.service":
notify => Service["docker"],
ensure => present,
owner => "root",
group => "root",
mode => 0600,
source =>"puppet:///modules/docker/etc/systemd/system/docker.service"
} ~> Exec['systemctl-daemon-reload']
Capitalize word source
require => Apt::Source['debian-jessie']
Puppet documentation states:
The general form of a resource reference is:
The resource type, capitalized (every segment must be capitalized if
the resource type includes a namespace separator [::])
An opening square bracket
The title of the resource as a string, or a comma-separated list of titles
A closing square bracket
When using MassiveRecord over thrift to save a record into HBase, I get a strange "abort" error.
Here is some code that will reproduce the error on Mac OS X, with hbase (0.92.0 and 0.94.0) install via homebrew.
require 'massive_record'
MassiveRecord::ORM::Base.connection_configuration = { :host => 'hbase' }
class Woot < MassiveRecord::ORM::Table
default_scope select(:data)
column_family :data do
field :name, :string
end
end
woot = Woot.new( :name => 'rawr' )
woot.save
This always causes the process to halt, leaving the message
[1] 8756 abort ruby massive_woot.rb
Retrieving works just fine, but I can't seem to save the records.
Here is what the schema looks like:
>> describe 'woots'
DESCRIPTION ENABLED
{NAME => 'woots', FAMILIES => [{NAME => 'data', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '3', C true
OMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => '2147483647', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKCA
CHE => 'true'}]}
1 row(s) in 0.0190 seconds
This turned out to be a versioning issue. MassiveRecord v0.2.2 depends on thrift 0.6.0 (specified by an "= 0.6.0" version in the Gemfile).
I solved this for now by pulling off the "develop" branch of MassiveRecord from github.