During migration commit links are "Fixed", "Removed" but not "Added" - azure-devops-migration-tools

When I run migration in azure-devops-migration-tools, there is Fixing, Removing of commit links, but no Adding.
As a result commit links do not get migrated.
However it doesn't reproduce in every project - in most projects this works fine and commits also get added. For example:
My WorkItemMigrationConfig:
{
"ObjectType": "VstsSyncMigrator.Engine.Configuration.Processing.WorkItemMigrationConfig",
"ReplayRevisions": true,
"PrefixProjectToNodes": false,
"UpdateCreatedDate": true,
"UpdateCreatedBy": true,
"UpdateSourceReflectedId": false,
"BuildFieldTable": false,
"AppendMigrationToolSignatureFooter": false,
"QueryBit": "AND [System.ID] = 41128",
"OrderBit": "[System.ChangedDate] desc",
"Enabled": true,
"LinkMigration": true,
"AttachmentMigration": true,
"AttachmentWorkingPath": "c:\\temp\\WorkItemAttachmentWorkingFolder\\",
"FixHtmlAttachmentLinks": false,
"SkipToFinalRevisedWorkItemType": false,
"WorkItemCreateRetryLimit": 5,
"FilterWorkItemsThatAlreadyExistInTarget": true,
"PauseAfterEachWorkItem": false,
"AttachmentMazSize": 480000000,
"CollapseRevisions": false
}
I suspect this may be project specific, but currently I have no idea what is causing the issue. What may be the reason for this?
//edit
After some research in the tool's source code I have found that commit links are only added if commit link URIs are different (https://github.com/nkdAgility/azure-devops-migration-tools/blob/9ef6ee4fd863de30d8a2179450bc86cb5cfafeb5/src/VstsSyncMigrator.Core/Execution/OMatics/RepoOMatic.cs#L137)
In my case these links are the same because TFS / AzureDevops project IDs are the same, as destination project is a result of cloning source project's collection.

In order for this to work the Git repository must be in the target first! If you have changes the name of the Git Repository you must add it to the mapping.
FixGitCommitLinks - Allows you to fix the migrated Git commit hooks (and
thus external links) to point to the new repository in the target
project. If the source and target repository names are the same, this
will work out of the box. If the target repository has a different
name, you can specify that name via the “TargetRepository” property
https://nkdagility.github.io/azure-devops-migration-tools/
This is slightly out of date, you need to use a "GitRepoMapping" similar as the "WorkItemTypeDefinition" element in the yaml that maps all of the old names to the new names. Again it is only needed when you use a different name from the source.

Related

How should we reduce the number of files generated by nuxt generate?

We generate our Jamstack site with nuxt generate and deploy to Cloudflare. Going Full Static. However we have a problem with frequent failures to deploy to Cloudflare. We contacted Cloudflare and were told we had too many deploy files.
So we want to reduce the number of files generated by nuxt generate. How can we configure our settings to reduce the number of files generated? For example, is there a setting that combines some of the generated files into one?
Initially, we tried to reduce the file size and display it more quickly. However, as it is now, deployments fail and information is not updated. We are now willing to sacrifice a little file size and display speed in order to always provide the latest information.
We have not added any special settings. Part of nuxt.config.js is as follows.
export default {
target: 'static',
build: {
html: {
minify: {
collapseBooleanAttributes: true,
decodeEntities: true,
minifyCSS: false,
minifyJS: false,
processConditionalComments: true,
removeEmptyAttributes: true,
removeRedundantAttributes: true,
trimCustomFragments: true,
useShortDoctype: true,
},
},
},
generate: {
subFolders: false,
},
}
We tried the following settings to no avail.
export default {
splitChunks: {
layouts: false,
pages: false,
commons: false
}
}

Unable to migrate teams and their members associated with a project in ADO using azure-devops-migration-tools

what configuration do i need to use to migrate the teams and members of the team associated with a project from one org to another.
Below is the configuration i tried but it didn't seem to work.
{
"$type": "TeamMigrationConfig",
"Enabled": true,
"PrefixProjectToNodes": false,
"EnableTeamSettingsMigration": true,
"FixTeamSettingsForExistingTeams": false
}

Migrating WorkItems that have no longer existing 'Team Project' references in their history fails

