Trigger staging deploy whenever a PR is merged to master about jaas.ai HOT 7 CLOSED

@barrymcgee added a few tasks to check what can be done with it

Needs to be done

• Investigate where github webhook endpoint is on jenkins
• Add webhook on organisation to push merges on master to jenkins
• Test it 😄 #winning

from jaas.ai.

Okay I think I've achieved this:

• I setup the webhook

• I pushed an empty commit to master

• This triggered webhook 14cdc8b0-5be0-11e9-9f0b-2cbe36c0a612, which succeeded (200 status)

• This started a build, which pushed commit 8cc847f to https://staging.jaas.ai (you can also see an entry in the GitHubPollLog)

• https://staging.jaas.ai looks up-to-date, as in it has the new header, merged since the previous deployment. And we can also see the correct commit ID in the headers:

  $ curl -Is https://staging.jaas.ai | grep revision
  x-vcs-revision: 1554935373-8cc847f

So I think we can call that success.

I filed https://github.com/ubuntudesign/base-squad/issues/471 to track the next step, which is to create a portal to make it easier to trigger production deployments.

from jaas.ai.

@tbille Would you be able to help me with this, please? I'm hoping it's a quick settings change in the Jenkins config? I had a quick look and fiddled with some settings but it doesn't seem to be working?

from jaas.ai.

So this has been the ultimate plan for every site for a while, but I'm worried that Just Doing It will actually produce a worse experience for developers. Here's why (#clickbait):

At the moment, the flow from master to production is:

• trigger the staging build
• follow the log output
• when it's finished, click the link - which takes you over to the product job with the image_tag filled in for you
• build the production job

If we simply automated the staging build step then instead the flow becomes:

• open the staging build
• find the latest build, that was run automatically
• open the log
• scroll to the bottom
• click the link to take you to production job with the image_tag filled in for you
• build the production job

This seems to me clunky and fundamentally less intuitive - it will feel unnatural and constantly annoying to have to open the staging job log, for a job you didn't start - and also doesn't really save you a whole lot of time.

So my plan for fixing this is to develop a page, similar to http://project-builds.demo.haus, which would know what version was on staging and provide you with a simple "deploy to production" link to start the job, reducing the production deployment steps significantly:

• open the production builds page
• click the link
• build the production job

I think now would be a good time to schedule the building of that webpage in the base squad. @tbille could you help me put that in the plan?

from jaas.ai.

Actually, sorry, I just properly read the Reasons:

@barrymcgee: In order to improve collaboration and communication with the design team, I want them to be able to quickly be able to view the staging site and know immediately what work has landed.

For this reason I imagine @barrymcgee will tell me the clunky developer release experience is tolerable so you get the benefit of designers immediately seeing the state of master. So we could Just Enable It. But we should still prioritise the building of that page to smooth the production release process.

from jaas.ai.

@nottrobin Excellent - thank you! I would also add that your first step assumption assumes that a developer deploys to staging but never actually leaves the Jenkins portal to check the site in their browser.

In my experience, there is always a step to return to Jenkins to find the last completed job to staging before deploying to prod.

Delighted this is done though and new status page is a great idea! 👌🏻👌🏻👌🏻

from jaas.ai.

@barrymcgee yeah fair enough. I always keep the staging deployment log open after running it, so it all seems a bit more linked to me than if it was automatically triggered, but I can appreciate that YMMV.

Which kinda means we need the portal even more ;)

from jaas.ai.