I'm using SauceLabs for my web component tests through the 'sauce' plugin in the web component tester. I'd like to use this plugin with different configurations depending which branch is being built on my CI.
I.E.: Latest chrome only on dev branches, and the whole battery of browsers/OS on master/staging branches (with deploy env.)
How can I achieve that?
Copy a template file before you start wct
// Test master branch
$ cp wct.conf.master.json wct.conf.json && wct
// Test feature branch
$ cp wct.conf.feature.json wct.conf.json && wct
The best way to do so for now remains the cp/mv method as stated in the official answer, but in web-component-tester#v6.0.0-prerelease.8, they included back the --config option (see this commit), so we'll be able to specify which config file to use at runtime without modifying any file.
Related
I am working with GitHub Actions to build code on Windows, Linux, and MacOS. I use actions/commit#v3 #actions/checkout#v3 to download my repo to each server. However, I do not know where the repo gets downloaded. I have to curl other files and add them to the repo folder for the build to work.
Does anyone know where repos are downloaded on each server (Windows, Linux, and MacOS) with actions/commit#v3 #actions/checkout#v3? I'm having trouble finding anything in the documentation. If the path is set in an environment variable, I would prefer to use that instead of hard coding the path for each server.
The environment variable you're looking for is GITHUB_WORKSPACE.
The default working directory on the runner for steps, and the default location of your repository when using the checkout action. For example, /home/runner/work/my-repo-name/my-repo-name.
Source: https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables
I am working on MySQL optimization with another researcher and we are using git for version control. The problem is that each of us has to compile those sources on separate machines and running cmake . generates different versions of makefile on our machine. If we think about the following cases
1. A changes source
2. A runs cmake, builds the source, and test performance
3. B pulls the code change
4. B changes source, runs cmake and builds the source
After the step 4, B will have a different version of Makefile and files such as cmake_install.cmake that depend on users and user paths.
For example, some of the files have the following diffs.
# The program to use to edit the cache.
-CMAKE_EDIT_COMMAND = /usr/local/bin/ccmake
+CMAKE_EDIT_COMMAND = /usr/bin/ccmake
# The top-level source directory on which CMake was run.
-CMAKE_SOURCE_DIR = /home/dcslab/userA/mysql/mysql-5.6.21-original
+CMAKE_SOURCE_DIR = /home/dcslab/userB/mysql-5.6.21-original
# The top-level build directory on which CMake was run.
-CMAKE_BINARY_DIR = /home/dcslab/userA/mysql/mysql-5.6.21-original
+CMAKE_BINARY_DIR = /home/dcslab/userB/mysql-5.6.21-original
These are all user-dependent paths generated by cmake commands. The direct way to resolve this conflict is to untrack Makefiles or any file generated by cmake after initially committing them. I am wondering if there is any better and legit way of managing projects using cmake for more than one user. Thanks for your help in advance!
Files generated by CMake are machine-dependent, so they will not work on any machine except one where they has been generated. Because of that, they are useless on for others and there is no needs to track them in git. There are two ways for achive this:
Tune gitignore for ignore files, generated by CMake, on commit. Patterns for such files are relatively simple and can be found by googling. Disadvantage of this approach is that files, generated by project's CMake scripts (configure_file, add_custom_command) will not be automatically ignored and will require explicit notion in gitignore
Perform out-of-source builds, that is not run cmake from source directory. CMake generates additional files only in build directory, correct project's CMake scripts also should follow this rule. So git repo will be clean without any gitignore patterns.
It is common practice to perform out-of-source build in ./build subdirectory of source directory. In this case you can add /build/** to gitignore, and everything will work.
An important part of good engineering -- and especially in research -- is reproducability. It is unfortunate that the code you are working on can be influenced by the environment in which it is built (you may want to look at the Bazel for future projects to reduce external dependencies). Given that this code already has this external dependency problem, you can at least counter the effects by using a consistent environment via virtualization. In particular, you may want to take a look at Docker, which would allow you and your collaborators to build/run code using a common system image, thereby ensuring that all builds and executions are derived from a predictable, consistent environment.
Codeception: Configuration file(s) placed in tests/_envs are not working. I am trying to run my acceptance tests in multiple environments (ex. dev, qa, staging, prod). So I have setup dev.yml, qa.yml, staging.yml and prod.yml files under tests/_env directory. Each of those separate environment I am overriding the WebDriver - url.
file - dev.yml
modules:
config:
WebDriver:
url: 'dev.mysite.local'
Then when I try to run the acceptance test suite using one of the environment, ex
./vendor/bin/codecept run acceptance --env dev
It doesn’t pull in the dev configuration, but instead uses the default configuration from acceptance.suite.yml file. What am I doing wrong?
There is a bug in the codeception/configuration.php file where a wrong regular expression has been used, which prevents .yml file from being loaded. However, dist.yml files loads just fine. They have already pushed a change for this bug.
In case you don't have this changeset, you can manually change it on your codeception/configuration.php file or simply use the dist.yml extension.
Wrong regex:
$envFiles = Finder::create()
->files()
->name('*{.dist}.yml')
->in($path)
->depth('< 1');
Correction:
$envFiles = Finder::create()
->files()
->name('*.yml')
->in($path)
->depth('< 1');
Thanks to sjableka for the answer posted on the Codeception repo.
Hi I am new to open shift . I don't know how to create repository and deploying our project to it. I have configured it through command prompt. After installing rhc successfully through command prompt I am getting confusion of help given on Open Shift site regarding uploading the application not about pushing and commiting. I got the idea about commiting and pushing but I did not get the idea about deploying or uploading the application first time . Please help me I am getting stuck for a lot of time thanks in advance
Deploying and Building Application
All OpenShift applications are built around a Git source control workflow - you code locally, then push your changes to the server. The server then runs a number of hooks to build and configure your application, and finally restarts your application. Optionally, applications can elect to be built using Jenkins, or run using "hot deployment" which speeds up the deployment of code to OpenShift.
Making Changes to your Application
As a developer on OpenShift, you make code changes on your local machine, check those changes in locally, and then "push" those changes to OpenShift. One of the primary advantages of Git is that it does not require a continuous online presence in order to run. You can easily check in (in Git terminology, 'commit') and revert changes locally before deciding to upload those changes to OpenShift.
Every OpenShift application you create has its own Git repository that only you can access. If you create your application from the command line, rhc will automatically download a copy of that repository (Git calls this 'cloning') to your local system. If you create an application from the web console, you'll need to tell Git to clone the repository. Find the Git URL from the application page, and then run:
$ git clone <git_url> <directory to create>
Once you make changes, you'll need to 'add' and 'commit' those changes - 'add' tells Git that a file or set of files will become part of a larger check in, and 'commit' completes the check in. Git requires that each commit have a message to describe it.
$ git add .
$ git commit -m "A checkin to my application"
Finally, you're ready to send your changes to your application - you'll 'push' these changes with:
$ git push
The output of the push command will contain information from OpenShift about your deployment -
Source Click me
There are two options for deploying content to the Tomcat Server within OpenShift. Both options
can be used together (i.e. build one archive from source and others pre-built)
1) (Preferred) You can upload your content in a Maven src structure as is this sample project and on
git push have the application built and deployed. For this to work you'll need your pom.xml at the
root of your repository and a maven-war-plugin like in this sample to move the output from the build
to the webapps directory. By default the warName is ROOT within pom.xml. This will cause the
webapp contents to be rendered at http://app_name-namespace.rhcloud.com/. If you change the warName in
pom.xml to app_name, your base url would then become http://app_name-namespace.rhcloud.com/app_name.
Note: If you are building locally you'll also want to add any output wars under webapps
from the build to your .gitignore file.
Note: If you are running scaled EWS2.0 then you need an application deployed to the root context (i.e.
http://app_name-namespace.rhcloud.com/) for the HAProxy load-balancer to recognize that the EWS2.0 instance
is active.
or
2) You can git push pre-built wars into webapps/. To do this
with the default repo you'll want to first run 'git rm -r src/ pom.xml' from the root of your repo.
Basic workflows for deploying pre-built content (each operation will require associated git add/commit/push operations to take effect):
A) Add new zipped content and deploy it:
cp target/example.war webapps/
B) Undeploy currently deployed content:
git rm webapps/example.war
C) Replace currently deployed zipped content with a new version and deploy it:
cp target/example.war webapps/
Note: You can get the information in the uri above from running 'rhc domain show'
If you have already committed large files to your git repo, you rewrite or reset the history of those files in git
to an earlier point in time and then 'git push --force' to apply those changes on the remote OpenShift server. A
git gc on the remote OpenShift repo can be forced with (Note: tidy also does other cleanup including clearing log
files and tmp dirs):
rhc app tidy -a appname
Whether you choose option 1) or 2) the end result will be the application
deployed into the webapps directory. The webapps directory in the
Tomcat distribution is the location end users can place
their deployment content (e.g. war, ear, jar, sar files) to have it
automatically deployed into the server runtime.
Here is really good tutorial prepared by openshift guys with source code so you can go wrong with it.
https://www.openshift.com/blogs/spring-polyglot-persistence-part-1
To sum up - if you have your application on some repository just create your application so it creates folder with git repo in your directory
rhc app create notebook jbossas-7 -l <openshift_login_email> -d
Go to newly created directory and replace default openshift code with your repo
git rm -rf src/ pom.xml
git commit -am "removed default files"
git remote add notebook -m master git://github.com/shekhargulati/notebook-part1.git
git pull -s recursive -X theirs notebook master
git push
You should see your java application build.
What application type is your app? Java/PHP/Python...? If it is a PHP based app, then externally exposed PHP code should go into "php" directory. Whenever you create an application using the rhc commands, a local repository is created, inside which you will find a README document, which lists your deployment steps. Additionally, you can refer to OpenShift user guide here:
https://www.openshift.com/sites/default/files/documents/OpenShift-2.0-User_Guide-en-US_5.pdf
I am new to Jenkins/Hudson and am trying to migrate a C make-based project from buildbot. For legacy reasons, the build system is hard-coded to build outside of the versioned source tree (git), one directory above, in a separate directory. E.g.:
workspace
.git
foo
bar
build
artifacts
Besides the fact that it ends up creating a directory outside the workspace, Jenkins won't recognize items in the build/ directory above to archive as artifacts.
How can I make this kind of build system work with Hudson? Building in-source-tree is not a short-term option. The only option I found was "use custom workspace," but all this does it hard-code the workspace directory to some other directory.
To answer my own question: there is indeed an option in Jenkins git plugin to check out to a local subdirectory instead of the root of the workspace. With the git plugin, click on the Advanced button and fill in the field "Local subdirectory for repo (optional)".
I don't find the option that djs mentioned, but you can specify a different work directory:
Configure job
Extended Project settings
Use custom work space
This can be set to everywhere you want, also the workspace of a different job.