Obie Rowe

Obie Rowe

1598479440

How To Automatically Transition Jira Issues Using a Github Webhook

What’s this all about eh?

One of the perks of my job is that on the last Friday of every month we get to work on our hack of choice, as long as it is in some way work related - come join us πŸ‘‹

We use Github for our repos and Jira for project management. This pairing offers some nice functionality through the use of third-party add-ons such as GitHub for Jira which allow us to add pull request context to Jira issues.

Jira supports many workflow transitions out-of-the-box including the following:

- Pull Request created

- Branch created

- Commit created

- Review rejected

See the full list at confluence.atlassian.com

Our Work Setup πŸ’»

Our Jira Workflows are quite involved but for us developers our primary focus is on the following Jira workflow transition states:

- In Development

- Ready for UI review

- Ready for review (Dev)

- Ready for QA

As part of a busy team there’s the inevitable context switching and we have many responsibilities including:

- Performing due diligence on new functionality

- PR reviews within our team

- Feature planning and development

- Bug fixing

- Mentoring

- etc.

Once our PRs have passed UI approval we then assign two Dev reviewers from within our team and transition the Jira ticket to Ready for review.

Reviews can take time for many reasons including the size of the feature, the amount of feedback, changes requested, and the number of PRs we have on the go at a given point in time; it can be difficult to notice when one has been granted the required number of approving Dev reviews and to manually then move the associated Jira ticket to the next stage in the workflow (Pull Panda can be hugely beneficial in this area, it’s a must-have for any large team).

#aws-lambda #lambda #aws #jira #slack #github #webhook #jira-to-github

What is GEEK

Buddha Community

How To Automatically Transition Jira Issues Using a Github Webhook
Spring Framework

Spring Framework

1642110180

Spring: A Static Web Site Generator Written By GitHub Issues

Spring

Spring is a blog engine written by GitHub Issues, or is a simple, static web site generator. No more server and database, you can setup it in free hosting with GitHub Pages as a repository, then post the blogs in the repository Issues.

You can add some labels in your repository Issues as the blog category, and create Issues for writing blog content through Markdown.

Spring has responsive templates, looking good on mobile, tablet, and desktop.Gracefully degrading in older browsers. Compatible with Internet Explorer 10+ and all modern browsers.

Get up and running in seconds.

中文介绍

Quick start guide

For the impatient, here's how to get a Spring blog site up and running.

First of all

  • Fork the Spring repository as yours.
  • Goto your repository settings page to rename Repository Name.
  • Hosted directly on GitHub Pages from your project repository, you can take it as User or organization site or Project site(create a gh-pages branch).
  • Also, you can set up a custom domain with Pages.

Secondly

  • Open the index.html file to edit the config variables with yours below.
$.extend(spring.config, {
  // my blog title
  title: 'Spring',
  // my blog description
  desc: "A blog engine written by github issues [Fork me on GitHub](https://github.com/zhaoda/spring)",
  // my github username
  owner: 'zhaoda',
  // creator's username
  creator: 'zhaoda',
  // the repository name on github for writting issues
  repo: 'spring',
  // custom page
  pages: [
  ]
})
  • Put your domain into the CNAME file if you have.
  • Commit your change and push it.

And then

  • Goto your repository settings page to turn on the Issues feature.
  • Browser this repository's issues page, like this https://github.com/your-username/your-repo-name/issues?state=open.
  • Click the New Issue button to just write some content as a new one blog.

Finally

  • Browser this repository's GitHub Pages url, like this http://your-username.github.io/your-repo-name, you will see your Spring blog, have a test.
  • And you're done!

Custom development

Installation

  • You will need a web server installed on your system, for example, Nginx, Apache etc.
  • Configure your spring project to your local web server directory.
  • Run and browser it, like http://localhost/spring/dev.html .
  • dev.html is used to develop, index.html is used to runtime.

Folder Structure

