DEV Community: ADS-BNE

4 handy snippets for your Cypress tests

ADS-BNE — Sun, 09 Nov 2025 23:38:26 +0000

This is the start of my growing list of handy JavaScript code snippets for the Cypress Testing Framework. I will update as I go.

Checking something includes “either/or” with “satisfy”

In this example we're checking if the page's URL includes one of 2 strings.

cy.url().should('satisfy', (url) => {
    return url.includes(pathStringA) || url.includes(pathStringB);
})

Get an element’s tag type

Check what tag and element has eg <a>, <div>, <h1> etc

cy.get('.heading').then(($element) => {
    const tagName = $element[0].tagName;
    cy.task('log', tagName); // returns 'H1'
});

Check if an element exists (or doesn’t exist)

Simply check if an element with a given class or ID exists on the page or not.

cy.get('body').then(($body) => {
  if ($body.find('.some-element').length == 0) {
    //do something if element doesn't exist
  }
  else {
    //do something if element does exist
  }
});

Checking URL statuses and redirects

Check if a given URL is working and if it is or isnt' a redirect. This can be handy for reporting which links are redirects.

const urlInterceptResp = (link) => {
    cy.intercept('GET', '**/*').as('getRequests');
    let reportMsg = ""; // reportMsg = the output
    cy.visit(link).then(() => {
        cy.wait('@getRequests').then((interception) => {
            if (interception.response.statusCode >= 300 && interception.response.statusCode < 400) {
                reportMsg = `is working, and redirecting to ${interception.response.headers.location}`;
            }
            else {
                reportMsg = `is working normally`;
            }
            cy.task('log', `${link}: ${reportMsg}`);
        });
    });
    // If visit() fails then intercept() won't run so we log errors this way.
    cy.on('fail', (err, runnable) => {
        cy.task('log', `${link}: ${err}`);
        throw new Error(`${testName + ' ' + link}: fail. ${err}`);
    });
}

Cover photo by Madzery Ma

Using Cypress to test multiple web pages as a logged-in user

ADS-BNE — Mon, 30 Jun 2025 02:11:24 +0000

Sometimes you need to test multiple pages when logged in as a user. This became apparent for me when I was testing a site that relied on a user to login to review content changes before articles were published.

Whilst we had a suite of Cypress tests for the live site, we didn't have any for the 'preview' versions of the site's blog article content, and so were faced with the challenge of being only able to run tests after a release.

Here's how we went about using Cypress' sessions to test our pages as a logged in user.

TL;DR:

Create a login() Custom Command in commands.js that passes a username and password to your site's login form.
Set your test account's username and password somewhere safely.
Save your test account's username and password, and a boolean saying whether to run as a logged in user or not in Cypress' Environment Variables.
Add a conditional, in e2e.js, that runs before each test that logs the user in using the login() Custom Command.

Step 1: Creating a Custom Command to login a user and create a session

First, we need to actually need to create the process for Cypress to login as a user. We need a special command to do that.

Cypress allows you to create Custom Commands for your project. Unsurprisingly, these are stored in commands.js (cypress/e2e/support/commands.js).

Our login Custom Command should simply do the following:

Take username and password values as arguments
Navigate to the login page
Fill out and submit the login form (username, password fields) - just usual Cypress cy.() stuff
Register a new 'session' (eg new cookies) with Cypress and cache it

My Custom Command login script looks like:

//cypress/e2e/support/commands.js
Cypress.Commands.add('login', (username, password) => {
    cy.session([username, password], () => {
        cy.visit('/login');
        cy.get("#username").type(username);
        cy.get("#password").type(password);
        cy.get('#login-btn').click();
    },{
        cacheAcrossSpecs: true
    });
});

Note the cy.session() function and the cacheAcrossSpecs: true setting.

Step 2 (optional): Saving your username and password

Next we want to save our username and password somewhere for our new login Custom Command to use.

Now, you could just hard code them into the Custom Command above, but that's not entirely advisable if you're pushing them on a shared git repo or something like that. But if you want to do that or just set them some other way you can skip this step.

For myself, I opted to create a users.js (cypress/e2e/support/users.js) file to save them on and used .gitignore to exclude from being pushed up to Github.

