Add automated testing and deployment of the license list to license-list-data repo #592

goneall · 2018-01-02T06:18:55Z

Resolves issue #503 and #504.

Once this PR is reviewed, the LICENSEDATAREPO in the file .travis/publishLicenseList.sh needs to be set to https://github.com/spdx/license-list-data.git

The GITUSERNAME and GITEMAIL should be updated to point to the SPDX legal team prior to merging.

Please review the script publishLicenseList.sh and the .travis.yml files

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

…riginal license text Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

…or a commit to the main repository Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

bradleeedmondson · 2018-01-02T18:57:27Z

This looks good from a 40,000-foot view, but I don't know enough about CI in general or travis in particular to say whether this is ready for production use. Could we post to the tech-list to see if anyone with experience using CI in production is willing to take a look and confirm we meet best practices?

Not sure if there's more to do to try and protect shellscripts from remote-execute (un-chroot) vulnerabilities, but I get a little spooked whenever I see a variable set in one place appended to the command line for execution on another machine/by another process. Also, is there a way we can get the jar from github directly rather than bintray.com? That would shrink the attack surface somewhat.

goneall · 2018-01-02T20:01:33Z

@bradleeedmondson Thanks for the review.

Could we post to the tech-list to see if anyone with experience using CI in production is willing to take a look and confirm we meet best practices?

@sschuberth @tsteenbe @wking @yevster Could you review this PR as well?

I get a little spooked whenever I see a variable set in one place appended to the command line for execution on another machine/by another process

This was a recommended practice from Travis-CI for deploying github pages, although this is a slightly different purpose. It makes me nervous too, definitely a good thing to review. I looked at the more sophisticated approach used for the SPDX Specs Repsitory, but it would also require similar variable setting/use. The variable is encrypted and is set in the github configuration. It is also easily revoked if it gets compromised.

is there a way we can get the jar from github directly rather than bintray.com?

There are only 2 people with access tot he bintray account, myself and @yevster . Since we have this as the deployment mechanism for the Jar files, it should be reasonably safe.

wking

My general impression is that this is coupling the spdx/tools and spdx/license-list-data repos too tightly with this one. I'd rather see most of this logic included in spdx/license-list-data scripts and/or a Makefile. That would also help address the current scarce documentation for building license-list-data, since folks interested in that are more likely to be looking in license-list-data than in .travis/ here.

wking · 2018-01-02T19:38:36Z

.travis.yml

+        before_install:
+          - wget https://dl.bintray.com/spdx/spdx-tools/org/spdx/spdx-tools/2.1.8/spdx-tools-2.1.8-jar-with-dependencies.jar
+        script: 
+          - 'if [[ "$TRAVIS_PULL_REQUEST" = "false" && "$TRAVIS_BRANCH" = "master" ]]; then bash ./.travis/publishLicenseList.sh; else bash ./.travis/testBuildLicenseList.sh; fi'


I think we always want to test, and only conditionally want to publish. That would be something like:

script: - ./.travis/testBuildLicenseList.sh - if [[ "master" = "$TRAVIS_BRANCH" ]]; then ./.travis/publishLicenseList.sh; fi

The changes in the condition are:

Drop $TRAVIS_PULL_REQUEST. If we're on master, we want to push. It doesn't matter if we're in a pull request or not, as far as I can tell. The only issue would be racy pushes (e.g. lots of PRs merged simultaneously, so there are racing Travis runs on the various master commits). I don't see an easy way around that with automatic publication, and don't think $TRAVIS_PULL_REQUEST would help with it anyway.

Re-order the $TRAVIS_BRANCH arguments to put the constant first. This protects test against the unlikely case that $TRAVIS_BRANCH expands to something like a test option/operator (e.g. a branch named !, which appears to be legal in Git 2.13.6).

My suggestion also drops bash, since that's covered by the shebang inside the scripts.

Both scripts test, the publish scripts test AND publish. Since these are long running scripts, I don't want to duplicate the testing that is done as part of publishing. I'll rename the publish script to make this clearer.

Pull requests do matter in terms of security since it may be on an external repo.

I'll re-order the test on the master branch and will drop bash

Pull requests do matter in terms of security since it may be on an external repo.

How does checking the branch name and or PR-ness help address the external-repo case? I'd expect the guard for that being “folks with push rights to license-list-data don't abuse their power”, and not something that happens in the script here.

wking · 2018-01-02T19:41:07Z