spring/
β”œβ”€β”€ css/
|    β”œβ”€β”€ boot.less  #import other less files
|    β”œβ”€β”€ github.less  #github highlight style
|    β”œβ”€β”€ home.less  #home page style
|    β”œβ”€β”€ issuelist.less #issue list widget style
|    β”œβ”€β”€ issues.less #issues page style
|    β”œβ”€β”€ labels.less #labels page style
|    β”œβ”€β”€ main.less #commo style
|    β”œβ”€β”€ markdown.less #markdown format style
|    β”œβ”€β”€ menu.less #menu panel style
|    β”œβ”€β”€ normalize.less #normalize style
|    β”œβ”€β”€ pull2refresh.less #pull2refresh widget style
|    └── side.html  #side panel style
β”œβ”€β”€ dist/
|    β”œβ”€β”€ main.min.css  #css for runtime
|    └── main.min.js  #js for runtime
β”œβ”€β”€ img/  #some icon, startup images
β”œβ”€β”€ js/
|    β”œβ”€β”€ lib/  #some js librarys need to use
|    β”œβ”€β”€ boot.js  #boot
|    β”œβ”€β”€ home.js  #home page
|    β”œβ”€β”€ issuelist.js #issue list widget
|    β”œβ”€β”€ issues.js #issues page
|    β”œβ”€β”€ labels.js #labels page
|    β”œβ”€β”€ menu.js #menu panel
|    β”œβ”€β”€ pull2refresh.less #pull2refresh widget
|    └── side.html  #side panel
β”œβ”€β”€ css/
|    β”œβ”€β”€ boot.less  #import other less files
|    β”œβ”€β”€ github.less  #github highlight style
|    β”œβ”€β”€ home.less  #home page style
|    β”œβ”€β”€ issuelist.less #issue list widget style
|    β”œβ”€β”€ issues.less #issues page style
|    β”œβ”€β”€ labels.less #labels page style
|    β”œβ”€β”€ main.less #commo style
|    β”œβ”€β”€ markdown.less #markdown format style
|    β”œβ”€β”€ menu.less #menu panel style
|    β”œβ”€β”€ normalize.less #normalize style
|    β”œβ”€β”€ pull2refresh.less #pull2refresh widget style
|    └── side.html  #side panel style
β”œβ”€β”€ dev.html #used to develop
β”œβ”€β”€ favicon.ico #website icon
β”œβ”€β”€ Gruntfile.js #Grunt task config
β”œβ”€β”€ index.html #used to runtime
└── package.json  #nodejs install config

Customization

  • Browser http://localhost/spring/dev.html, enter the development mode.
  • Changes you want to modify the source code, like css, js etc.
  • Refresh dev.html view change.

Building

  • You will need Node.js installed on your system.
  • Installation package.
bash

$ npm install