//cypress/e2e/support/users.js
module.exports.uatUser = {
    un: "myUserAcc",
    pw: "myP4ssw0rd",
};

In .gitignore: cypress/e2e/support/users.js

Step 3: Setting Environment Variables

We need to make our username and password available to all our test spec files. We also need a way to tell Cypress if we want to run the test as a logged in user, or just a normal public user.

The way we do that is with Cypress' Environment Variables. These are simply variables that are available to Cypress across all tests.

First, we need know if we want to run the test as a logged in user or not. I did this using an npm Environment Config (not to be confused with Cypress' own Environment Variables). These are simply values taken from the command line input, eg: process.env.npm_config_hello is set by adding --hello=world to your command.

For example, to create a variable to tell Cypress we are going to run something as a logged in user we make a new constant:

const userLoggedIn = process.env.npm_config_loggedIn === "yes" ? 'yes' : '';

And in our command line we'd run: node ./cypress/e2e/myTests.js --loggedIn-yes to set it.

There are many ways to set Environment Variables in Cypress, but as I run my tests via the Module API .run() function I just include them as such:

//myTests.js
const cypress = require('cypress');
const user = require('./support/users.js'); //<- where I've stored my 
const userLoggedIn = process.env.npm_config_loggedIn === "yes" ? 'yes' : '';
// Array of my test spec files.
const specs = [
    `./homePage.spec.js`,
    `./aboutPage.spec.js`,
     //etc
];
// Run Cypress
cypress.run({
    browser: 'chrome',
    headed: false,
    spec: specs,
    env: {
        loggedIn: userLoggedIn, //<- set from the command line
        userName: user.uatUser.un, //<- this login var from users.js
        password: user.uatUser.pw, //<- this login var from users.js
    }
});

In this way, we are making our environment, username and password available to all our tests.

Step 4: Logging-in, or checking the session, before each test is run

We need to ensure that our user is logged in before each test runs. You might think we need to run our Login Custom Command before each test starts. And you'd be right. But, lucky for us we don't actually need to update each of our test specs to do this.

Instead, we can simply add the follow to our support/e2e.js file:

//support/e2e.js
before(() => {
    if (Cypress.env('loggedIn') == 'yes'){
        cy.task('log', `Running test as a logged in user ------------`);
        cy.login( Cypress.env('userName'), Cypress.env('password'));
    }
})

As you can guess, the before() function runs before each test starts. It's the same as adding it to each test's spec.js file, but a lot less work.

Note, we are passing it the loggedIn, username and password values we set in our Cypress environment variables (obviously, we're not going to login if the loggedIn value isn't yes).

Now, just to clear something up: When I first was looking into this I was concerned that the above code meant that Cypress would have to login before every, single, test. This is not so.

Remember when we added cacheAcrossSpecs: true above? That allows Cypress to cache to the user session and so only run the login process once per set of tests. In other words Cypress will not waste time re-filling out the login form for each consecutive test if it has already logged in once.

And that should be it! You can now run your set of tests both as a logged in and non-logged in user!

For my example above, to run tests as a logged in user I would simply run: node ./cypress/e2e/myTests.js --loggedIn==yes

Cover photo by Markus Spiske

Setting up Selenium Webdriver with Node.js for automated testing

ADS-BNE — Tue, 21 May 2024 00:25:55 +0000

To get get started, we need 3 ingredients: Node.js, Selenium Webdriver and a browser driver.

What is Selenium Webdriver?

The Selenium open source project provides a range of tools for browser automation. Whilst the regression testing of websites is not the only thing Selenium Webdriver is built for, it is most often used for this.

Why use it with Node.js?

Node.js is a cross-platform JavaScript runtime environment that allows you to run JavaScript code outside of a web browser. It lets developers write applications in JavaScript, the advantage being (among some speed improvements) many web developers are already familiar with this language.

What are browser drivers?

Browser drivers act as a proxy between your Selenium testing code and the browsers themselves.

Chrome’s browser drivers: ChromeDriver
FireFox’s browser drivers: GeckoDriver
Edge’s browser drivers: Microsoft Edge WebDriver
Safari has browser drivers already built in.

Let's create a simple 'test'

The goal here is to simply open FireFox, navigate to Google and search for the term “Hello World!”, display the results for 5 seconds, then quit.

If you haven’t already, download and install Node.js.
Create a new project/directory, open it in terminal and run npm init to create a new Node.js project.
Install Selenium Webdriver with npm install selenium-webdriver
Download Geckodriver for Firefox. I just placed this in my newly created directory.
Add the Geckodriver.exe file to your PATHS variables. On Mac, get the route to the file (right click > Get Info), then run the command sudo vi /etc/paths in your terminal (using Vim) and add the path on a new line. Use echo $PATH to check if it was added correctly. On Windows there is a GUI to do this.
Create a new file in your directory (eg: test.js) and paste in the following code:

const {Builder, By, Key, until} = require('selenium-webdriver');

(async function example() {
  let driver = await new Builder().forBrowser("firefox").build();
  try {
    await driver.get('http://www.google.com');
    await driver.findElement(By.name('q')).sendKeys('Hello World!', Key.RETURN);
    await driver.wait(until.titleIs('Hello World! - Google Search'), 5000);
  } finally {
    await driver.quit();
  }
})();

Let's break down what's going on here:

We're running a Selenium function that first triggers a new instance of FireFox.
We're telling that instance of FireFox to navigate to google.com
We're finding the element with the name q (aka the Google search text input field) and entering the values Hello World! by simulating keyboard inputs, followed by the Return key.
We're waiting until the title of the page becomes Hello World! - Google Search (note this must be an exact match), then waiting 5 seconds before closing the browser down.

Finally, let's try to run this script. Run the command node test.js from your terminal.

Firefox should fire up on it’s own, redirect to google.com and search for the term “Hello World!”, then close itself after 5 seconds.

Troubleshooting

Didn't work? Try the following:

Ensure your chosen WebDriver version matches up with your browser's version. I found FireFox and Geckodriver to be a little more forgiving in terms of this problem.
If things are happening a little too fast you can comment out the line await driver.quit(); so that FireFox does not automatically close.
Do your own manual search for "Hello World!" and ensure the Google search results page's title text matches up with 'Hello World! - Google Search'.

Photo by Rodolfo Clix: https://www.pexels.com/photo/photo-of-clear-glass-measuring-cup-lot-1366942/

How to check for broken links using Selenium Webdriver on Node.js (automated testing)

ADS-BNE — Mon, 13 May 2024 01:12:01 +0000

Cover photo by Miguel Á. Padriñán

So you're building automated tests using Node, Cucumber JS, and Selenium Webdriver (I have written more about this here)? Here's a way to test for pesky broken links.

One of the easiest ways to check for broken links is to simply read their status codes: 200 ✅ good, 301 or 404 ❌ bad.

However, it seems Selenium Webdriver does not have an out-of-the-box way to read status codes. No matter, since we're writing these tests on Node we can use an npm package: xhr2. xhr2 is a simple tool that uses XMLHttpRequest to send and receive data from a server. In this case we are simply asking it to give the servers response/status code when asking for a document via a given url or path.

Install xhr2 into your Node project the normal way: npm i xhr2

Now, if you're using Cucumber.JS like me, you can write your test's .feature file. In mine I'm going to cycle through some given pages and check that all links within my site's footer are working (ie, returning 200 status codes).

check-footer.feature

Feature: Check footer links

    Scenario: Check for broken links in the footer section on these pages
        Given I am checking the footer on the '<page>' page
        Then there should be no broken links on '<page>'

        Examples: 
        | page                          |
        | about-us                      |
        | contact-us                    |
        | products                      |

Now, on my steps file:

checkFooterSteps.js

const { When, Then, Given, After } = require('@cucumber/cucumber');
const assert = require('assert');
const { Builder, By, until, Key, http } = require('selenium-webdriver');
const firefox = require('selenium-webdriver/firefox');
// Don't forget to include xhr2.
const XMLHttpRequest = require('xhr2');

var {setDefaultTimeout} = require('@cucumber/cucumber');
setDefaultTimeout(60 * 1000);

// Uses Firefox to load each page listed in the .features file.
Given('I am checking the footer on the {string} page', async function (string) {
    this.driver = new Builder()
        .forBrowser('firefox')
        .build();

    this.driver.wait(until.elementLocated(By.className('logo-image')));

    await this.driver.get('https://www.your-site.com/' + string);
});

// For each page find all <a> tags from within the .footer element.
// Get each <a> tag's href value and store in urlArr array.
// For each value in urlArr run it through the checkLink() function.
// Use assert() to check returned status value is 200.
Then('there should be no broken links on {string}', async function(string) {
    var urlArr = [];
    var footerLinks = await this.driver.findElements(By.css('.footer a'));
    for (let i = 0; i < footerLinks.length; i++) {
        var url = await footerLinks[i].getAttribute("href");
        urlArr.push(url);
    }

    if (urlArr.length  < 1) {
        console.log(`Could not find any links on ${string} page`);
    }
    else {
        for (let i = 0; i < urlArr.length; i++) {
            var respStatus = await checkLink(urlArr[i]);
            assert.ok(respStatus==200);
        }
    }
});

// xhr2 link checker function
function checkLink(url) {
    return new Promise((resolve, reject) => {
        const xhr = new XMLHttpRequest();
        xhr.open('HEAD', url, true);

        xhr.onload = () => {
            if (xhr.status >= 200 && xhr.status < 400) {
                resolve(xhr.status);
            } else {
                reject(`HTTP status code ${xhr.status}`);
            }
        };

        xhr.onerror = () => {
            reject("Network error or URL not reachable");
        };

        xhr.send();
    });
}

What this is doing is:

looping through each page I've provided on the Cucumber.js file
for each page, gathering a list of href attribute values from each <a> tag within the .footer element
running each URL through the checkLink() function, which returns the HTTP status code.
Using Node's assert function to check if the returned value is 200.

Note, this JS code probably still needs to be improved and optimised.

9 things I wish I knew when learning to use Selenium Webdriver with Node.JS

ADS-BNE — Mon, 18 Dec 2023 01:35:50 +0000

A short while ago I was tasked with setting up automated testing on a website. I inherited some existing tests written in Java, but, being a web developer, I felt that the tests would be easier for me to write in JavaScript on Node.js.

This was for the most part true, but there were certain areas lacking in the official Selenium Webdriver documentation for JavaScript.

So, to save others the trouble of trying to convert Python or Java examples to JavaScript, here's some things that I learnt along the way. Note: I am using Cucumber.js as well.

I'm using the npm packages selenium-webdriver and Cucumber.js.

Turning off Geo Location

This is set an an option in your browser settings before you run build against. For example, for FireFox:

let options = new firefox.Options();
    options.setPreference('geo.enabled', false);
const driver = new Builder()
    .forBrowser('firefox')
    .setFirefoxOptions(options)
    .build();

Dismissing alerts

The Selenium documentation gives the way to dismiss alerts in JavaScript as:

await alert.dismiss();

For the life of me, I could not get this to work. An alternative is to automatically dismiss alerts as a browser setting, like above:

let options = new firefox.Options();
    options.setAlertBehavior('dismiss');
const driver = new Builder()
    .forBrowser('firefox')
    .setFirefoxOptions(options)
    .build();

Getting clean text from an element

Retrieving text content is relatively easy with Selenium's .getText() method. However some browsers like Safari also grab a bunch of junk like line breaks and empty spaces. So it's better to clean this up with regular JavaScript, as such:

var resultsCountText = await driver.findElement(By.className('search-results_count')).getText();
resultsCountText = resultsCountText.replace(/\n|\r|/g, "");
resultsCountText = resultsCountText.trim();

Getting text from a hidden element

Sometimes you might just want to get text content from an element like a modal or mega-menu that is just not visible on the page. That's where .getAttribute("innerText") comes in handy.

let modalContent = await driver.findElement(By.className('modal-body')).getAttribute("innerText");

Remember this may need cleaning up, as above.

Repeating the same test for multiple pages

This can be achieved using Cucumber's Scenario Outline. Say, if I wanted to ensure the footer is present on a give list of pages, my .feature file might look like:

    Scenario Outline: Run a check to see if the footer is present
        Given I am on the '<page>' page
        Then the footer section should be present

    Examples: 
        | page           |
        | about-us       |
        | products       |
        | contact-us     |
        | store-locations|

The values in the above table are paths to the aforementioned pages. In my steps .js file I would have something like:

Given('I am on the {string} page', async function (string) {
    this.driver = new Builder()
        .forBrowser('firefox')
        .build();
this.driver.wait(until.elementLocated(By.className('logo')));
    await this.driver.get('https://www.your-website.com/' + string);
});

Then('the footer section should be present', async function() {
  var footerContent = await webdriver.driver.findElement(By.css('footer')).getText();
  assert.ok(footerContent.length>1);
});

Iterating through a series of elements

Say you have a group of .card elements and simply want to test if each has a title. driver.findElements() (note the s) returns a collection of elements which you can simply loop through. This works particularly well with Cucumber/Gherkin datatables.

Then('the prod card titles should be', async function (dataTable) {
    var productCard = await this.driver.findElements(By.className('product-card'));
    var expectations = dataTable.hashes();
    for (let i = 0; i < expectations.length; i++) {
        const productName = await productElements[i].findElement(By.className('product-card_title')).getText();
    assert.equal(productName, expectations[i].productName);
    }
});

Locating multiple elements that share the same class with Xpath

Xpath is a way of accessing specific pieces of content in an XML file. Selenium can make use of this way of locating data by converting the HTML page to an XML file. This is specifically handy when pulling data from HTML elements that all share the same class name.

Consider trying to obtain the price data from the following HTML:

<div class="prod-card">
  <div class="prices">
    <div class="price-wrap">
      From: 
      <div class="price">$9.99</div>
    </div>
    <div class="price-wrap">
      To: 
      <div class="price">$19.99</div>
    </div>
  </div>
</div>

Obviously the issue here is there are no unique identifiers between the 2 .price elements.

However, we can use Selenium's Xpath to locate the first and second instance of .price, as such:

let lowerPrice = await driver.findElement(By.xpath("(//div[@class='price'])[1]")).getText();
let higherPrice = await driver.findElement(By.xpath("(//div[@class='price'])[2]")).getText();

Using different kinds of Explicit Waits when Implicit Waits just won't work

Happy to be proved wrong, but the Implicit Waits as per the Selenium Documentation just never worked for me. At all.

Instead, I had to get creative using Explicit Waits (until.).

For example, on a page whose content is altered with JavaScript (eg a Store Locator page that uses the Google Maps API) I had to wait until the text of an element changed, eg:

await driver.wait(until.stalenessOf(driver.findElement(By.id('location'))));
await driver.wait(until.elementTextContains(driver.findElement(By.id('location')), 'New content!'));

Note I had to pair this with until.stalenessOf(). Instead of waiting a couple of sections for the JavaScript on the page to do its thing and alter the content on the DOM, I instead waited for a particular element's text content to change.

The comments in the files in the `/lib` directory are very useful

For some reason, with the Selenium Webdriver npm package at least, there seem to be way more undocumented methods available. I found it actually incredibly useful to simply poke around the /lib directory of the selenium-webdriver package.

For example, the file node_modules/selenium-webdriver/lib/until.js lists a whole host of very useful Explicit Wait methods:

module.exports = {
  elementTextMatches,
  elementTextContains,
  elementTextIs,
  elementIsNotSelected,
  elementIsSelected,
  elementIsDisabled,
  ableToSwitchToFrame,
  elementIsEnabled,
  elementIsNotVisible,
  elementIsVisible,
  stalenessOf,
  elementsLocated,
  elementLocated,
  urlMatches,
  urlContains,
  urlIs,
  titleMatches,
  titleContains,
  alertIsPresent,
  titleIs,
}

Extra: Checking for broken links

I've written another tutorial for how to check for broken links here.

Cover photo by Markus Spiske on Unsplash

How do I actually get data from a CMS into my React component?

ADS-BNE — Wed, 02 Aug 2023 00:01:30 +0000

I am new to React and my immediate goal is to build React components locally and use them within my existing CMS. The end goal is to eventually go headless, but that is far down the road at this point.

Ideally I want to have a JS object on a page in the CMS that has all the variables/props I need for the React component I want to put there.

The issues I'm facing are:

Building React locally without having access to this data.
Getting the built/compiled React component to "see" this data once it's been uploaded to the CMS.

For the issue with building locally I tried using ternary operators and try/catches to set the props, eg:

const greeting = cmsComponentObj.title ? cmsComponentObj.title : 'Data not from CMS object';

But since cmsComponentObj was not defined anywhere the build failed.

I'm a bit lost as to how to achieve this. Can anyone point me in the right direction?

Where do I start when I want to build a React App based existing JS?

ADS-BNE — Mon, 08 Nov 2021 04:31:28 +0000

So, I'm the first to admit I really struggle with React. I'm fine with JS and JQuery and have even completed many, many React tutorials. But when it comes to converting an existing JavaScript script into a React component, I'm completely stumped.

Right now I have a JavaScript script that is moderately complex.

It reads user data from and object in an external .js file.
Based off that data (or combinations of that data) the script writes elements to the DOM or fires off a modal.

So, for example, a simple if statement might be:

if (userdata.userage > 50 && userdata.userjob.userincome > 100000){
  $(".js-modal-body").load(info[key].content);
  $('#alertModal').foundation('open');
  Cookies.set(modalName, '1', { expires: 7 })
}

And so on.

I won't paste the whole code in here, but basically it consists of:

An import, brining in the userData object from a user.js file.
A stand-alone helper function that returns the user's age based of their inputted date-of-birth and today's date.
A series of if statements like the one above. Some if statements fire off Modals, some write new card elements to the DOM. Some also create cookies.

My question is where do I start when want to convert this to react?

Explain Private and Public keys (SSH) Like I'm Five

ADS-BNE — Sat, 19 Jun 2021 01:31:26 +0000

On paper I think I understand the concept: you have a matching key file to one on a remote machine that grants you access. Yet, I've never been able to get these working. It's a mysterious box to me.

ELI5?

Simple way to overcome the multiple SCSS files issue with Shopify

ADS-BNE — Thu, 15 Oct 2020 04:07:00 +0000

Shopify uses SCSS already (and compiles it on the server), but only allows you to work on one .scss file, meaning you miss out on splitting up your styles into more manageable, separate files.

Here's a simple (and a little hacky) solution I came up with:

We compile our multiple scss files into a normal theme.css file, but then use Gulp to rename that file to theme.scss.liquid.

We will use Gulp for 2 things - building SCSS and deploying to the server (the latter is optional. Themekit already does this).

I am using the gulp-shopify-upload plugin for transferring files to Shopify's server (more info on that here https://www.npmjs.com/package/gulp-shopify-upload).

My gulpfile.js looks as such:

const gulp = require('gulp');
const sass = require('gulp-sass');
const rename = require('gulp-rename');
const gulpShopify = require('gulp-shopify-upload');
const watch = require('gulp-watch');

// Normal .scss compilation.
gulp.task('sass', function(){
  return gulp.src('assets/scss/theme.scss')
    .pipe(sass().on('error', sass.logError))
    .pipe(gulp.dest('css'));
});

// Rename css.
gulp.task('rename', function(){
  return gulp.src("css/theme.css")
  .pipe(rename("theme.scss.liquid"))
  .pipe(gulp.dest("assets"));
});

// Compile and rename css.
gulp.task('do-sass', gulp.series('sass', 'rename'));

// Watch files, upload to Shopify server.
gulp.task('shopifywatch', function() {
  gulp.watch('assets/scss/**/*.scss', gulp.series('do-sass'));
  return watch('./+(assets|layout|config|sections|snippets|templates|locales)/**')
.pipe(gulpShopify('API KEY', 'PASSWORD', 'MYSITE.myshopify.com', 'THEME ID'));
});

And that's it. Running gulp shopifywatch now compiles SCSS files, watches normal files and shoots everything up to the server. It might complain about .scss, but it's just a warning.

Improving Neto development workflow with Github's Actions

ADS-BNE — Tue, 08 Sep 2020 23:34:29 +0000

The Goal

Ultimately, to improve workflow when working on Neto sites.

The main goals are:

Create a staging version of the current Neto theme.
Easily deploy both the staging and production themes via the command line. Allows devs and clients to easily view the staging version of the site theme.
Implement Git for sub-versioning.

The workflow we're creating:

Developer creates new staging branch against master. Does coding work, pushes staging branch to Github and Github Actions deploys to staging theme on Neto's server.
Client/Stakeholders test on staging theme (in Neto's case by just adding ?nview=my-theme-stg to the site URL).
Once work is approved, developer merges stage to master. Github Actions automatically deploys changes to the live theme.

Setting up Github Actions

We need 2 Github Action files, One for deploying to production, one for deploying to staging.

Step 1: Create the .yml files

Locally, in your repo create 2 new .yml files (and folder structure if needed): .github/workflows/main.yml and .github/workflows/stg.workflow.yml. These will house the code for our Github action.

On the main.yml file

We're going to use this Action: FTP Deploy. To use, simply paste in the following code into your main.yml file:

on:
  push:
    branches:
      - master
name: Publish Website
jobs:
  FTP-Deploy-Action:
    name: FTP-Deploy-Action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2.1.0
      with:
        fetch-depth: 2
    - name: FTP-Deploy-Action
      uses: SamKirkland/FTP-Deploy-Action@3.1.1
      with:
        ftp-server: sftp://sftp.neto.com.au:1022/httpdocs/assets/themes/my-theme
        ftp-username: ${{ secrets.FTP_USERNAME }}
        ftp-password: ${{ secrets.FTP_PASSWORD }}
        local-dir: src/
        git-ftp-args: --insecure

So, a few things to note:

The lines:

on:
  push:
    branches:
      - master

Tell Github when the jobs: below are to be run. In this case the jobs will run when there is a push to the repo's master branch.

The next section of the above code is the job FTP-Deploy-Action. For Neto (and indeed most other FTP applications) this can remain the same. You will, however, need to update a few small things:

ftp-server: sftp://sftp.neto.com.au:1022/httpdocs/assets/themes/my-theme/

Not only does this line refer to the server name, but also the transfer protocol (sftp://), the port number (:1022) and the location directory (/httpdocs/assets/themes/). For Neto you might just need to change the location directory path.

local-dir: src/

This obviously refers to the local directory. In my case, I've got a bunch of things in the route of my repo and only want to deploy the stuff in the src directory.

On the stg.workflow.yml file

Copy the above main.yml file's contents into stg.workflow.yml to create an Actions file for staging deployment. We're going to change 2 things:

Change when the job runs to when we push to the stage branch:

on:
  push:
    branches:
      - stage

And change the destination directory to your staging theme:

ftp-server: sftp://sftp.neto.com.au:1022/httpdocs/assets/themes/my-theme-stg

Push these files up to your remote repo.

As for ftp-password and ftp-username, we'll deal with those in the next step.

Step 2: Set up Secrets in Github to store our FTP login and passwords

Secrets allow you to store sensitive information like usernames and passwords for, say, your FTP account. To add them go to your repo's Settings page, then Secrets tab. Simply hit New Secret at the top right of the page, give it a name (eg: FTP_USERNAME) and a value. Note, only 1 name and value pair per Secret.

Step 3: Testing

I simply created a dummy test.txt file in my src/ directory and pushed it to master. You can see the Action run your repo's Action tab. Click the Action's name to see the live log. For a sanity check, I just used Filezilla to confirm this new test.txt file appeared on the remote server.

I repeated the exact same test for the stage branch.

The first time you run FTP Deploy it may take 1 or 2 minutes to index everything.

Note that merging stage to master will also trigger a deploy to master.

Additional stuff (optional)

Since pushing to master now deploys to the live server we might want a way to confirm that's what the developer actually wants to do (don't want to deploy by accident).

We can add the Protected Branches script below which will ask the user to confirm if they want to deploy. This lives in the .git/hooks/pre-push file.

Are you sure you want to push to master? (y/n):

BRANCH=`git rev-parse --abbrev-ref HEAD`
PROTECTED_BRANCHES="^(master|dev|release-*|patch-*)"

if [[ "$BRANCH" =~ $PROTECTED_BRANCHES ]]; then
  read -p "Are you sure you want to push to \"$BRANCH\" ? (y/n): " -n 1 -r < /dev/tty
  echo
  if [[ $REPLY =~ ^[Yy]$ ]]; then
    exit 0
  fi
  echo "Push aborted."
  exit 1
fi
exit 0