iamwillbar

// Copyright (c) Microsoft Corporation. All rights reserved.
// Licensed under the MIT License.
const ghrequestor = require('ghrequestor');

function discoverRefFromGitHub(id, version, licenseStore, sourceRepositoryUrl, gitHubUrl) {
  return ghrequestor.getAll(`https://api.github.com/repos/${encodeURIComponent(gitHubUrl.owner)}/${encodeURIComponent(gitHubUrl.name)}/git/refs`, {
    headers: {
      'User-Agent': 'msftgits/component-metadata-service',
      'Authorization': 'token ' + config.get('GITHUB_TOKEN')
    },

iamwillbar

Keybase proof

I hereby claim:

• I am iamwillbar on github.
• I am iamwillbar (https://keybase.io/iamwillbar) on keybase.
• I have a public key whose fingerprint is 7243 ECF1 451D D541 D9BD 5042 1DD6 A822 B850 9A5A

To claim this, I am signing this object:

iamwillbar

- hosts: all
  vars_files:
    - vault.yaml
  become: "{{ ansible_ssh_user is undefined or ansible_user == ansible_ssh_user | ternary('yes', 'no') }}"
  become_method: su
  tasks:
    - group:
        name: ansible
        gid: 1000
        state: present

iamwillbar

{
  "_1": "// Commit -> CI/CD (GitHub Actions) +-> Build Artifact",
  "_2": "//                                  |-> npm Package",
  "_3": "// Caveats: Physical representation, some data excluded, readability over brevity (mostly)",

  "id": "https://api.github.com/iamwillbar/license-list-XML/sboms#repository_f4ab225",
  "_type": "Document",
  "name": "SBOM for iamwillbar/license-listXML@f4ab225",
  "createdBy": "https://api.github.com/users/iamwillbar#v3",
  "externalMap": [

iamwillbar

SPDX 3.0 Primer

Principles

Domain/use case specific profiles

SPDX documents must conform to the Core profile but can opt-in to additional profiles to support the use cases they are intending to address. This layering allows SPDX to be used for different use cases (licensing, security, bill of materials, …) while allowing adopters to focus on only the use cases they care about.

Separate logical and physical models

SPDX is a single logical model but can be represented by different physical models. These physical models may be to support different formats (JSON, YAML, …) or to allow more compact representation of the logical model. A logical model should be serializable to any of the defined physical models and any of the defined physical models should be deserializable to the logical model. This allows interop between formats and ensures the constraints defined in the logical model aren’t violated.

Extend beyond software

The Core profile will not constrain itself to the software domain allowing