My thoughts on using sub-expressions to access object properties.
$serviceObj = Get-Service "wmi*"
Write-Output "Service Status $serviceObj.status"
Service Status System.ServiceProcess.ServiceController.status
Not really the output I was expecting. This is where the sub-expression comes in handy! I can use a sub-expression to extract the status property value and display without using another variable.
$serviceObj = Get-Service "wmi*"
Write-Output "Service Status $($serviceObj.status)"
Service Status Stopped
I just can’t stop playing around with the Jenkins JCasC plugin. However, I just don’t think its in a state to replace all of your Jenkins configuration yet.
Example – I want to create a new Jenkins user\password and add the additional user data such as email, token, and description with the JCasC plugin.
You are currently only able to automate the username and password, and that is it.
- id: "builduser"
If you try adding the additional attributes, its going to fail. Checking the code seems to confirm the only available values are username and password.
Anyways, I will be following this plugin very closely. Probably even test it out more…
Lately, I’ve been reading some AWS documents in preparation for the SYSOPS certification and came across a great AWS monitoring best practice document.
This is such a great starting point for teams implementing a new monitoring solutions!
I’m still playing around with this Jenkins JCasC plugin. Its got major potential!!
One little gotcha if you are on Windows is how you path out to the jenkins.yaml file from within Jenkins. In my case, I was using standard Windows back slash.
This isn’t going to work. You need to use forward slashes in the Path text box.
I have been doing a little research on the Jenkins Configuration as Code (JCasC) plugin and I must say I think it’s definitely a step in the right direction.
In theory, with this plugin, you can have the majority of your Jenkins configuration stored in 1 file. This file can then be put in source control, which would allow you to easily rebuild your Jenkins instance at anytime.
However, while playing around with the plugin, a couple things came to my mind.
- It was hard for me to determine the correct syntax that needed to go into my jenkins.yaml file. There are examples located here, but these weren’t enough for me to get moving quickly.
- Long term, it could be a bit cumbersome to make all changes in the yaml file correctly, then re-apply to Jenkins instances.
- If the examples and plugin mature more, this is surely a easy way for teams to fail-safe\share their Jenkins configuration
- Fixing or growing the jenkins.yaml export functionality would greatly help. This would essentially allow you to apply Jenkins changes manually, then export to see the correct yaml syntax.
Anyways – This is a cool plugin that I am surely looking forward to using in the future!
I ran into a little issue today parsing a S3 SQS event that was sent to Lambda via a SQS trigger. I assumed the incoming event to Lambda was 100% of type dict. Given this, I assumed I could pull the bucket name and key using this syntax.
bucketname = event['Records']['body']['Records']['s3']['bucket']['name']
objectname = event['Records']['body']['Records']['s3']['object']['key']
As it turns out the incoming event is not 100% of type dict and I got the following error.
string indices must be integers
The Records after the body ([‘Records’][‘body’]) are of type str. Below is the updated code to pull the bucket name and key from the incoming event.
event_body_records_string = event['Records']['body']
event_body_records_dict = json.loads(event_body_records_string)
bucketname = event_body_records_dict['Records']['s3']['bucaket']['name']
objectname = event_body_records_dict['Records']['s3']['object']['key']
Now everything works out great!!!