*   Run grunt task.

    ```bash
$ grunt
  • Browser http://localhost/spring/index.html, enter the runtime mode.
  • If there is no problem, commit and push the code.
  • Don't forget to merge master branch into gh-pages branch if you have.
  • And you're done! Good luck!

Report a bug

Who used

If you are using, please tell me.

Download Details:
Author: zhaoda
Source Code: https://github.com/zhaoda/spring
License: MIT License

#spring #spring-framework #spring-boot #java 

Chloe Butler

Chloe Butler

1667425440

Pdf2gerb: Perl Script Converts PDF Files to Gerber format

pdf2gerb

Perl script converts PDF files to Gerber format

Pdf2Gerb generates Gerber 274X photoplotting and Excellon drill files from PDFs of a PCB. Up to three PDFs are used: the top copper layer, the bottom copper layer (for 2-sided PCBs), and an optional silk screen layer. The PDFs can be created directly from any PDF drawing software, or a PDF print driver can be used to capture the Print output if the drawing software does not directly support output to PDF.

The general workflow is as follows:

  1. Design the PCB using your favorite CAD or drawing software.
  2. Print the top and bottom copper and top silk screen layers to a PDF file.
  3. Run Pdf2Gerb on the PDFs to create Gerber and Excellon files.
  4. Use a Gerber viewer to double-check the output against the original PCB design.
  5. Make adjustments as needed.
  6. Submit the files to a PCB manufacturer.

Please note that Pdf2Gerb does NOT perform DRC (Design Rule Checks), as these will vary according to individual PCB manufacturer conventions and capabilities. Also note that Pdf2Gerb is not perfect, so the output files must always be checked before submitting them. As of version 1.6, Pdf2Gerb supports most PCB elements, such as round and square pads, round holes, traces, SMD pads, ground planes, no-fill areas, and panelization. However, because it interprets the graphical output of a Print function, there are limitations in what it can recognize (or there may be bugs).

See docs/Pdf2Gerb.pdf for install/setup, config, usage, and other info.

pdf2gerb_cfg.pm

#Pdf2Gerb config settings:
#Put this file in same folder/directory as pdf2gerb.pl itself (global settings),
#or copy to another folder/directory with PDFs if you want PCB-specific settings.
#There is only one user of this file, so we don't need a custom package or namespace.
#NOTE: all constants defined in here will be added to main namespace.
#package pdf2gerb_cfg;

use strict; #trap undef vars (easier debug)
use warnings; #other useful info (easier debug)


##############################################################################################
#configurable settings:
#change values here instead of in main pfg2gerb.pl file

use constant WANT_COLORS => ($^O !~ m/Win/); #ANSI colors no worky on Windows? this must be set < first DebugPrint() call

#just a little warning; set realistic expectations:
#DebugPrint("${\(CYAN)}Pdf2Gerb.pl ${\(VERSION)}, $^O O/S\n${\(YELLOW)}${\(BOLD)}${\(ITALIC)}This is EXPERIMENTAL software.  \nGerber files MAY CONTAIN ERRORS.  Please CHECK them before fabrication!${\(RESET)}", 0); #if WANT_DEBUG

use constant METRIC => FALSE; #set to TRUE for metric units (only affect final numbers in output files, not internal arithmetic)
use constant APERTURE_LIMIT => 0; #34; #max #apertures to use; generate warnings if too many apertures are used (0 to not check)
use constant DRILL_FMT => '2.4'; #'2.3'; #'2.4' is the default for PCB fab; change to '2.3' for CNC

use constant WANT_DEBUG => 0; #10; #level of debug wanted; higher == more, lower == less, 0 == none
use constant GERBER_DEBUG => 0; #level of debug to include in Gerber file; DON'T USE FOR FABRICATION
use constant WANT_STREAMS => FALSE; #TRUE; #save decompressed streams to files (for debug)
use constant WANT_ALLINPUT => FALSE; #TRUE; #save entire input stream (for debug ONLY)

#DebugPrint(sprintf("${\(CYAN)}DEBUG: stdout %d, gerber %d, want streams? %d, all input? %d, O/S: $^O, Perl: $]${\(RESET)}\n", WANT_DEBUG, GERBER_DEBUG, WANT_STREAMS, WANT_ALLINPUT), 1);
#DebugPrint(sprintf("max int = %d, min int = %d\n", MAXINT, MININT), 1); 

#define standard trace and pad sizes to reduce scaling or PDF rendering errors:
#This avoids weird aperture settings and replaces them with more standardized values.
#(I'm not sure how photoplotters handle strange sizes).
#Fewer choices here gives more accurate mapping in the final Gerber files.
#units are in inches
use constant TOOL_SIZES => #add more as desired
(
#round or square pads (> 0) and drills (< 0):
    .010, -.001,  #tiny pads for SMD; dummy drill size (too small for practical use, but needed so StandardTool will use this entry)
    .031, -.014,  #used for vias
    .041, -.020,  #smallest non-filled plated hole
    .051, -.025,
    .056, -.029,  #useful for IC pins
    .070, -.033,
    .075, -.040,  #heavier leads
#    .090, -.043,  #NOTE: 600 dpi is not high enough resolution to reliably distinguish between .043" and .046", so choose 1 of the 2 here
    .100, -.046,
    .115, -.052,
    .130, -.061,
    .140, -.067,
    .150, -.079,
    .175, -.088,
    .190, -.093,
    .200, -.100,
    .220, -.110,
    .160, -.125,  #useful for mounting holes
#some additional pad sizes without holes (repeat a previous hole size if you just want the pad size):
    .090, -.040,  #want a .090 pad option, but use dummy hole size
    .065, -.040, #.065 x .065 rect pad
    .035, -.040, #.035 x .065 rect pad
#traces:
    .001,  #too thin for real traces; use only for board outlines
    .006,  #minimum real trace width; mainly used for text
    .008,  #mainly used for mid-sized text, not traces
    .010,  #minimum recommended trace width for low-current signals
    .012,
    .015,  #moderate low-voltage current
    .020,  #heavier trace for power, ground (even if a lighter one is adequate)
    .025,
    .030,  #heavy-current traces; be careful with these ones!
    .040,
    .050,
    .060,
    .080,
    .100,
    .120,
);
#Areas larger than the values below will be filled with parallel lines:
#This cuts down on the number of aperture sizes used.
#Set to 0 to always use an aperture or drill, regardless of size.
use constant { MAX_APERTURE => max((TOOL_SIZES)) + .004, MAX_DRILL => -min((TOOL_SIZES)) + .004 }; #max aperture and drill sizes (plus a little tolerance)
#DebugPrint(sprintf("using %d standard tool sizes: %s, max aper %.3f, max drill %.3f\n", scalar((TOOL_SIZES)), join(", ", (TOOL_SIZES)), MAX_APERTURE, MAX_DRILL), 1);

#NOTE: Compare the PDF to the original CAD file to check the accuracy of the PDF rendering and parsing!
#for example, the CAD software I used generated the following circles for holes:
#CAD hole size:   parsed PDF diameter:      error:
#  .014                .016                +.002
#  .020                .02267              +.00267
#  .025                .026                +.001
#  .029                .03167              +.00267
#  .033                .036                +.003
#  .040                .04267              +.00267
#This was usually ~ .002" - .003" too big compared to the hole as displayed in the CAD software.
#To compensate for PDF rendering errors (either during CAD Print function or PDF parsing logic), adjust the values below as needed.
#units are pixels; for example, a value of 2.4 at 600 dpi = .0004 inch, 2 at 600 dpi = .0033"
use constant
{
    HOLE_ADJUST => -0.004 * 600, #-2.6, #holes seemed to be slightly oversized (by .002" - .004"), so shrink them a little
    RNDPAD_ADJUST => -0.003 * 600, #-2, #-2.4, #round pads seemed to be slightly oversized, so shrink them a little
    SQRPAD_ADJUST => +0.001 * 600, #+.5, #square pads are sometimes too small by .00067, so bump them up a little
    RECTPAD_ADJUST => 0, #(pixels) rectangular pads seem to be okay? (not tested much)
    TRACE_ADJUST => 0, #(pixels) traces seemed to be okay?
    REDUCE_TOLERANCE => .001, #(inches) allow this much variation when reducing circles and rects
};

#Also, my CAD's Print function or the PDF print driver I used was a little off for circles, so define some additional adjustment values here:
#Values are added to X/Y coordinates; units are pixels; for example, a value of 1 at 600 dpi would be ~= .002 inch
use constant
{
    CIRCLE_ADJUST_MINX => 0,
    CIRCLE_ADJUST_MINY => -0.001 * 600, #-1, #circles were a little too high, so nudge them a little lower
    CIRCLE_ADJUST_MAXX => +0.001 * 600, #+1, #circles were a little too far to the left, so nudge them a little to the right
    CIRCLE_ADJUST_MAXY => 0,
    SUBST_CIRCLE_CLIPRECT => FALSE, #generate circle and substitute for clip rects (to compensate for the way some CAD software draws circles)
    WANT_CLIPRECT => TRUE, #FALSE, #AI doesn't need clip rect at all? should be on normally?
    RECT_COMPLETION => FALSE, #TRUE, #fill in 4th side of rect when 3 sides found
};

#allow .012 clearance around pads for solder mask:
#This value effectively adjusts pad sizes in the TOOL_SIZES list above (only for solder mask layers).
use constant SOLDER_MARGIN => +.012; #units are inches

#line join/cap styles:
use constant
{
    CAP_NONE => 0, #butt (none); line is exact length
    CAP_ROUND => 1, #round cap/join; line overhangs by a semi-circle at either end
    CAP_SQUARE => 2, #square cap/join; line overhangs by a half square on either end
    CAP_OVERRIDE => FALSE, #cap style overrides drawing logic
};
    
#number of elements in each shape type:
use constant
{
    RECT_SHAPELEN => 6, #x0, y0, x1, y1, count, "rect" (start, end corners)
    LINE_SHAPELEN => 6, #x0, y0, x1, y1, count, "line" (line seg)
    CURVE_SHAPELEN => 10, #xstart, ystart, x0, y0, x1, y1, xend, yend, count, "curve" (bezier 2 points)
    CIRCLE_SHAPELEN => 5, #x, y, 5, count, "circle" (center + radius)
};
#const my %SHAPELEN =
#Readonly my %SHAPELEN =>
our %SHAPELEN =
(
    rect => RECT_SHAPELEN,
    line => LINE_SHAPELEN,
    curve => CURVE_SHAPELEN,
    circle => CIRCLE_SHAPELEN,
);

#panelization:
#This will repeat the entire body the number of times indicated along the X or Y axes (files grow accordingly).
#Display elements that overhang PCB boundary can be squashed or left as-is (typically text or other silk screen markings).
#Set "overhangs" TRUE to allow overhangs, FALSE to truncate them.
#xpad and ypad allow margins to be added around outer edge of panelized PCB.
use constant PANELIZE => {'x' => 1, 'y' => 1, 'xpad' => 0, 'ypad' => 0, 'overhangs' => TRUE}; #number of times to repeat in X and Y directions

# Set this to 1 if you need TurboCAD support.
#$turboCAD = FALSE; #is this still needed as an option?

#CIRCAD pad generation uses an appropriate aperture, then moves it (stroke) "a little" - we use this to find pads and distinguish them from PCB holes. 
use constant PAD_STROKE => 0.3; #0.0005 * 600; #units are pixels
#convert very short traces to pads or holes:
use constant TRACE_MINLEN => .001; #units are inches
#use constant ALWAYS_XY => TRUE; #FALSE; #force XY even if X or Y doesn't change; NOTE: needs to be TRUE for all pads to show in FlatCAM and ViewPlot
use constant REMOVE_POLARITY => FALSE; #TRUE; #set to remove subtractive (negative) polarity; NOTE: must be FALSE for ground planes

#PDF uses "points", each point = 1/72 inch
#combined with a PDF scale factor of .12, this gives 600 dpi resolution (1/72 * .12 = 600 dpi)
use constant INCHES_PER_POINT => 1/72; #0.0138888889; #multiply point-size by this to get inches

# The precision used when computing a bezier curve. Higher numbers are more precise but slower (and generate larger files).
#$bezierPrecision = 100;
use constant BEZIER_PRECISION => 36; #100; #use const; reduced for faster rendering (mainly used for silk screen and thermal pads)

# Ground planes and silk screen or larger copper rectangles or circles are filled line-by-line using this resolution.
use constant FILL_WIDTH => .01; #fill at most 0.01 inch at a time

# The max number of characters to read into memory
use constant MAX_BYTES => 10 * M; #bumped up to 10 MB, use const

use constant DUP_DRILL1 => TRUE; #FALSE; #kludge: ViewPlot doesn't load drill files that are too small so duplicate first tool

my $runtime = time(); #Time::HiRes::gettimeofday(); #measure my execution time

print STDERR "Loaded config settings from '${\(__FILE__)}'.\n";
1; #last value must be truthful to indicate successful load


#############################################################################################
#junk/experiment:

#use Package::Constants;
#use Exporter qw(import); #https://perldoc.perl.org/Exporter.html

#my $caller = "pdf2gerb::";

#sub cfg
#{
#    my $proto = shift;
#    my $class = ref($proto) || $proto;
#    my $settings =
#    {
#        $WANT_DEBUG => 990, #10; #level of debug wanted; higher == more, lower == less, 0 == none
#    };
#    bless($settings, $class);
#    return $settings;
#}

#use constant HELLO => "hi there2"; #"main::HELLO" => "hi there";
#use constant GOODBYE => 14; #"main::GOODBYE" => 12;

#print STDERR "read cfg file\n";

#our @EXPORT_OK = Package::Constants->list(__PACKAGE__); #https://www.perlmonks.org/?node_id=1072691; NOTE: "_OK" skips short/common names

#print STDERR scalar(@EXPORT_OK) . " consts exported:\n";
#foreach(@EXPORT_OK) { print STDERR "$_\n"; }
#my $val = main::thing("xyz");
#print STDERR "caller gave me $val\n";
#foreach my $arg (@ARGV) { print STDERR "arg $arg\n"; }

Download Details:

Author: swannman
Source Code: https://github.com/swannman/pdf2gerb

License: GPL-3.0 license

#perl 

Obie Rowe

Obie Rowe

1598479440

How To Automatically Transition Jira Issues Using a Github Webhook

What’s this all about eh?

One of the perks of my job is that on the last Friday of every month we get to work on our hack of choice, as long as it is in some way work related - come join us πŸ‘‹

We use Github for our repos and Jira for project management. This pairing offers some nice functionality through the use of third-party add-ons such as GitHub for Jira which allow us to add pull request context to Jira issues.

Jira supports many workflow transitions out-of-the-box including the following:

- Pull Request created

- Branch created

- Commit created

- Review rejected

See the full list at confluence.atlassian.com

Our Work Setup πŸ’»

Our Jira Workflows are quite involved but for us developers our primary focus is on the following Jira workflow transition states:

- In Development

- Ready for UI review

- Ready for review (Dev)

- Ready for QA

As part of a busy team there’s the inevitable context switching and we have many responsibilities including:

- Performing due diligence on new functionality

- PR reviews within our team

- Feature planning and development

- Bug fixing

- Mentoring

- etc.

Once our PRs have passed UI approval we then assign two Dev reviewers from within our team and transition the Jira ticket to Ready for review.

Reviews can take time for many reasons including the size of the feature, the amount of feedback, changes requested, and the number of PRs we have on the go at a given point in time; it can be difficult to notice when one has been granted the required number of approving Dev reviews and to manually then move the associated Jira ticket to the next stage in the workflow (Pull Panda can be hugely beneficial in this area, it’s a must-have for any large team).

#aws-lambda #lambda #aws #jira #slack #github #webhook #jira-to-github

Ronel Ramos

Ronel Ramos

1620363180

Automatically Trigger Jenkins Jobs Using Github WebHook | Jenkins Integration With Github Webhook

In this video, I will show you how to trigger the Jenkins jobs automatically using GitHub webhooks.

Subscribe: https://www.youtube.com/c/Mukeshotwani/featured

#jenkins #github #webhook

Adolphus Tillman

Adolphus Tillman

1653811680

Automation With Jira Webhook and GitHub Actions Workflow

 Automation empowers us to focus on the work that matters, removing the need to perform manual, repetitive tasks by allowing us to automate our processes and workflows. JIRA offers a simple yet powerful rule builder, and we can configure automation rules to handle even the most complex scenarios.

In this story, we are going to explore how to automate JIRA issue status updates to trigger GitHub actions workflow to deploy Spring Boot microservice artifacts to ECS Fargate for different environments. Our goal:

  • The user updates a JIRA issue’s status to DEV; the artifact gets deployed to the DEV environment through GitHub actions workflow.
  • The user updates the JIRA issue’s status to QA; the artifacts then correspondingly get deployed to the QA environment.
  • Prod deployment follows the same way.

Let’s define an automation rule in JIRA to handle this workflow addressed in our use case. See the screenshot below:

A few points to mention:

  • Since the use case is centered around the status field in a JIRA issue, we start our rule with When: Issue transitioned.
  • We use if/else conditions to spell out the rule details.
  • If status equals DEV, we trigger a webhook call to send a repository dispatch event to GitHub actions workflow to deploy the artifacts to the DEV environment.
  • If status equals QA, we trigger a webhook call to send a repository dispatch event to GitHub actions workflow to deploy the artifacts to the QA environment.
  • If status equals PROD, we trigger a webhook call to send a repository dispatch event to GitHub actions workflow to deploy the artifacts to the PROD environment.

Assumption: the rule can only be created by a user with administrator privileges for the particular project in JIRA.

Webhook Configuration

Let’s take a closer look at how we define the webhook in our rule. See the screenshot below. This webhook is essentially a REST API call to GitHub’s repository dispatch API. A repository dispatch is just an HTTP request to our repository asking GitHub to kick off any action or webhook.

Using this feature, we can either manually trigger GitHub actions using repository dispatches or set up an application like JIRA to trigger the action by sending a web request.

A few things to point out:

  • This endpoint requires write access to the repository. The Header section’s Authorization needs to have value as Bearer <github token>. Without this, the call will fail.
  • Custom data section. The design is as follows:
  • event_type: we can define our event type as event-triggered-by-jira. Later in the GitHub Actions workflow, we filter by this particular event type to process. As long as the event type defined here matches that in GitHub actions workflow, we can name this whatever we want that makes sense.
  • The client_payload parameter is available for any extra information that our workflow might need. This parameter is a JSON payload that will be passed on when the webhook event is dispatched. In our case, we define two parameters:
  • jira-issue: this is the JIRA issue number, in the form of JIRA smart value {{issue.key}}. We can use this JIRA issue number in the commit comment in the GitHub actions workflow.
  • env: this is the environment we want to pass to GitHub actions workflow so artifacts can be deployed in this particular environment defined here.

That’s it on the rule definition side. Now, let’s move on to GitHub.

GitHub Environments

GitHub Environments are used to describe a general deployment target like DEV, QA, or PROD. We can configure environments with environment-specific secrets. Repository secrets act as the default/backup secrets. Environment secrets overwrite repository secrets.

We can also set up environment protection rules for higher environments, such as PROD. We can configure up to six reviewers to ensure deploying to PROD is indeed intended and approved.

GitHub Actions Workflow

This is where the actual artifacts deployment takes place. See the screenshot below for the full workflow.yml. Comments have been added to this yml file to explain the purpose of each action. Notice no hard-coded environments or other variables so that we can use this same workflow yml for deployments to other environments that are based on the JIRA status trigger.

# This workflow will build and push a new container image to Amazon ECR, and then deploy a new task definition to Amazon ECS.
#
# To use this workflow, assume you have your infrastructure already provisioned, if not, you will need to complete the following set-up steps:
#
# 1. Create an ECR repository to store your images.
#    For example: `aws ecr create-repository --repository-name my-ecr-repo --region us-east-1`.
#    Replace the value of the `ECR_REPOSITORY` environment variable in the workflow below with your repository's name.
#    Replace the value of the `AWS_REGION` environment variable in the workflow below with your repository's region.
#
# 2. Create an ECS task definition, an ECS cluster, and an ECS service.
#    For example, follow the Getting Started guide on the ECS console:
#      https://us-east-2.console.aws.amazon.com/ecs/home?region=us-east-2#/firstRun
#    Replace the value of the `ECS_SERVICE` environment variable in the workflow below with the name you set for the Amazon ECS service.
#    Replace the value of the `ECS_CLUSTER` environment variable in the workflow below with the name you set for the cluster.
#
# 3. Store your ECS task definition as a JSON file in your repository.
#    The format should follow the output of `aws ecs register-task-definition --generate-cli-skeleton`.
#    Replace the value of the `ECS_TASK_DEFINITION` environment variable in the workflow below with the path to the JSON file.
#    Replace the value of the `CONTAINER_NAME` environment variable in the workflow below with the name of the container
#    in the `containerDefinitions` section of the task definition.
#
# 4. Store an IAM user access key in GitHub Actions secrets named `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.
#    See the documentation for each action used below for the recommended IAM policies for this IAM user,
#    and best practices on handling the access key credentials.

