[bug] v22.2 contributions required

[EPP-KMD]

Hi, v22.2 broke our pipeline, apparently requiring 1 or more contributions to be defined in extension.json. Is this an intended change?

[james-h-stephens]

@EPP-KMD I had the same issue. If you're still facing the issue and need a mitigation, downgrading to 22.0 did resolve it for me.

[EPP-KMD]

Yes, we switched from 22.x to 22.0 specifically. I do not believe it to be acceptable that a minor version update can brick our pipeline, however.

[james-h-stephens]

100% agreed! Just one dev looking out for another. I had the same issue crop up and just wanted to share the mitigation for you or others who might stumble onto the thread.

[jessehouwing]

Do you have a sample repo that causes this issue? The validation has been in place 10 years already, but the logic calling the validators has changed a bit with a number of dependency updates. Or at least the commandline syntax you're using.

None of my own extensions cause this validation, solving the issue would be expedited if there was a repro.

The validation itself is called here:

tfs-cli/app/exec/extension/_lib/merger.ts

Lines 283 to 291 in e17e51a

	return this.extensionComposer.validate(components).then(validationResult => {
	if (validationResult.length === 0 || this.settings.bypassValidation) {
	return components;
	} else {
	throw new Error(
	"There were errors with your extension. Address the following and re-run the tool.\n" +
	validationResult,
	);
	}

The extensionComposer is setup here:

tfs-cli/app/exec/extension/_lib/merger.ts

Lines 165 to 166 in e17e51a

	this.extensionComposer = ComposerFactory.GetComposer(this.settings, targets);
	this.manifestBuilders = this.extensionComposer.getBuilders();

[jessehouwing]

Simplest way to update to the latest version is to add --bypass-validation, which will skip local validations.

[james-h-stephens]

@jessehouwing Thanks for the update! I am working on trying to get a sample to you, or at least to get the trace logs to write out what is happening. But I don't think it is a validation issue, but rather a manifest globbing issue.

Here is the command I am running:
tfx extension create --manifest-globs azure-devops-extension.json dist/Manifests/**/manifest-*.json --overrides-file azure-devops-extension-dev.json --rev-version --output-path bin

When I run the tool with 22.0, my contributions show up as intended in the extension.vsomanifest:

{
    "manifestVersion": 1,
    "licensing": {
        "overrides": [
            {
                "id": "overview.hub",
                "behavior": "AlwaysInclude"
            }
        ]
    },
    "scopes": [
        "vso.analytics",
        "vso.build",
        "vso.code",
        "vso.project",
        "vso.settings",
        "vso.work_write",
        "vso.work"
    ],
    "contributions": [
		// Contributions which were globbed here
    ],
    "baseUri": "https://localhost:3000",
    "contributionTypes": []
}

However, with 22.2 my contributions only contains the one that is in azure-devops-extension.json

{
    "manifestVersion": 1,
    "licensing": {
        "overrides": [
            {
                "id": "overview.hub",
                "behavior": "AlwaysInclude"
            }
        ]
    },
    "scopes": [
        "vso.analytics",
        "vso.build",
        "vso.code",
        "vso.project",
        "vso.settings",
        "vso.work_write"
        // "vso.work" missing
    ],
    "contributions": [
        // Only my contributions from azure-devops-extension.json here
    ],
    "baseUri": "https://localhost:3000",
    "contributionTypes": []
}

Also note that the scopes changed, presumably from the globbed contributions not getting picked up.

[jessehouwing]

Yeah, looks like a bigger bug that got introduced by the upgrade of the globbing library.

[jessehouwing]

I think I found the culprit. Until this is merged, keep using an older version. This was an unexpected regression caused by upgrading the glob package.