While migrating a project across two distinct Azure DevOps Organizations with the following config for the processor:
{
"ObjectType": "VstsSyncMigrator.Engine.Configuration.Processing.WorkItemMigrationConfig",
"Enabled": true,
"PrefixProjectToNodes": false,
"UpdateCreatedDate": true,
"UpdateCreatedBy": true,
"AppendMigrationToolSignatureFooter": false,
"LinkMigration": true,
"AttachmentMigration": true,
"AttachmentMazSize": 480000000,
"AttachmentWorkingPath": "c:\\temp\\WorkItemAttachmentWorkingFolder\\",
"FixHtmlAttachmentLinks": true,
"SkipToFinalRevisedWorkItemType": false,
"WorkItemCreateRetryLimit": 5,
"PauseAfterEachWorkItem": false,
"FilterWorkItemsThatAlreadyExistInTarget": false,
"BuildFieldTable": false,
"QueryBit": "AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan') ",
"OrderBit": "[System.ChangedDate] desc",
"ReplayRevisions": true,
"CollapseRevisions": false
}
The process fails in the items that, in any of their revisions, reference Team Projects that no longer exist - those items were moved across projects within the same Organization in the past, and the originating project was in the meanwhile deleted.
[ User Story][Complete: 18/3284][sid:1471 |Rev:64 ][tid:null | Microsoft.TeamFoundation.WorkItemTracking.Client.DeniedOrNotExistException: TF26192: The team project specified by the ID 129 does not exist. Check the team project ID and try again.
at Microsoft.TeamFoundation.WorkItemTracking.Client.ProjectCollection.GetById(Int32 projectId)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.CheckUpdateCachedData(Boolean projectChanged, Boolean typeChanged)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.get_Type()
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemFieldData.Microsoft.TeamFoundation.WorkItemTracking.Internals.IWorkItemOpenFieldDataHelper.SetLatestData(Dictionary`2 latestData)
at Microsoft.TeamFoundation.WorkItemTracking.Internals.WorkItemHelper.LoadWorkItemFieldData(IRowSetCollectionHelper tables, IWorkItemOpenFieldDataHelper helper)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem.LoadWorkItemFromRowSetInternal(Int32 rev, Nullable`1 asof, IWorkItemRowSets witem)
at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem..ctor(WorkItemStore store, Int32 id, Int32 revision)
at VstsSyncMigrator.Engine.WorkItemStoreContext.GetRevision(WorkItem workItem, Int32 revision) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\ComponentContext\WorkItemStoreContext.cs:line 202
at VstsSyncMigrator.Engine.WorkItemMigrationContext.ReplayRevisions(List`1 revisionsToMigrate, WorkItem sourceWorkItem, WorkItem targetWorkItem, Project destProject, WorkItemStoreContext sourceStore, Int32 current, WorkItemStoreContext targetStore) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 361
Is there any way to overcome this while maintaining the full revision history?
The issue is overcome if I migrate only the tip revisions.

How to fix vuejs env variables not beeing used

The problem is that I am not able to use env variables, associated with Vue (Using Typescript, if that makes any difference). When declaring an URL for an endpoint and trying to serve, it just uses localhost, which leads me to believe that something in my setup is not done properly.
I've tried setting it up following Vue's own documentation:
https://cli.vuejs.org/guide/mode-and-env.html#modes
Furthermore I've tryed following this guy, which is excatly what I need:
https://code-maze.com/vuejs-axios-http-environment-files/
I've tried a few more different approaches, all with the same result, but theese two are the most topical ones.
Maybe it has something with my setup in my tsconfig.json to do, but to be honest, I'm not sure where the fault could be.
//tsconfig.json
{
"compilerOptions": {
"outDir": "./built/",
"sourceMap": true,
"strict": true,
"noImplicitThis": true,
"noImplicitReturns": true,
"noImplicitAny": true,
"module": "es2015",
"experimentalDecorators": true,
"emitDecoratorMetadata": true,
"moduleResolution": "node",
"target": "es5",
"lib": [
"es2016",
"dom"
]
},
"include": [
"./src/"
]
}
I've read some solutions where webpack plays in, but as far as I know this should not be needed, since Vue uses its own web bundling.

Frustration with inconsistent Emmet results in VSCode

I moved to VSCode from ST3 about 6 or 7 months ago now and overall am loving it. But I'm really struggling with inconsistencies in how Emmet/VSCode expands text...
For example: (these examples are as per the cheat sheet)
fl should give me float:left, but instead i get flex: gif
m:a should give me margin:auto - although since ST3 i've always used m- for this. However in VScode: I get max-block-size: gif
ttu should give me text-transform:uppercase, but instead I get text-underline-position:
p20-40 should give me padding: 20px 40px but in this case, nothing happens - doesn't recoginize it at all
w100p should give me width:100% but again, doesn't even recognize it <-- probably the most annoying one because I use this so often.
and even HTML borks out quite often: .div-class becomes .div-class<?php <-- no idea whats going on here... gif
It almost seems that VSCode has its own built-in Emmet, which is always conflicting with actual Emmet. I'll be the first to admit that it might be a conflicting option in my settings.json, so here is my settings file:
{
"editor.tabSize": 2,
"editor.minimap.enabled": false,
"editor.acceptSuggestionOnEnter": "smart",
"editor.wordBasedSuggestions": false,
"editor.quickSuggestions": {
"other": true,
"comments": false,
"strings": true
},
"editor.tabCompletion": true,
"editor.renderWhitespace": "boundary",
"editor.snippetSuggestions": "top",
"editor.occurrencesHighlight": false,
"editor.selectionHighlight": false,
"editor.renderIndentGuides": true,
"editor.autoIndent": true,
"php.suggest.basic": false,
"php.validate.executablePath": "/usr/local/php5/bin/php",
"workbench.colorTheme": "Bimbo Theme",
"workbench.iconTheme": "vs-seti",
"workbench.startupEditor": "none",
"workbench.editor.tabCloseButton": "left",
"workbench.commandPalette.preserveInput": true,
"workbench.tips.enabled": false,
"window.zoomLevel": 0,
"git.enableSmartCommit": true
}
I have removed settings relating to font sizes and themes etc.
Other Info:
VSCode Version 1.15.1 (1.15.1)
Extensions
Would really appreciate it if someone who isn't experiencing these issues could share their settings file so I can fix my frustration and carry on loving VSCode?
Thanks :)
That's because Emmet is interfering with autocomplete. Try typing any of these commands and execute from command palette Emmet: Expand Abbreviation.
You can remap keybinding for emmet command editor.emmet.action.expandAbbreviation
You can disable autocomplete for css (to show autocomplete when needed Trigger Suggest Ctrl+Space)
"[css]": {
"editor.quickSuggestions": {
"other": false,
"comments": false,
"strings": false
}
}
From version 1.16 August 2017 you can move emmet snippets on top and still have autocomplete:
"emmet.showSuggestionsAsSnippets": true,
"editor.snippetSuggestions": "top"