name: App CI/CD for building and deploying customer-service to ECS Fargate

on:
  push:
    branches: [ main ]
    tags: "*"
  pull_request:
    branches: [ main ]
  repository_dispatch:
    # this is the event_type passed in from the webhook, needs to match exactly what was defined in the webhook custom data payload
    types: [ "event-triggered-by-jira" ]

# env section defines environment variables, for now, we have them configured in the github environment secrets
#env:
  #AWS_REGION: us-east-1                           # set this to your preferred AWS region, e.g. us-west-1
  #ECR_REPOSITORY: customer-service                # set this to your Amazon ECR repository name
  #ECS_SERVICE: customer-service                   # set this to your Amazon ECS service name
  #ECS_CLUSTER: default                            # set this to your Amazon ECS cluster name
  #ECS_TASK_DEFINITION: customer-service           # set this to your Amazon ECS task definition
  #CONTAINER_NAME: customer-service                # set this to the name of the container in the containerDefinitions section of your task definition

# The GITHUB_TOKEN is an automatically generated secret that lets you make authenticated calls to the GitHub API in your workflow runs.
# Actions generate a new token for each job and expires the token when a job completes. The token has read permission to contents.
# This configuration allows you to follow a principle of least privilege in your workflows.
permissions:
  contents: read

jobs:

  buildAndTest:
    name: Build & Test
    runs-on: ubuntu-latest
    environment: ${{ github.event.client_payload.env }}

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      # Merely to print out the jira issue number and the env variables passed in from the webhook for verification
      - name: Print JIRA ticket number and environment
        run: |
          echo JIRA number is ${{ github.event.client_payload.jira-issue }}
          echo environment is ${{ github.event.client_payload.env }}
      # this action provides the following functionality for the runners:
      # - download and set up java 17
      # - configure runner for publisher using maven
      # - caching dependencies managed by maven
      - name: Setup jdk-17
        uses: actions/setup-java@main
        with:
          java-version: 17
          distribution: 'adopt'
          #This action has a built-in functionality for caching dependencies by using actions/cache under the hood.
          cache: maven

      # run maven command to build the artifact, skipping test because no connectivity to a real postgres db in the backend, revise data source jdbc url in application.yml to enable testing 
      - name: Build with Maven
        run: mvn clean install -Dmaven.test.skip --file pom.xml

      # The output of one job is not automatically available to the subsequent jobs in a workflow.
      # GitHub Actions Artifacts allow us to persist data after a job has completed, and share that data with another job in the same workflow.
      # So we upload the artifact here so it can be reused by the deploy job later on
      - name: Upload the build output
        uses: actions/upload-artifact@v2
        with:
          name: exec-jar
          # this path and file name is app specific, be sure to modify if your app differs
          path: target/customerservice-0.0.1-SNAPSHOT-exec.jar

  autoMerge:
    name: Auto Merge for Dependabot PRs
    # uses "needs" to specify sequence of jobs
    needs: buildAndTest 
    runs-on: ubuntu-latest

    # specify "write" permission for GITHUB_TOKEN, so it can merge the PRs raised by Dependabot, see step below.
    permissions:
      pull-requests: write
      contents: write

    steps:
      # step to auto merge PRs raised by dependabot
      - uses: fastify/github-action-merge-dependabot@v3.0.0
        if: ${{ github.actor == 'dependabot[bot]' && github.event_name == 'pull_request' }}
        with:
          # it is an automatically generated secret that lets you make authenticated calls to the GitHub APIs.
          github-token: ${{ secrets.GITHUB_TOKEN }}

  deploy:
    name: Deploy to AWS ECS Fargate
    runs-on: ubuntu-latest
    # important to specify the environment here so workflow knows where to deploy your artifact to.
    # default environment to "dev" if it is not passed in through workflow_dispatch manual trigger
    environment: ${{ github.event.inputs.environment || 'dev' }}
    needs: autoMerge
    # notice the if condition below, no need for ${{ }} as GitHub automatically evaluates the if conditional as an expression
    if: startsWith(github.ref, 'refs/tags/') || github.event.inputs.environment != null
    steps:
      # this print env step merely prints the env for debugging purpose
      - name: Print environment
        run: |
          echo environment is ${{ github.event.inputs.environment }}
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Set tag
        id: vars
        run: echo "::set-output name=tag::${GITHUB_REF#refs/*/}"

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Download the build output
        uses: actions/download-artifact@v2
        with:
          name: exec-jar
          path: rest-controller/target # this value may vary depending on your application

      - name: Build, tag, and push image to AWS ECR
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: ${{ secrets.ECR_REPOSITORY_NAME }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          # Build a docker container and push it to ECR so that it can be deployed to ECS.
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"
      - name: Download task definition
        run: |
          aws ecs describe-task-definition --task-definition ${{ secrets.ECS_TASK_DEFINITION }} --query taskDefinition > task-definition.json
      - name: Fill in the new image ID and pass in the environment variable in the ECS task definition
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: task-definition.json
          container-name: ${{ secrets.CONTAINER_NAME }}
          image: ${{ steps.build-image.outputs.image }}
          environment-variables: |
            ENVIRONMENT=${{ github.event.inputs.environment || 'dev' }}
      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service: ${{ secrets.ECS_SERVICE }}
          cluster: ${{ secrets.ECS_CLUSTER }}
          wait-for-service-stability: true

      - name: Create commit comment
        if: github.event_name == 'repository_dispatch'
        uses: peter-evans/commit-comment@v1
        with:
          body: |
            ${{ github.event.client_payload.jira-issue }} has been deployed in ${{ github.event.client_payload.env }}

A few things to pay attention to:

  • Lines 34–36: This is the trigger we defined through the webhook in the JIRA automation rule. Be sure to have the exact same value for event type as the one defined in the webhook’s custom data. Otherwise, this workflow will not be triggered.
  • Line 58: This is where GitHub Environments does its magic. We pass in the env value defined in the webhook custom data in the form of ${{ github.event.client_payload.env }}. This tells GitHub to extract that particular environment’s secrets and validate against its protection rules to deploy artifacts to that particular environment.
  • Lines 188–193: Was added to commit a comment after the above steps, so users who watch this repo get notified by email that the particular JIRA issue has been deployed to the environment selected in JIRA.

Final Result

Here’s the overview of a simplified deployment process triggered by JIRA issues:

  1. A developer gets assigned a JIRA ticket to work on, the developer creates a feature branch off of the main branch, names the branch with the JIRA issue number, pushes code, raises PR, and merges PR after approval.
  2. The user (developer or product owner?) changes the JIRA ticket status to DEV, JIRA automation triggers GitHub actions workflow to deploy the artifacts to DEV environment.
  3. For any bug fixes, the developer fixes the code, pushes code, raises PR, and merges PR after approval.
  4. In case of bug fixes, JIRA status can be changed to a different value, such as IN PROGRESS, then changed back to DEV, which triggers the latest artifact deployment to DEV environment again.
  5. Once DEV testing is done, the user changes the JIRA status to QA, follows the same process above to move on to higher environments such as PROD.
  6. A JIRA report can be pulled up at any point for all open tickets with their status field reflecting various stages of their deployment status.
  7. On the GitHub side, all artifacts reside in the main branch. One workflow handles both CI and CD for all environments with variables for environment and JIRA issue number passed in from the JIRA automation rule.
  8. Encourage to configure environment protection rule in GitHub, at least for the higher environments, so each deployment will need to be approved by one or multiple designated people. This is also to avoid fat-fingering in JIRA status updates.

Summary

In this article, we explored JIRA automation rules, webhook configuration details, GitHub Environments, and GitHub actions workflow. It’s interesting to unfold the automation magic between JIRA and GitHub.

The real exciting part is that this is merely one use case, and there are so many more flows we can automate between JIRA and GitHub. Have fun exploring!

Original article source at: https://betterprogramming.pub/automation-with-jira-webhook-and-github-actions-workflow-fcd7efbf6688

#jira #webhook #github