qwe321qwe321qwe321

With GitHub Actions, a workflow can publish artifacts, typically logs or binaries. As of early 2020, the life time of an artifact is hard-coded to 90 days (this may change in the future). After 90 days, an artifact is automatically deleted. But, in the meantime, artifacts for a repository may accumulate and generate mega-bytes or even giga-bytes of data files.

It is unclear if there is a size limit for the total accumulated size of artifacts for a public repository. But GitHub cannot reasonably let multi-giga-bytes of artifacts data accumulate without doing anything. So, if your workflows regularly produce large artifacts (such as "nightly build" procedures for instance), it is wise to cleanup and delete older artifacts without waiting for the 90 days limit.

Using the Web page for the "Actions" of a repository, it is possible to browse old workflow runs and manually delete artifacts. But the procedure is slow and tedious. It is fine to delete one selected artifact. It is not for a regular cleanup. We need

sktse

How to Keep Pull Requests Manageable

• There are a lot different things you can try to keep pull requests manageable.
• These pointers are not meant to be rules, but merely guidelines when possible. Due to the nature of what you are working on, some of these techniques may not be possible (or incredibly difficult).

• Either way, here are some tips to help make people not want to claw their eyes out reviewing a pull request.

The Basics

• These are the fundamental basics to a pull request and ALL pull requests should have these, regardless of how small or meaningless it is.

mkauf

mariotacke

#!/bin/sh
### BEGIN INIT INFO
# Provides:          TeamCity Build Agent
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start build agent daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

bwbaugh

# Mirror of the instructions available here:
# http://www.lowefamily.com.au/2016/06/02/installing-ubiquiti-unifi-controller-5-on-raspberry-pi/
#
# These commands CANNOT be run in a script.
# They're just for reference.


# Install on Raspbian Jessie, or upgrade from Wheezy.
# Make sure all packages are upgraded (update && upgrade).

reggi

How to setup AWS lambda function to talk to the internet and VPC

I'm going to walk you through the steps for setting up a AWS Lambda to talk to the internet and a VPC. Let's dive in.

So it might be really unintuitive at first but lambda functions have three states.

1. No VPC, where it can talk openly to the web, but can't talk to any of your AWS services.
2. VPC, the default setting where the lambda function can talk to your AWS services but can't talk to the web.
3. VPC with NAT, The best of both worlds, AWS services and web.

paxmanchris

<?php
require('mysql.php'); // see https://gist.github.com/paxmanchris/f5d4b94f67a8acd8cefc
$me = 'http://'.$_SERVER['HTTP_HOST'].$_SERVER['SCRIPT_NAME'];

$sso_secret = 'YOUR_SSO_PROVIDER_KEY_HERE';
$discourse_url = 'http://example.com';



if(!empty($_GET) and isset($_GET['sso'])){

mzabriskie

If you're like me you have a dir like ~/Workspace/Github where all your git repos live. I often find myself making a change in a repo, getting side tracked and ending up in another repo, or off doing something else all together. After a while I end up with several repos with modifications. This script helps me pick up where I left off by checking the status of all my repos, instead of having to check each one individually.

Usage:

git-status [directory]

This will run git status on each repo under the directory specified. If called with no directory provided it will default to the current directory.