test/original/BitTorrent-1.0.txt

+      d. Required Notices. You must duplicate this License in any documentation you provide along with the Source Code of any Modifications you create or to which you contribute, and which you distribute, wherever you describe recipients' rights relating to Licensed Product. You must duplicate the notice contained in Exhibit A (the "Notice") in each file of the Source Code of any copy you distribute of the Licensed Product. If you created a Modification, you may add your name as a Contributor to the Notice. If it is not possible to put the Notice in a particular Source Code file due to its structure, then you must include such Notice in a location (such as a relevant directory file) where a user would be likely to look for such a notice. You may choose to offer, and charge a fee for, warranty, support, indemnity or liability obligations to one or more recipients of Licensed Product. However, you may do so only on your own behalf, and not on behalf of the Licensor or any Contributor. You must make it clear that any such warranty, support, indemnity or liability obligation is offered by you alone, and you hereby agree to indemnify the Licensor and every Contributor for any liability incurred by the Licensor or such Contributor as a result of warranty, support, indemnity or liability terms you offer.
+      e. Distribution of Executable Versions. You may distribute Licensed Product as an executable program under a license of your choice that may contain terms different from this License provided (i) you have satisfied the requirements of Sections 4(a) through 4(d) for that distribution, (ii) you include a conspicuous notice in the executable version, related documentation and collateral materials stating that the Source Code version of the Licensed Product is available under the terms of this License, including a description of how and where you have fulfilled the obligations of Section 4(b), and (iii) you make it clear that any terms that differ from this License are offered by you alone, not by Licensor or any Contributor. You hereby agree to indemnify the Licensor and every Contributor for any liability incurred by Licensor or such Contributor as a result of any terms you offer.
+      f. Distribution of Derivative Works. You may create Derivative Works (e.g., combinations of some or all of the Licensed Product with other code) and distribute the Derivative Works as products under any other license you select, with the proviso that the requirements of this License are fulfilled for those portions of the Derivative Works that consist of the Licensed Product or any Modifications thereto.
+      g. Compensation for Distribution of Executable Versions of Licensed Products, Modifications or Derivative Works. Notwithstanding any provision of this License to the contrary, by distributing, selling, licensing, sublicensing or otherwise making available any Licensed Product, or Modification or Derivative Work thereof, you and Licensor hereby acknowledge and agree that you may sell, license or sublicense for a fee, accept donations or otherwise receive compensation for executable versions of a Licensed Product, without paying a royalty or other fee to the Licensor or any other Contributor, provided that such executable versions (i) contain your or another Contributor's material Modifications, or (ii) are otherwise material Derivative Works. For purposes of this License, an executable version of the Licensed Product will be deemed to contain a material Modification, or will otherwise be deemed a material Derivative Work, if (a) the Licensed Product is modified with your own or a third party's software programs or other code, and/or the Licensed Product is combined with a number of your own or a third party's software programs or code, respectively, and (b) such software programs or code add or contribute material value, functionality or features to the License Product. For the avoidance of doubt, to the extent your executable version of a Licensed Product does not contain your or another Contributor's material Modifications or is otherwise not a material Derivative Work, in each case as contemplated herein, you may not sell, license or sublicense for a fee, accept donations or otherwise receive compensation for such executable. Additionally, without limitation of the foregoing and notwithstanding any provision of this License to the contrary, you cannot charge for, sell, license or sublicense for a fee, accept donations or otherwise receive compensation for the Source Code.


This section is broken, see #589 and goneall/license-test-files#1. I'm still in favor of pulling these in from license-test-files instead of trying to keep this directory and what you have in spdx/license-test-files#6 in sync.

