Commit Graph

14 Commits

Author SHA1 Message Date
kiloreux ee5d881ad3 ci: Move from Travis to GitHub Actions (#308)
* Initial commit

* trimpath error

* Test

* test priority

* Another versiong

* ON push only

* Build also

* Enable GO11MODULE

* Disable trimpath

* Separate jobs

* Change stuff

* Matrix build again

* Remove mapping

* Don't use script

* Disable version temp

* Restore

* Deploy on master only

* Deploy on master push

* Remove unused code

* Rename GitHub token secret

The GITHUB_ prefix is reserved (see https://help.github.com/en/articles/virtual-environments-for-github-actions#naming-conventions) and I was not able to create a secret called GITHUB_TOKEN
2019-10-01 17:58:22 +02:00
Marius 59213a5b3a ci: Remove leading 'v' from version for Debian packages 2019-09-20 11:06:25 +02:00
Marius a6a305f1c0 ci: Remove paths from Go binaries for easier use with plugins 2019-09-20 11:05:53 +02:00
Marius 619555607a ci: Enable builds for Windows again 2019-09-20 11:05:31 +02:00
Marius 03d478eb5c fixup! misc: Remove dots from folders 2019-09-12 21:39:00 +02:00
Acconut a70bd4cfa3 rewrite tusd
* expose tusd.DataStore and extracted FileStore
* use pat for routing
* allow absolute BasePaths
* requires StripPrefix
* add support for 1.0 core
* update date in license
2015-02-01 14:57:57 +01:00
Kevin van Zonneveld 022ad36077 Compatibility note 2013-05-08 15:45:25 +02:00
Kevin van Zonneveld 5945dc06d9 Disable the partial get as it wasn't supported by the protocol
it used to be, but not intentionally. now results in a
CopyN of size %!s(int64=26) failed with: EOF
(it tries to copy the full range),
so disabling
2013-03-29 22:57:48 +01:00
Felix Geisendörfer 817129c2a5 Revert "Turn every @todo 404 into an actual 404"
This reverts commit 7601e3a77e.
2013-03-28 15:20:47 +01:00
Kevin van Zonneveld 7601e3a77e Turn every @todo 404 into an actual 404 2013-03-27 22:30:48 +01:00
Kevin van Zonneveld f67ce78c4d Bash script now correctly puts 2 parts.
So what triggered the previous error was an invalid range. What
remains weird is why a failed PUT would still be retrievable
2013-03-20 17:53:45 +01:00
Kevin van Zonneveld d4718fc6f0 Whitespace and small fixes 2013-03-20 17:53:09 +01:00
Kevin van Zonneveld e68f74faa0 put fails, but it looks like full data is still available.
The second PUT fails, the HEAD also claims to only have 3 bytes,
that would be inline with the fail. However the final get is able
to return the full 6 bytes. 3 of which are stored by the 2nd PUT that
was reported to fail.
2013-03-20 16:51:06 +01:00
Kevin van Zonneveld 6ac7656bec Demo script. Without a `tr -d '\r'`, this will currently hang the HEAD indefinitely 2013-03-20 16:19:31 +01:00