I have a root .stylelintrc file (in YAML format) which has my main configuration. I want to override some of those rules for files in a specific directory, how do I do that? In ESLint I could just create an .eslintrc file in that directory and it would magically happen.
I tried using extends, but I'm not sure if that works for YAML format.
Turns out that in your nested .stylelintrc you can just do:
extends: ../path/to/.stylelintrc
rules:
...
Related
Right now my application repos have directories that look like this:
myapp
code/
myappChartConfig/
myappChart/
dev.yaml
prod.yaml
The chart is in myappChart/ and my dev/prod settings are outside it in dev/prod yaml files. On deploy if it's dev or prod, the right config is supplied with -f.
I want instead to include my dev/prod YAML files inside the chart itself. So when I push the chart to a repo it includes the configs and when I pull it down I get the chart and its configs.
Does Helm support this? This is not the helmignore use case. I want to include these files in the chart but I don't want helm to process them as though they are manifests- they are values files (but not the default values.yaml file, env specific ones).
What I want to avoid is something wonky like naming the files dev.yaml.deploy and then have scripts pull down the chart and move and rename those files before running helm upgrade. It would be nice to refer to them with -f and have them be inside the chart's folder when it's pulled down.
You can split it into 2 charts.
Chart named prod includes a values.yaml file containing the configuration values of prod.
Chart named dev includes a values.yaml file containing the configuration values of dev.
Hope it's useful for you!
I'm completely new to Azure DevOps Pipelines so if I'm doing something incorrectly I'd appreciate a nod in the right direction... I setup a build pipeline and that seems to be working, now I'm trying to setup a release pipeline in order to run tests, it's mostly based on Microsoft's documentation:
https://learn.microsoft.com/en-us/azure/devops/test/run-automated-tests-from-test-hub?view=azure-devops
Before running tests I need to transform a config file to replace some variables like access keys, usernames, etc. What I setup is what I have below but for the life of me I can't figure out what text box Package or folder refers to. The documentation is super helpful as you can imagine:
File path to the package or a folder
but what package or what folder is this referring to??? I've tried several different things but everything errors with
##[error]Error: Nopackagefoundwithspecifiedpattern D:\a\r1\a\**\*.zip
or pretty much whatever I specify for a value.
The File Transform task supports the .zip files.
Test with the default File Transform task settings, I could reproduce this issue.
In Release pipeline, the file path could has one more node for the build artifacts .zip file.
The format example:
$(System.DefaultWorkingDirectory)\{Source alias name}\{Artifacts name}\*.zip
So you could try to set the $(System.DefaultWorkingDirectory)/**/**/*.zip in Package Or folder field
For example:
On the other hand, you can check the specific path in the Release log -> Download Artifacts Step.
$(System.DefaultWorkingDirectory): D:\a\r1\a
You could aslo use this specific path in the task.
Update:
If your file is Project Folder, you refer to the following sample:
File structure：
Task Settings:
Note:You only need to assign to the folder node.
You could also select the folder path via ... option.
I have defined mysoft-ci.yml file in the repo and committed it in. Now I am trying to create a build pipeline with that file but it looks that I cannot get any path working with that.
I have tried with same path I use in the build configuration or the path that is in git but none of those work. Am I missing something?
the problem went away on its own. but in general you need to make sure the file exists in the branch you are targeting and supply the path to the file relative to the repo root.
I know how to make a shared config file for traditional projects and adding them to each project with the following tag:
<appSettings file="../other_project/foo.config">.
How do I share application settings in VSTS, ensuring every role can access the shared config settings? I assume you can't directly reference other projects' config files using relative path names, like in my example above.
I would like to centralize my configuration and make my config transform file relatively short, as there are a lot of projects.
I assume you can't directly reference other projects' config files
using relative path names, like in my example above.
You can manage the config file into solution directory or the root of your git repo.
Then you can add (Add -> Existing Item) the config file for each project separately.
And keep the config file as artifacts, so even when deploying different projects into different machines, the config file will always accessible.
I would like to use the same bluemix delivery pipeline for several apps. Could I export its settings to some template?
Thanks in advance!
From the doc found here,
Section: GENERATING A YAML FILE FROM A PIPELINE
You can generate a YAML file from a pipeline.
Generate the file from an existing pipeline with a URL in this format:
http(s)://<DevOps Services domain>/pipeline/user/project/yaml
This call does not require an accept header. You can use this call from a browser.
Note: For safety reasons, secure-stage environment property values are omitted from generated pipeline YAML files.
To reuse this downloaded template, per the link shared above - simply create a .bluemix folder at the root of your other code project folders and place this template file within this .bluemix folder. The file should be named as pipeline.yml
How to do it nowadays (March 2020)
To export a pipeline simple add /yamlto pipeline url. example:
From:
https://cloud.ibm.com/devops/pipelines/<pipeline-guid>?env_id=<ibm_cloud_region>
To:
https://cloud.ibm.com/devops/pipelines/<pipeline-guid>/yaml?env_id=<ibm_cloud_region>
Download the file and store it as pipeline.yml. Put it inside .bluemix folder in the root of your project as #Sanjay.Joshi said.