aussielunix

*
!/.gitignore
!/*.xml
!/nextBuildNumber

!/jobs
!/jobs/*
!/jobs/*/*.xml
/jobs/*/disk-usage.xml
/jobs/*/builds

Rud5G

# create alias for cli gerrit requests
alias gerrit='ssh -p 29418 gerrit.yourdomain.com gerrit'

# get tempfile for the ids
tmpfileids=$(tempfile -d /tmp)

# get all commit number ids for the project YOUR_PROJECT_NAME
gerrit query 'status:open project:YOUR_PROJECT_NAME' | egrep '^\ +number' | cut -d' ' -f4- > $tmpfileids

# do mass abandon

domenic

Auto-deploying built products to gh-pages with GitHub Actions

This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.

A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:

• It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
• It is free, with no quotas.
• Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.

sleevi

On Twitter the other day, I was lamenting the state of OCSP stapling support on Linux servers, and got asked by several people to write-up what I think the requirements are for OCSP stapling support.

1. Support for keeping a long-lived (disk) cache of OCSP responses.

   This should be fairly simple. Any restarting of the service shouldn't blow away previous responses that were obtained. This doesn't need to be disk, just stable - and disk is an easy stable storage for most server