Related
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
}
}
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.
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.
I've been able to create a grid and basic filtering to narrow down iterations etc. Ideally I would like to run this via html/confluence so ideally I need to have the filtering set so that I can filter on parent as well as project. Testing this in the Rally dashboard, the way I have it still only working within project I'm sitting in. How do I make my filtering work so that where I'm at project wise in Rally doesn't matter or if I use my api key.
Thanks!
Mark
Ext.create('Rally.data.wsapi.TreeStoreBuilder').build({
models: ['userstory'],
autoLoad: true,
enableHierarchy: true,
filters: [{property: 'Iteration.Name',
operator : '=',
value : 'March'},
{property: 'Project.Parent.Name',
operator : '=',
value : 'Synergy'},
{property: 'Project.Name',
operator : '=',
value : 'Condor'}
]
}).then({
success: function(store) {
Ext.create('Ext.Container', {
items: [{
xtype: 'rallytreegrid',
columnCfgs: [
'DisplayColor',
'Name',
'ScheduleState',
'Blocked',
'TaskEstimateTotal',
'TaskRemainingTotal',
'Owner',
'Notes'
],
store: store
}],
renderTo: Ext.getBody()
});
}
});
You just need to pass a context to your store:
https://help.rallydev.com/apps/2.0/doc/#!/guide/data_stores-section-scoping
All projects:
{ project: null, workspace: '/workspace/12345'}
Specific project:
{ project: '/project/12345', projectScopeDown: false, projectScopeUp: false }
Project hierarchy:
{ project: '/project/12345', projectScopeDown: true, projectScopeUp: false }
Or if you are trying to get data from multiple projects not in a tree you can always create a filter in the store on Project like you're doing above. Note that you'll need to make sure all those projects are actually in scope based on your context to get any results.
I need to store account settings for each account profile. I decided to use SQL DB for this, but not sure should I go with complex data (json/xml).
I found answers
Using a Single Row configuration table in SQL Server database. Bad idea?
https://softwareengineering.stackexchange.com/questions/163606/configuration-data-single-row-table-vs-name-value-pair-table
but none of them discusses using single row approach containing complex data
Complex data would be stored inside a following DB table
AccountID int
AccountSettings nvarchar(max)
and would contain AccountSettings data such as
"settings": {
"branding": {
"header_color": "1A00C3",
"page_background_color": "333333",
"tab_background_color": "3915A2",
"text_color": "FFFFFF",
"header_logo_url": "/path/to/header_logo.png",
"favicon_url": "/path/to/favicon.png",
},
"apps": {
"use": true,
"create_private": false,
"create_public": true
},
"tickets": {
"comments_public_by_default": true,
"list_newest_comments_first": true,
"collaboration": true,
"private_attachments": true,
"agent_collision": true
"list_empty_views": true,
"maximum_personal_views_to_list": 12,
"tagging": true,
"markdown_ticket_comments": false
},
"chat": {
"maximum_request_count": 5,
"welcome_message": "Hello, how may I help you?",
"enabled": true
},
"voice": {
"enabled": true,
"maintenance": false,
"logging": true
},
"twitter": {
"shorten_url": "optional"
},
"users": {
"tagging": true,
"time_zone_selection": true,
"language_selection": true
},
"billing": {
"backend": 'internal'
},
"brands": {
"default_brand_id": 47
},
"active_features": {
"on_hold_status": true,
"user_tagging": true,
"ticket_tagging": true,
"topic_suggestion": true,
"voice": true,
"business_hours": true,
"facebook_login": true,
"google_login": true,
"twitter_login": true,
"forum_analytics": true,
"agent_forwarding": true,
"chat": true,
"chat_about_my_ticket": true,
"customer_satisfaction": true,
"csat_reason_code": true,
"screencasts": true,
"markdown": true,
"language_detection": true,
"bcc_archiving": true,
"allow_ccs": true,
"advanced_analytics": true,
"sandbox": true,
"suspended_ticket_notification": true,
"twitter": true,
"facebook": true,
"feedback_tabs": true,
"dynamic_contents": true,
"light_agents": true
},
"ticket_sharing_partners": [
"foo#example.com"
]
}
Other solution is a widely used single row approach such as
AccountID int
SettingsName nvarchar(max)
SettingsValue nvarchar(max)
that could hold data such as
AccountID SettingsName SettingsValue
1 Branding.Header_Color 1A00C3
1 Branding.Page_Background_Color 333333
1 Apps.Use true
......
I assume both solutions are valid and would depend based on application needs, but would REALLY like to know is there an issue that i am not seeing when using complex data with single row approach to store application settings?
One concern is if you have a busy large database, you cannot do ONLINE re-indexing (if you have the Enterprise version) on XML, text, varchar(max) type fields. This causes grief for 2008 R2. The newer versions of MS SQL Server can re-index online varchar(max) fields, so it depends on which version you are running.
Also, you won't be able to query or index if you need to search for specific records, unless you go with the SettingsName, SettingsValue type of table, which I've used a lot. This solves the re-index online issue (if that applies to your situation), as well as indexing the fields for quick queries.