I am trying to build a Continuous Deployment workflow via GitHub
Actions.
As a background context, this is a Clojure/ClojureScript project -
specifically, a dependency on a dynamic web app.
As the outcome of the CD workflow, I want to have Maven packages
published on GitHub packages after every time the file project.clj
is changed.
Why this file? Because it holds the project version! Usually, when
someone edit this file it is because it is a new version. Hence, it
makes sense for a new version to be automatically published as a
dependency.
Ok. I have achieved something close to what I want. Packages have
been automatically published!
However, they are being published even when someone JUST submits a Pull Request.
I want the package to be published (CD to be triggered) on the
following conditions:
1 - after direct changes on main branch; or,
2 - after a Pull Request is MERGED.
I do not want a package to be published if the Pull Request is
only submitted.
This is my cd.yml file:
name: 'cd'
on:
workflow_dispatch:
push:
branches:
- main
paths:
- 'project.clj'
pull_request:
paths:
- 'project.clj'
What do I need to change on the workflow dispatch?
Only removing the last 3 lines will do the trick?
As hinted by my own questions and endorsed by user #tmt, removing the last 3 lines worked out as expected:
name: 'cd'
on:
workflow_dispatch:
push:
branches:
- main
paths:
- 'project.clj'
Related
I am working Azure DevOps Pipeline to build and deploy React JS application. It contains config.js file which some variables that needs to modified for different environments. Anyone help me how to handle the config.js in Release pipeline while deploying to different stages?
I marked this question as duplicate because I think there is already a suitable answer. Nevertheless, I remembered two other approaches for achieving what you are looking for:
1. Storing your variables in .env files
You can easily store your variables in .env files like described here. You then need to give each .env file a different name for each environment. You could end up having a .env.developemt, a .env.production, ... and so on in your repository. Then you can use the following YAML for building according to your desired environments:
# Node.js with React
# Build a Node.js project that uses React.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/javascript
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool#0
inputs:
versionSpec: '10.x'
displayName: 'Install Node.js'
- script: |
npm install
npm run build:staging
displayName: 'npm install and build'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: 'build'
ArtifactName: 'drop'
publishLocation: 'Container'
For each build pipeline, you then use a adjusted YAML. In the shown YAML, you can add custom triggers and stuff. And of course, you need to change the staging to the environment name that you want to build. In that concrete example, if you have a .env.development and a .env.production, you will end up with two YAMLs, one where the staging is replaced by production and one where the staging is replaced by development.
2. Store your variables in JSON files
You could store you variables in JSON files and then use the JavaScript files (which previously stored your variables) to load the data out of those JSON files. Here is how this can be done in detail:
Create a file JSON file which contains all the variables you need to change depending on the environment, e.g. config.json with the following content:
{
"key1":"",
"key2":"",
"key3":""
}
Now you can use the File Transform Task of Microsoft in you Release Pipeline to modify this JSON file. The task will take the variables defined in the pipeline (as described here) and will overwrite any value in the JSON file which has a matching key. For example, you define key2 = "foo" in your pipeline. The File Transform Task will produce this JSON:
{
"key1":"",
"key2":"foo",
"key3":""
}
Last but not least, you need to get the variables defined in your JSON file into your react app. Therefore, you can simply load the config.json into your JavaScript file (which contained those variables before) with the following command:
export const config = "./config.json";
I hope this helps. If anything is unclear, just leave a comment and I can try to explain it :)
I am having an Android app that I developed in July 2019 using Eclipse (at least that is what the folder says).
Now I want to make some changes and tried to import and run the project with Eclipse.
But when trying to run the project, I get the following error messages:
These values are required!
userName - login information from codenameone.com
password - the password matching your login from codenameone.com
jarFile - the application jar file resulting from the build
ApplicationDisplayName - display name for the application in the UI
MainClassName - the name of the main class not including the package name
ApplicationPackageName - the package in which the main class resides, this will also be used to classify the application. It is recommended you give this some thought since package names are impossible to change later on some stores!
version - the version number for the application
There is some other strange behaviour, like the error:
The method getAllStyles() is undefined for the type Form
and no Simulator_Project.launch file ...
I have tried refreshing the libraries, but to no avail. Maybe there have changes been made to the build process ...
How can I run the project?
I use exq and exq_ui for background job processing and monitoring in my Phoenix application.
At first, I refer to exq_ui in mix.exs's deps like this:
{:exq_ui, "~> 0.11.0", only: [:dev, :qa, :stg, :prod]}
And it works fine.
But then I discover 2 bugs in the UI:
When I click on the tab Busy, it blows up on the server side, and shows nothing in the tab Busy in UI.
In the tab Scheduled, when a job is passed args as a list of map, it is showed as [Object object] in the column Args, instead of the real content of the args.
I fix those bugs here in this PR to the main official repo:
https://github.com/akira/exq_ui/pull/89/files
But I cannot expect it will be merged anytime soon, so I change my dependency in mix.exs like this:
{:exq_ui, "~> 0.11.0",
git: "https://github.com/chauhonglinh/exq_ui.git",
branch: "feature/fix_busy_tab_in_exq_ui",
only: [:dev, :qa, :stg, :prod]}
Now the trouble happens.
The mix deps.get, mix deps.compile and iex -S mix phx.server all run successfully.
But then when I browse to http://localhost:4040, the UI doesn't show up, and in the javascript console, there are errors:
Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://localhost:4040/assets/vendor.css".
exq_ui:20
Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://localhost:4040/assets/exqui.css".
vendor.js:1 Uncaught SyntaxError: Unexpected token <
exqui.js:1 Uncaught SyntaxError: Unexpected token <
Question: Why did this error not happen with ordinary deps config, but it happened with deps config referred to a git repo?
How can I fix it?
I think React and Angular also have similar errors in certain situations, but it seems that nobody has a good fix for them, just some anecdotes here and there.
I figured out what the problem was. But I don't see any good solution for it yet if my PR is not merged (short of copying the whole exq_ui package and create a new one)
Here is the problem.
Referring to package like this points to binary distribution on hex.pm, hence it has all the emberjs and js modules prepackaged and babelified correctly:
{:exq_ui, "~> 0.11.0", only: [:dev, :qa, :stg, :prod]}
However, the referring to package in github points to source from github, so it has only source:
{:exq_ui, "~> 0.11.0",
git: "https://github.com/chauhonglinh/exq_ui.git",
branch: "feature/fix_busy_tab_in_exq_ui",
only: [:dev, :qa, :stg, :prod]}
Solution for dev environment:
In order for it to work in dev environment, from within my Phoenix repo, I need to run the following commands:
cd deps/exq_ui/priv/ember
npm install
bower install
node_modules/ember-cli/bin/ember build --environment=production
Then the web UI at http://localhost:4040 will work properly.
Remaining Question: When I refer to exq_ui from a git repo, I still don't see how I can make a binary distributed version for exq_ui when I want to release my Phoenix app.
I'm currently following the Vespa tutorials, and ran into an issue with the HTTP API use-case. Everything works fine from the mvn install package to the vespa-deploy prepare target/application.zip.
The call to vespa-deploy activate returns normally, but the application then never gets available on localhost:8080. Looking at /opt/vespa/logs/vespa/vespa.log (in the VM) one finds the following stack trace:
Container.com.yahoo.jdisc.core.StandaloneMain error Unexpected:
exception=
java.lang.IllegalArgumentException: Could not create a component with id 'com.mydomain.demo.DemoComponent'.
Tried to load class directly, since no bundle was found for spec: sample-app-http-api-searcher.
If a bundle with the same name is installed, there is a either a version mismatch or the installed bundle's version contains a qualifier string.
at com.yahoo.osgi.OsgiImpl.resolveFromClassPath(OsgiImpl.java:48)
...
This occurred using a fresh Docker image with a clean clone of the sample-apps git repository. Preparing and activating the basic sample as well as the other http example did work seamlessly.
I checked the sources and the xml files for obvious problems but don't have any clue about what is failing and where.
target/application.zip contains
application/components/http-api-using-searcher-1.0.1-deploy.jar
application/hosts.xml
application/searchdefinitions/basic.sd
application/services.xml
And the jar itself does contain a com/mydomain/demo/DemoComponent.class file (among other things).
Potentially related issue on the github tracker: https://github.com/vespa-engine/vespa/issues/3479 I'll be posting a link to this question there as well, but I still think it's worth a SO question, at least to get some action behind the vespa tag :)
The bundle id in the application's services.xml file was wrong. Please pull the application from git and try again now. See also PR: https://github.com/vespa-engine/sample-apps/pull/18
Brief explanation: The bundle id given in the bundle="<id>" declaration in services.xml must match the 'Bundle-SymbolicName' in the bundle's manifest. When the bundle has been built with the Vespa bundle-plugin, the symbolic name is by default the same as the project's artifactId. Hence, in most cases you just have to verify that the bundle id matches the artifactId.
there is an idea to implement 'protractor core' which will be used by multiple projects for UI testing. At this moment I have an angular project 'project1' with e2e tests (cucumber-protractor-typescript) which are covering 'project1'. In future I expect 'project 2', 'project 3' ... which is also required UI testing. So I would like to have a separate project let's say 'protractor core' which could be used by any project for develop UI tests. The stucture should be smth like this:
project 1 >>> (has dependency to 'protractor core')
features
step_definitions > (access to api, smth common)
project 2 >>> (has dependency to 'protractor core')
features
step_definitions > (access to api, smth common)
project 3 >>> (has dependency to 'protractor core')
features
step_definitions > (access to api, smth common)
Really appreciate any examples, ideas, suggestions !
For a start, understand Protractor is not project related.
The config file you use to execute your tests will run every file you gave him. In your case, it could be from multiple project folder.
If you already have a config file for each project, create a new one at the top of every project, and give him all project.
One of the possibility is to use the option "suite"
Here a partial example of your config file (eg protractor.conf.js) could look like with this option
exports.config = {
suites: {
project1: ['Project1/tests/e2e/**/*.js'],
project2: ['Project2/tests/e2e/**/*.js'],
project3: ['Project3/tests/e2e/**/*.js']
},
// more option
Your config file needed to be on top the folder. If not, change path according to your structured folder you want. (again protractor is not project related, it's file related)
And you run your test like this:
protractor protractor.conf.js --suite project1
# depending on other option you have put in your config file
It's another subject. I don't talk about version control, but you will have to think about that for maintainability.
I'm actually working on something very similar right now. I think my situation is very similar to yours.
What I started noticing is that we have duplicate page objects and helper classes/functions across multiple projects. What we're doing is building an npm package for our protractor framework(page objects, helper classes, etc.) and placing it on our ProGet server. That way every team has access to the same framework and they can just pull it down into their projects just like you would any other npm package. Each project will have it's own config and tests but the framework can be shared across multiple projects and helps prevent duplicate resources across multiple repos.