I think we need to get to consensus on this (or decide that we don't need to) before merging the CI tests against known licenses. So far my impression has been that it's just be @goneall and @wking, but hopefully getting some more technical input can help us get to a decision here.

I don't know enough to say for sure which way I'd prefer, nor would I say that my opinion is worth much here (as I am not fully informed), but on the current evidence I think I would lean toward keeping the original texts for testing in this same repo (the idea being that if you PR to add a license, that PR should also contain the original text). From what I can glean from the issues firehose, that seems more like @goneall's position than @wking. But I do not think I should be the deciding vote on this issue.

… evidence I think I would lean toward keeping the original texts for testing in this same repo (the idea being that if you PR to add a license, that PR should also contain the original text).

But do you expect the legal team to review the test text being added in this repo? I think that review would be more likely without the noise like my question about Bash vs. vanilla POSIX and similar. And if you do expect legal-team review of test-text being added here, do you also expect there to be legal-team review when that same (hopefully ;) content is submitted to license-test-files (e.g. with spdx/license-test-files#6)? That seems like twice the work to me.

We did discuss this on one of the legal calls and there was consensus for those attending the call that we could add the license text to the license-list-XML repository.

I don't expect we will gain consensus on this topic and I do not want to be prevented from automating the testing due to the lack of consensus.

We can always change the location of the tests in a future release.

Totally fair -- I didn't recall having addressed this on a call.

I don't expect we will gain consensus on this topic…

Can we at least reach a narrower consensus around BitTorrent-1.0's 4.g being broken or not? I'd really like to avoid committing known-broken test data to this repository.

wking · 2018-01-02T19:42:37Z

.travis/publishLicenseList.sh

@@ -0,0 +1,62 @@
+#!/bin/bash


Do we need anything Bash-specific? I'd rather use the generic POSIX #!/bin/sh.

Prefer bash specific since that is what I am testing against

Prefer bash specific since that is what I am testing against

You can get cheap POSIX-ish tests using bash --posix …. But really, the guard here is to develop based on the POSIX spec instead of relying on your current implementation. If you're not aware of any Bash-isms, I'd prefer we use /bin/sh, I'll review these for conformance, and we'll field bug reports for other shells if/when they come in.

If you don't mind reviewing and/or testing, go ahead and review and make a PR when completed.

wking · 2018-01-02T19:43:08Z

.travis/publishLicenseList.sh

@@ -0,0 +1,62 @@
+#!/bin/bash
+# NOTE: $GITHUB_TOKEN must be defined as an external system variable (e.g. in the Travis-CI respository settings https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings


This line is missing a closing paren.

wking · 2018-01-02T19:43:23Z

.travis/publishLicenseList.sh

@@ -0,0 +1,62 @@
+#!/bin/bash
+# NOTE: $GITHUB_TOKEN must be defined as an external system variable (e.g. in the Travis-CI respository settings https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings
+#TODO Update user ane email before PR to spdx/license-list-XML


“ane” → “and”?

Also, did you mean to address this TODO before filing this PR?

The TODO needs to be done as the last step before merging

wking · 2018-01-02T20:05:31Z

.travis/publishLicenseList.sh

+PUBLISHCMD="LicenseRDFAGenerator $LICENSEXMLDIR $LICENSEOUTPUTDIR $VERSION $RELEASEDATE $TESTDIR $WARNINGSFILE"
+echo running SPDX Tool command $PUBLISHCMD
+java -jar $TOOLSJAR $PUBLISHCMD
+rc=$?; if [[ $rc != 0 ]]; then exit $rc; fi


This sort of error handling is good for every line of the file. The usual way I see it handled (e.g. in sharness) is to chain everything with &&. If that sounds useful but like more work than you're interested, I'm happy to work it up and file a PR against this branch.

I'm working on an update to other parts of the file right now, once that is complete feel to produce a PR. If you want to restructure into a makefile, feel free to make that change as well.

If you want to restructure into a makefile, feel free to make that change as well.

I've stubbed this in with spdx/license-list-data#22.

wking · 2018-01-02T20:06:22Z

.travis/publishLicenseList.sh

+cd $LICENSEOUTPUTDIR
+# Commit and push the changes back to the license data repository
+# Create the push URL including the authentication token
+git add .


This should be git add -A . so you also pick up removals.

Good catch - updated

wking · 2018-01-02T20:09:46Z

.travis/publishLicenseList.sh

+	git push origin --quiet
+else
+# Add a tag and push with the tags
+	git  -a $VERSION -m "Adding release mathing the license list XML tag $VERSION"


I think you want git -a → git tag -a. Also, I'd very much prefer we manually tag license-list-data releases. Then we can:

Sign the tags (e.g. git tag --sign …), so downstream consumers can ensure the tag was approved by an SPDX member.

Review the changes since the last tagged release. A license-list-XML tag does not mean that the Java we're using for auto-publication is bug-free.

Fixed the git tag.

In practice, it is difficult to manually review the license list data. Signing the tag isn't a bad idea, though. We could always review and re-apply the tag after the automated tag.

If we don't automate this, I'm concerned we would miss / forget to tag the license-list-data repo.

In practice, it is difficult to manually review the license list data.

license-list-data $ git diff --word-diff=color v2.6..v3.0 text/ isn't exactly short, but it's still easy enough that I'd rather have it happen before we tag a license-list-data release. And as we address word-wrapping issues, reviewing those diffs should become even easier. Adding a tag that you missed is a lot less troublesome than revoking a tag you shouldn't have made.

That said, if you want to push auto-generated tag to a separate tier in license-list-data (distinct from manually-approved tags in license-list-data), I have no problem with that.

wking · 2018-01-02T20:11:17Z

.travis/publishLicenseList.sh

+	echo Pushing new version to the license list data repository.  This could take a while...
+	git push origin --tags --quiet
+fi
+echo License list data has been published


Instead of printing “it worked” messages, I'd rather just exit 0 (which will happen automatically if the last command exited zero). We want to be printing messages for errors (which should be surprising), not for success (which should be expected).

OK - will change

wking · 2018-01-02T20:14:07Z

.travis/testBuildLicenseList.sh

+WARNINGSFILE="TEMP-WARNINGS"
+echo $IGNOREWARNINGS > $WARNINGSFILE
+# Test and generate the output files
+PUBLISHCMD="LicenseRDFAGenerator $LICENSEXMLDIR $LICENSEOUTPUTDIR $VERSION $RELEASEDATE $TESTDIR $WARNINGSFILE"


Generating RDFa seems unnecessary for validation. Would it be hard to teach spdx/tools a mode that just validates, without writing output? On a related note, it's not clear to me whether successful RDFa generation is sufficient to validate the XML. Is it possible that RDFa generation could succeed, but JSON (or whatever) generation would fail?

Generating RDFa seems unnecessary for validation. Would it be hard to teach spdx/tools a mode that just validates, without writing output?

Yes - more work than I would prefer to do at this point, but not impossible.

If we want to dramatically improve performance, we should only test and translate the XML files which have been added or modified. Currently, it rebuilds all files. This, however, is a lot of work to implement.

wking · 2018-01-02T20:35:47Z

On Tue, Jan 02, 2018 at 12:01:34PM -0800, goneall wrote: > I get a little spooked whenever I see a variable set in one place > appended to the command line for execution on another machine/by > another process This was a recommended practice from Travis-CI…

Just from the foot-gun protection side of things, it would be nice to follow your current NOTE with: test -n "${GITHUB_TOKEN}" || echo '$GITHUB_TOKEN unset' >&2 && exit 1 or similar.

> is there a way we can get the jar from github directly rather than > bintray.com? There are only 2 people with access tot he bintray account…

And also (at least) some unknown subset of Bintray employees. How about: - wget https://dl.bintray.com/spdx/spdx-tools/org/spdx/spdx-tools/2.1.8/spdx-tools-2.1.8-jar-with-dependencies.jar - echo '4871a3f72cd87f5680da4dbda8fbc7805f365b599c8fbfd8f9d9e371b3a2d3b8 spdx-tools-2.1.8-jar-with-dependencies.jar' | sha256sum --check where I've assumed that the current JAR is uncompromised to figure out the hash. Ideally whoever is publishing those JARs (@goneall?) would be able to provide the hash directly. And the even more convenient alternative would be to sign the JARs with OpenPGP so folks could download the signature and verify with GnuPG or similar.

goneall · 2018-01-02T21:44:57Z

@wking Thanks for the detailed review and suggestions.

My general impression is that this is coupling the spdx/tools and spdx/license-list-data repos too tightly with this one. I'd rather see most of this logic included in spdx/license-list-data scripts and/or a Makefile. That would also help address the current scarce documentation for building license-list-data, since folks interested in that are more likely to be looking in license-list-data than in .travis/ here.

I'll just added a pull request to license-list-data to address the documentation. I'll merge that in after merging this change.

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

goneall · 2018-01-02T22:39:31Z

And the even more convenient alternative would be to sign the JARs

The jar files are actually signed and the asc files accompany the jar files in the same bintray directory: https://dl.bintray.com/spdx/spdx-tools/org/spdx/spdx-tools/2.1.8/

I'll look into what changes need to be made to verify the signatures (e.g. do we need to install additional packages in the travis environment).

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Based on the script in-flight with [1], but using an external test-data directory. This script does not cover fetching those directories, but it does cover the build process once they're fetched. I didn't build the JAR myself, so I'm just hashing the JAR that Bintray is currently returning and assuming that is uncompromised. Docs on $@, $<, and $* in [2]. [1]: spdx/license-list-XML#592 [2]: https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html

Signed-off-by: License Publisher(Gary O'Neall) <gary@sourceauditor.com>

goneall · 2018-01-02T23:31:21Z

But I think the Makefile should be in license-list-data (since that's what's getting built), not in this repo (which is one of several data sources feeding license-list-data).

I disagree - I believe the makefile should belong with the source. Two reasons, the make file is run when source code changes (not when the output files change) and it is what is expected in the source code world (you normally don't maintain the makefiles in an output directory, you normally maintain the makefiles with the source). In general, it is easier to setup/run the tools keeping it in the same directory as the source.

goneall · 2018-01-02T23:34:30Z

Can we at least reach a narrower consensus around BitTorrent-1.0's 4.g being broken or not? I'd really like to avoid committing known-broken test data to this repository.

We can consider this a separate issue from where the test data is stored. You present compelling evidence that BitTorrent-1.0's 4.g is indeed broken. IMHO, it should be fixed. I'm merging it into this PR once I get the scripts working on the last set of changes.

Signed-off-by: License Publisher(Gary O'Neall) <gary@sourceauditor.com>

wking · 2018-01-02T23:49:18Z

On Tue, Jan 02, 2018 at 03:31:23PM -0800, goneall wrote: > But I think the Makefile should be in license-list-data (since > that's what's getting built), not in this repo (which is one of > several data sources feeding license-list-data). I disagree - I believe the makefile should belong with the source.

I agree that validation checks should stay here (#593), and I'm ok with auto-publishing from here (although I'd rather not auto-tag [1]). However, I think we can safely punt on auto-publishing for now and focus on validation.

Two reasons, the make file is run when source code changes (not when the output files change)…

Right, but license-list-data isn't solely fed by this repo. It also depends on spdx/tools and the mock FSF API. license-list-data and spdx/tools can make independent design decisions (e.g. adding or removing an output format), and changes like that should have no impact on this repository. [1]: #592 (comment)

… change and the license XML for BitTorrent-1.0 should be made in the same commit to avoid test failure Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Based on the script in-flight with [1], but using an external test-data directory. This script does not cover fetching those directories, but it does cover the build process once they're fetched. I didn't build the JAR myself, so I'm just hashing the JAR that Bintray is currently returning and assuming that is uncompromised. Docs on $@, $<, and $* in [2]. The key in goneall.gpg is 0xEA760AF7CBD0E4F9013F06FB8CCBE63DE91BFF1C, imported with: $ gpg --search 0x8CCBE63DE91BFF1C gpg: data source: http://5.45.108.219:11371 (1) Gary O'Neall (Key for signing jar files) <gary@sourceauditor.com> 4096 bit RSA key 8CCBE63DE91BFF1C, created: 2017-12-13 Keys 1-1 of 1 for "0x8CCBE63DE91BFF1C". Enter number(s), N)ext, or Q)uit > 1 gpg: key 8CCBE63DE91BFF1C: public key "Gary O'Neall (Key for signing jar files) <gary@sourceauditor.com>" imported gpg: Total number processed: 1 gpg: imported: 1 The source keyserver is from hkp://pool.sks-keyservers.net. I then exported the key with: $ gpg --export 0x8CCBE63DE91BFF1C >goneall.gpg When exported without ASCII armor, such keys can be used as a keyring. The --no-default-keyring option disables the user's default keyring (if any. There probably won't be one on Travis). And the --keyring ./goneall.gpg slots in our local file. We need the ./ (at least with GnuPG 2.1.20), because gpg2(1) has: If the filename does not contain a slash, it is assumed to be in the GnuPG home directory ("~/.gnupg" if --homedir or $GNUPGHOME is not used). The output may still include: gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. but that's ok, because gpg still exits zero. And because of our keyring manipulation, we know the key is trusted. Signatures from any other key will instead show: gpg: Can't check signature: No public key and exit 2. [1]: spdx/license-list-XML#592 [2]: https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

…ocal version of the fsf-free-json file Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

goneall · 2018-01-22T23:36:42Z

Closing this PR as the makefile approach from PR #593 has been merged

goneall added 30 commits October 29, 2016 17:40

Test data only, please ignore

a278460

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge remote-tracking branch 'upstream/master'

472daa6

Changing README back

4f530f8

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add deprecated license eCos-2.0

a74b9d7

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge remote-tracking branch 'upstream/master'

53daa61

Merge branch 'master' of https://github.com/goneall/license-list-XML

1b9c0a6

Merge remote-tracking branch 'upstream/master'

dbd6300

Merge branch 'master' of https://github.com/spdx/license-list-XML

718234e

Add travis-CI build files

2aeee5d

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Fix parse error in travis config file

3425d5b

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Make shell script executable

e2e70a7

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Update the continuous testing to test license XML files against the o…

e1a070b

…riginal license text Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add new test case for added license

afe8b2c

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add CLDA-Sharing-1.0 to tests

31d12f9

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge upstream changes

3bc8691

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add both the node and java based tests to Travis

7e50369

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Fix bad spacing in travis file

57047e2

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add test files for BSD-1-Clause and EPL-2.0

0b583c9

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Fix issues identified in license list XML PR #513

13172d0

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge branch 'master' of https://github.com/spdx/license-list-XML

278cc3a

Add license tests for the new licenses added

e10d699

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge branch 'master' of https://github.com/spdx/license-list-XML

28666b0

Add missing copyright to test file

1857ff6

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Update travis for license publishing

9ed696b

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge upstream travis file

a8c3cd0

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add license publishing functionality to Travis-CI

5bf6f59

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add proper location of the publish license list script

3343c57

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Update file permissions

8dbd6ba

Remove unused script

8d90e69

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add test only for pull requests - don't publish unless it is a merge …

51c4de4

…or a commit to the main repository Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

wking reviewed Jan 2, 2018

View reviewed changes

Address review comments for pull request

595cdc8

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add changes per @wking pull request to goneall/license-test-files PR #1

2c1c392

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

wking mentioned this pull request Jan 2, 2018

Makefile: Add a Makefile and build script spdx/license-list-data#22

Closed

Add execution permission to testPublish script

b5ebc6a

Signed-off-by: License Publisher(Gary O'Neall) <gary@sourceauditor.com>

wking mentioned this pull request Jan 2, 2018

Makefile: Use Travis to run canonical-matching tests #593

Merged

Add execution permission to testBuild script

8d3d39b

Signed-off-by: License Publisher(Gary O'Neall) <gary@sourceauditor.com>

goneall added 2 commits January 2, 2018 21:57

Reverting BitTorrent-1.0 test file to commit 7c61df0f9. The test file…

c1a1dd9

… change and the license XML for BitTorrent-1.0 should be made in the same commit to avoid test failure Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add checksum validation to tools jar download

d83fe80

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Comment out tagging releases for the license list publishing

a57d829

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

wking mentioned this pull request Jan 9, 2018

/licenses/licenses.json: All isDeprecatedLicenseId properties are false spdx/tools#144

Closed

jlovejoy assigned goneall Jan 11, 2018

jlovejoy added this to the 3.1 release milestone Jan 11, 2018

goneall added 4 commits January 15, 2018 20:52

Remove section g to match cononical license text

10d9a73

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Add missing quote to the Apache 1.0 license

cc92a1c

Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

Merge remote-tracking branch 'upstream/master'

94faa5c

Update to version 2.1.9 of the SPDX tools and set the switch to use l…

a4dc1f1

…ocal version of the fsf-free-json file Signed-off-by: Gary O'Neall <gary@sourceauditor.com>

goneall closed this Jan 22, 2018

		@@ -0,0 +1,62 @@
		#!/bin/bash
		# NOTE: $GITHUB_TOKEN must be defined as an external system variable (e.g. in the Travis-CI respository settings https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings

Add automated testing and deployment of the license list to license-list-data repo #592

Add automated testing and deployment of the license list to license-list-data repo #592

Conversation

goneall commented Jan 2, 2018

bradleeedmondson commented Jan 2, 2018

goneall commented Jan 2, 2018 • edited Loading

wking left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wking Jan 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wking commented Jan 2, 2018 via email

goneall commented Jan 2, 2018

goneall commented Jan 2, 2018

goneall commented Jan 2, 2018

goneall commented Jan 2, 2018

wking commented Jan 2, 2018 via email

goneall commented Jan 22, 2018

goneall commented Jan 2, 2018 •

edited

Loading

wking Jan 2, 2018 •

edited

Loading