Im currently managing the weight file by dvc. This is the dvc file:
outs:
- md5: b2c80e73090cae013eef778308faf8fc
size: 202055043
path: checkpoint_1.pth.tar
So I would like to create a dvc config file so that when it's necessary to change the weight file then I change the dvc config file. My current config yaml file for the weights is like
...
robot_perception_detector:
ros__parameters:
weights: /home/ros2/foxy/src/robot_pkg/data/model_weights/checkpoint_1.pth.tar
....
Any help and advice how this config file should looks like so that works in both cases?
You are probably looking for Templating. The very first example templates an output file:
params.yaml:
models:
us:
threshold: 10
filename: 'model-us.hdf5'
dvc.yaml:
stages:
build-us:
cmd: >-
python train.py
--thresh ${models.us.threshold}
--out ${models.us.filename}
outs:
- ${models.us.filename}:
cache: true
Please give it a try, let us know if something is not working as expected.
Related
I am trying to configure my spec flow project with the Azure CI pipeline. When I try to create Specflow+LivingDoc with TestExecution.json, the pipeline is unable to find the path. Attaching my YAML, and specflow.json along with this. Can anybody help me with this??
YAML
- task: SpecFlowPlus#0
displayName: 'Upload SpecFlow Living Docs'
inputs:
projectFilePath: 'MyProjecct'
projectName: 'MyProjecct'
testExecutionJson: '**\TestExecution.json'
projectLanguage: 'en'
specflow.json
{
"livingDocGenerator": {
"enabled": true,
"filePath": "{CurrentDirectory}\\TestResults\\TestExecution.json"
}
}
Error
Error
##[error]Error: Command failed: dotnet D:\a_tasks\SpecFlowPlus_32f3fe66-8bfc-476e-8e2c-9b4b59432ffa\0.6.859\CLI\LivingDoc.CLI.dll feature-folder "D:\a\1\s\MyProjecct" --output-type JSON --test-execution-json "**/TestExecution.json" --output "D:\a\1\s\16707\FeatureData.json" --project-name "MyProjecct" --project-language "en"
Before the SpecFlowPlus task you can add a shell task (such as Bask) to execute the ls command to see if the TestExecution.json file has been generated or existing in the specified Feature folder under current directory.
ls -R
If the TestExecution.json file is not existing, you should go to check if there is any issue on the step that generates this file.
I got the same error when I tried to configure this a few days back.
Try giving the full path to your TestExecution.json, that should work. The pattern matching is not working in the file paths so provide full path to your json files as well as project/test assembly etc...
Hello I'm using VueJS 2 and I have multiple .env in my project.
My app have .env for each company to select the company configuration (skin color / files...)
Actually I have all my .env in the root folder:
.env.company1-dev
.env.company1-staging
.env.company1-prod
.env.company2-dev
.env.company2-staging
.env.company2-prod
.env.company3-dev
.env.company3-staging
.env.company3-prod
So when I'll get 20 companies it will be confused on my root folder so it is possible to create a folder where I can place all my .env ?
The idea :
/environments/company1/
.env.dev
.env.staging
.env.prod
/environments/company2/
.env.dev
.env.staging
.env.prod
/environments/company3/
.env.dev
.env.staging
.env.prod
On your vue.config.js file you can add:
const dotenv = require("dotenv");
const path = require("path");
let envfile = ".env";
if (process.env.NODE_ENV) {
envfile += "." + process.env.NODE_ENV;
}
const result = dotenv.config({
path: path.resolve(`environments/${process.env.VUE_APP_COMPANY}`, envfile)
});
// optional: check for errors
if (result.error) {
throw result.error;
}
the before run you can set VUE_APP_COMPANY to a company name and run your app,
Note: It's important to put this code on vue.config.js and not in main.js because dotenv will use fs to read files.
References
https://github.com/motdotla/dotenv#path
https://github.com/vuejs/vue-cli/issues/787
https://cli.vuejs.org/guide/mode-and-env.html#environment-variables
The accepted answer we have also used in the past. But I found a better solution to handle different environments. Using the npm package dotenv-flow allows not only the use of different environments but has some more benefits like:
local overwriting of variables by using .env.local or .env.staging.local and so on
definition of defaults using .env.defaults
In combination we have set up our projects with this configuration:
.env
.env.defaults
.env.development
.env.production
.env.staging
.env.test
And the only thing you have to do in your vue.config.js, nuxt.config.js or other entry points is
require('dotenv-flow').config()
Reference: https://www.npmjs.com/package/dotenv-flow
The powershell solution
I was handling exactly the same problem. Accepted solution is kind of ok, but it did not solve all differences between companies. Also, if you are using npm, your scripts can look nasty. So if you have powershell, here is what I suggest - get rid of the .env files :)
You can keep your structure like you want in the question. Just convert the env files to ps1.
/build/company1/
build-dev.ps1
build-stage.ps1
build-prod.ps1
/build/company2/
build-dev.ps1
build-stage.ps1
build-prod.ps1
Inside each of those, you can fully customize all env variables, run build process and apply some advanced post-build logic (like careful auto-deploy, publishing, merging with api project, ..).
So for example company1\build-stage.ps1 can look like this:
# You can pass some arguments to the script
param (
[string]$appName = "company1"
)
# Set environment variables for vue pipeline
$env:VUE_APP_ENVIRONMENT = "company1-stage";
$env:NODE_ENV="development";
$env:VUE_APP_NAME=$appName;
$env:VUE_APP_API_BASE_URL="https://company1.stage.mycompany.com"
# Run the vue pipeline build
vue-cli-service build;
# Any additional logic e.g.
# Copy-Item -Path "./dist" -Destination "my-server/my-app" -Recurse¨
Last part is easy - just call it (manualy or from integration service like TeamCity). Or, you can put it inside package.json.
...
"scripts": {
"build-company1-stage": "#powershell -Command ./build/company1/build-stage.ps1 -appName Company-One",
}
...
The you can call whole build process just by calling
npm run build-company1-stage
Similary, you can create localhost, dev, prod, test and any other environment. Let the javascript handle the part of building the app itself. For other advanced work, use poweshell. I think that this solution gives you much more flexibility for configuration and build process.
P.S.
I know that this way I'm merging configuration and build process, but you can always extract the configuration outside the file if it gets bigger.
I am doing the DBT hello world tutorial found here, and I have created my first project on a windows machine. My profiles.yml file looks like this:
my-bigquery-db:
target: dev
outputs:
dev:
type: bigquery
method: service-account
project: abiding-operand-286102
dataset: xxxDBTtestO1
threads: 1
keyfile: C:\Users\xxx\.dbt\abiding-operand-286102-ed9e3c9c13cd.json
timeout_seconds: 300
when I execute dbt run I get:
Running with dbt=0.17.2 Encountered an error while reading profiles: ERROR Runtime Error
dbt encountered an error while trying to read your profiles.yml
file.
Profile my-bigquery-db in profiles.yml is empty
Defined profiles:
my-bigquery-db
target
outputs
dev
type
method
project
dataset
threads
keyfile
timeout_seconds
Any idea?
At first glance from both your code and the source walkthrough, this is just a yml config problem. YML is a markup language that is white-space sensitive. And by just looking at the example that you may have pulled from - it doesn't look appropriately white spaced to me.
I'm not sure if you can simply copy from the below but it might be worth a shot.
my-bigquery-db:
target: dev
outputs:
dev:
type: bigquery
method: service-account
project: abiding-operand-286102
dataset: xxxDBTtestO1
threads: 1
keyfile: C:\Users\xxx\.dbt\abiding-operand-286102-ed9e3c9c13cd.json
timeout_seconds: 300
Basically - your dbt profile.yml needs to be setup with the sections at certain levels (not unlike python indentation or any other white spacing scheme).
Thinking Sphinx works on my Rails app (Rails 3.2.1, TS 3.0.1) but when I set up a sphinx.yml file in the config folder, it doesn't seem to read the morphology instructions.
The file is called sphinx.yml and is in the config folder. Here is the yml format:
development:
morphology: stem_en
production:
morphology: stem_en
I copy/pasted this so the indentation matches wha'ts in my code. I don't use a libstemmer or haven't installed any other wordforms.
Please, I keep my fingers crossed someone can help me on this one as I'm stumped!
And the answer is: read ALL the doco on:
https://github.com/pat/thinking-sphinx/blob/master/README.textile
The new name for the .yml is thinking_sphinx.yml
i am currently attempting to do a diff using review board but keep getting an ambiguous error message:
Error uploading diff
Your review request still exists, but the diff is not attached.
The debug messages do not give much away either, no errors whatsoever....
>>> RBTools 0.4.1
>>> Home = /home/tom
>>> HTTP GETting api/
>>> HTTP GETting http://127.0.0.1/api/info/
>>> Using the new web API
Index: /trunk/0.1/scripts/configure-apache.sh
===================================================================
--- /trunk/0.1/scripts/configure-apache.sh (revision 143)
+++ /trunk/0.1/scripts/configure-apache.sh (working copy)
## -1,5 +1,5 ##
#! /bin/bash
-
+echo hello
cd ..
#SRCHEAD="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
SRCHEAD=$SRC_HEAD
This is what my ".reviewboardrc" file contains:
REVIEWBOARD_URL = "http://127.0.0.1/"
the repository path is: "https://XXX/svn/infinity/trunk/0.1"
does anyone know where i can start in order to resolve this issue i am seeing?
thanks in advance
The problem you are facing may be that the relative path in the diff file is not correlated with the path of the repository as it is configured in Reviewboard.
Reviewboard, in order to find in the repository the files mentioned in the diff, will concatenate the URLs like this:
URL of the repo as configured in Reviewboard
+
optionally - the Base directory as it appears in the
Reviewboard Upload diff dialog - which can be absolute/complete
but also relative(!)
+
the relative path of the modified file as it appears in the diff file.
All these must be correlated.
Therefore, in your case, if your repository configured URL is:
https://XXX/svn/infinity/trunk/0.1
and your relative path in the diff file is:
/trunk/0.1/scripts/configure-apache.sh
... that will not work because the resulting absolute path of the file in the repo will be incorrect:
https://XXX/svn/infinity/trunk/0.1/trunk/0.1/scripts/configure-apache.sh
Possible solutions would be:
Your URL for SVN should be configured in Reviewboard like this:
https://XXX/svn/infinity
OR
The diff should be created at a lower level in the folders hierarchy - in this case it should be done at ../0.1/ level so that the path in the diff file results in /scripts/configure-apache.sh
HTH!
a workaround is to do a manual svn diff and save to a file and then compare the working copy with the trunk in the web ui