kmx git

Commit	Date	Message
2d4b2f14	2016-10-20T17:55:55	Travis: Deploy to S3 rather than SourceForge This has the following advantages: -- It doesn't require checking a private SSH key into the repository. (With SourceForge, an SSH key is the "keys to the kingdom".) -- If the S3 key is compromised, it is very easy to revoke it and generate a new one. -- The S3 bucket is isolated, so even if it becomes compromised, then the damage that one could do is limited. -- It's much easier to manage files through S3's web interface than through SourceForge. -- The files are served via HTTPS. -- Travis fully supports S3 as a deployment target, so this simplifies .travis.yml somewhat.
9366cf0b	2016-10-20T01:01:27	Travis: GPG sign Linux binaries/source tarballs Since we're still deploying our Linux/macOS CI artifacts to a web server (specifically SourceForge Project Web Services) that doesn't support HTTPS, it's a good idea to sign them. But since the private key has to be checked into the repository, we use a different key for signing the pre-releases (per project policy, the private signing keys for our release binaries are never made available on any public server.)
1ee329d6	2016-10-07T12:54:55	Travis: Fix deployment issue (2nd attempt)
b47c5e73	2016-10-07T05:34:11	Travis: Fix deployment issue "Skipping a deployment with the script provider because this branch is not permitted"
27f817cd	2016-10-07T05:07:11	Travis: Use existing sandbox for official builds This eliminates the need to specify the remote repository and branch, and it prevents the code from being checked out twice.
6d22430a	2016-10-05T14:36:46	Travis: use correct repo/branch for off. builds Pass the actual repository and branch that Travis is using into the builtljt script, so the official builds it generates will come from the same code base as the other tested builds.
e9e3a2ed	2016-10-05T12:38:59	Travis CI: Use correct key for this repository
211c69f3	2016-10-02T09:13:23	Add Travis CI config for Un*x pre-release builds

2d4b2f14

2016-10-20T17:55:55

Travis: Deploy to S3 rather than SourceForge This has the following advantages: -- It doesn't require checking a private SSH key into the repository. (With SourceForge, an SSH key is the "keys to the kingdom".) -- If the S3 key is compromised, it is very easy to revoke it and generate a new one. -- The S3 bucket is isolated, so even if it becomes compromised, then the damage that one could do is limited. -- It's much easier to manage files through S3's web interface than through SourceForge. -- The files are served via HTTPS. -- Travis fully supports S3 as a deployment target, so this simplifies .travis.yml somewhat.

9366cf0b

2016-10-20T01:01:27

Travis: GPG sign Linux binaries/source tarballs Since we're still deploying our Linux/macOS CI artifacts to a web server (specifically SourceForge Project Web Services) that doesn't support HTTPS, it's a good idea to sign them. But since the private key has to be checked into the repository, we use a different key for signing the pre-releases (per project policy, the private signing keys for our release binaries are never made available on any public server.)

1ee329d6

2016-10-07T12:54:55

Travis: Fix deployment issue (2nd attempt)

b47c5e73

2016-10-07T05:34:11

Travis: Fix deployment issue "Skipping a deployment with the script provider because this branch is not permitted"

27f817cd

2016-10-07T05:07:11

Travis: Use existing sandbox for official builds This eliminates the need to specify the remote repository and branch, and it prevents the code from being checked out twice.

6d22430a

2016-10-05T14:36:46

Travis: use correct repo/branch for off. builds Pass the actual repository and branch that Travis is using into the builtljt script, so the official builds it generates will come from the same code base as the other tested builds.

e9e3a2ed

2016-10-05T12:38:59

Travis CI: Use correct key for this repository

211c69f3

2016-10-02T09:13:23

Add Travis CI config for Un*x pre-release builds

kc3-lang/libjpeg-turbo/.travis.yml

.travis.yml

Log