I am quite new to heroku and I want to offer people to easily install my application on their own instance via a "Deploy to heroku" button as described here https://devcenter.heroku.com/articles/heroku-button.
I've now created an app.json on my develop branch: https://github.com/scribble-rs/scribble.rs/blob/develop/app.json
{
"name": "Scribble.rs",
"description": "A multiplayer drawing game for the browser",
"repository": "https://github.com/scribble-rs/scribble.rs",
"keywords": ["game", "multiplayer", "ephemeral"]
}
However, actually testing the button by calling https://dashboard.heroku.com/new?template=https%3A%2F%2Fgithub.com%2Fscribble-rs%2Fscribble.rs%2Ftree%2Fdevelop will result in Heroku running the default build procedure for go-projects. However, due to the fact that the resulting binary doesn't contain the resources necessary for running the application, the app will build, but crash on startup.
In order to fix this, I'd need to instead run it with a docker-buildpack. However, I couldn't really find any documentation on this specific usecase, even though it seemed quite general. For deploying via GitHub using the GitHub-connection on the "Deploy" tab of an app, you can specify a heroku.yml, which I did: https://github.com/scribble-rs/scribble.rs/blob/develop/heroku.yml
build:
docker:
web: Dockerfile
However, in case of the on-click-deploy, this file seems to be ignored and what I am supposed to do instead, is to explicitly specify a buildpack via the app.json. While I've found some GitHub repositories with docker-buildpacks, I kind of dislike this solution, as I'd have to trust some random repository that could either break or vanish any moment.
What exactly is the best way to go about this problem?
It appears you have to specify the stack inside of the app.json. This wasn't very clear by reading the docs: https://devcenter.heroku.com/articles/app-json-schema#stack
I've set this to:
"stack": "container"
Related
Background
I have a makefile which fetches and spins up a Dockerized Mediawiki instance on my local machine, from scratch, with a single make command:
https://gitlab.wikimedia.org/mhurd/mediawiki-docker-make
This works fairly well. Please try it!
Goal
I'd also like to be able to run Mediawiki's Selenium tests (as-is) in Docker containers and watch them execute "live", with the makefile, again, making it easy to kick this process off.
Approach
This work-in-progress branch adds a container for running Mediawiki Selenium tests, and a browserless-chrome container so you can watch and debug the tests "live", as they run:
https://gitlab.wikimedia.org/mhurd/mediawiki-docker-make/-/tree/selenium
As you can see from the top of this branch's readme, after running make to spin everything up, running make runseleniumtests kicks the tests off. When doing so a browser window is automatically opened which lets you see the Selenium tests which are running in the browserless-chrome container. This works... to a point.
Problem
Unfortunately, after a few tests are seen to be running, I'm seeing this error:
Protocol error (Input.dispatchMouseEvent): Target closed.
I suspect the way the browserless-chrome container manages its Chrome sessions may be to blame, as it appears the error is happening when a test causes a new page to be loaded, but I'm not sure.
Any ideas appreciated, and please try it yourself - the whole point of the makefile is to make spinning this up from scratch super simple. It only takes a couple commands and you should be able to see the tests running and the resulting error. Thanks!
Misc
Running curl -s http://127.0.0.1:3000/sessions | python3 -m json.tool on the host machine after attempting to run the tests shows there are multiple browserless-chrome sessions, but I'm unsure how to make it behave more like a non-dockerized setup - which has no problem with tests which cause page loads.
In email communication with Browserless support, they mention seeing similar issues but haven't been able to track down why:
It seems to be that the root cause may be due to "click" events aren't
working properly when your viewing the live debugger. Can you confirm
that if you don't open the live viewer, it allows the test to progress
and eventually throws new errors regarding selectors not being found? (Edit: I did)
I've also run into this live debugger behavior before and in my
experience I stopped watching the live debugger, and since I couldn't
see which selector it wasn't finding I exported a screenshot and in
that particular case, it ended up being an issue with my viewport,
since the viewport in the remote session was smaller, the styles
rendered differently then locally on my machine, when I set the
viewport size, the selectors were found - but then again, that was my
particular issue, might not be yours.
But yes, for some odd reason when you view live sessions, you can run
into this odd issue which we haven't been able to understand.
As it says in the title, this is what im trying to do: using windows 10, codesign my electron app using the certificate purchased from a third party vendor (which is in p12 format).
I've read the docs here: https://www.electron.build/configuration/win and here: https://www.electron.build/code-signing
And realise that I need to provide a path to the certificate file and password (if one is set) using the appropriate keys (certificateFile and certificatePassword).
I've also seen these answers:
How to sign in windows installer using electron builder
(There's also loads of questions and answers referring to people building for windows on mac, but that's not what im doing here)
But this doesnt seem to address the question.
These are how the lines in my package.json are set referring to the relevant path/password:
"certificateFile ": "./certificate_file.p12",
"certificatePassword ": "password"
I realise that it is better to have these set in a .env file and read them from there, which I intend to do later. But as I understand it, this should suffice shouldnt it?
My build command is:
"build": "electron-builder build"
And this produces the following:
But there is no mention of signing taking place at all. If Im being royally stupid, please feel free to point out where ^_^ many thanks in advance!
Updates
Queried with project maintainers on github, code signing is supposed to take place automatically provided the variables are set correctly, see convo here: https://github.com/electron-userland/electron-builder/issues/6895)
It may be significantly simpler to sign your exe OUTSIDE of electron builder. In which case, the approach I took was to use SSL.com's SSL manager GUI.
You can read about it toward the bottom of this page and see their documentation of the tool here.
About a week looking into codesigning with electron builder, still not entirely sure how to do it.
About 5 mins using this tool. Done.
I don't remember the whole process but I had to fumble around for a few days to get it working.
In my package.json file I have a build object like this:
"build":
...
"win": {
"certificateFile": "private/mycertificate.pfx",
"verifyUpdateCodeSignature": true,
"publisherName": [
"My Company Name"
]
},
Then before publishing I run this in windows powershell to set the env variable:
setx CSC_KEY_PASSWORD my-certifcate-password-here
Then finally:
electron-builder -w
I am on an Electron + Create React App stack.
I am using Electron Updater (https://github.com/develar/electron-updater) for auto updates.
Platform: Linux, Format: AppImage.
When my app checks for updates, I get the following error:
APPIMAGE env is not defined.
Has someone experienced the same issue? Suggestions required.
Please don't use electron-updater anymore, since it is no longer supported according to its GitHub page.
Most often, this occurs when you are trying to use the auto updater in development mode (or non-packaged AppImage mode). It only works in a packed production build.
For me however, this also occurred in a packed AppImage, and turned out to be caused by using the webpack DefinePlugin, like this:
plugins: [
new webpack.DefinePlugin({
"process.env": {
NODE_ENV: JSON.stringify("production")
},
...
Removing the process.env definition allowed APPIMAGE to be defined once again in the distributed package. It seems the rest of the definitions can be left in place safely without breaking the auto-updater.
If removing this definition is not possible for your use-case, according to some users it's possible to simply override it at the beginning of your main thread (not renderer thread) file like this:
process.env.APPIMAGE = path.join(__dirname, 'dist', `MyApp-${app.getVersion()}.AppImage`)
... obviously with the correct file name in the 3rd argument of Path.join.
This override approach didn't seem to do anything for me though, so I myself went with simply removing process.env from the DefinePlugin definitions, but it may help in other cases.
try to use electron-builder for building your app cause this module is is in maintainance only mode.
the autoUpdate for linux is not possible, you can do that only for mac and windows try to read this documentation.
I've created my 'first' ASP.NET Core project with Docker support in VS2017.
I build and run and viola, it 'works'. A browser is launched, it loads http://localhost:32787/api/values and returns the expected "value1","value2" response... All is good.
So now I want to start working with this animal to make it do MY will.. get rid of the valuesController and create my own new testController. On run (select the 'docker' start command) it heads for api/values again...and again. (if I change values to test in the url it works as expected. But how do I get it to STOP going to api/values I cannot find any setting that will affect this change.
launchSettings.json is the 'intuitive' place to look. There I find a setting for launchUrl, which I change, first to just api/test (just as it was api/values OOTB) ... no joy, I go ahead and add the rest of the address
so it reads: http://localhost:32787/api/value...
I do a search on the solution and in the file system and can find the word "Values" NOWHERE.
I have found other articles that get into more advanced routes and adding them to the app.UseMvc() command in the Configuration (great, I'm sure I will need to use that soon) but something, somewhere is telling this project to go to http://localhost:32787/api/values and I want to know where that is and how to change it.
Pardon if this is a duplicate but I have tried any number of google searches for things like 'change default url in asp.net core with docker' and get polluted with irrelevant articles that show me many wonderful things that I don't need to know...YET.
If you are using the latest version of VS, and you added Docker support either during, or after the solution was created, all you have to do is right-click on the project named docker-compose, choose Properties, and you can change the information there.
The default Service URL is what you need to focus on. The Launch Browser is set to Yes by default, which has little value in an API project after a short time. Change these to what you think you need. I set my Launch Browser to No, and in case I ever need it, set the Service URL to one that makes sense after doing some development.
I had a hard time finding these myself the first time I went digging.
In case you try to browse with docker and it doesn't land on desired default route, then in your launchSettings.json, just add your desired prefix to launchUrl in the Docker node. For example to make api as your default route when running docker:
"Docker": {
"commandName": "Docker",
"launchBrowser": true,
"launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}/api"
}
I am trying to setup a CI server on my Macbook, I have followed the documentation on the apple website up to the point of creating a bot and integrating my build. When I attempt to integrate the build I repeatedly get the following error:
Bot Issue: error. Build Service Error.
Issue: '/Library/Developer/XcodeServer/Integrations/Caches/14a8ea2a72904f1abcecd38b1c02196b' exists and is not an empty directory (-4).
Integration Number: 13.
Integration URL: https://DavidMcQueens-MacBook-Pro-2.local/xcode/bots/BF817C9/integrations
Description: '/Library/Developer/XcodeServer/Integrations/Caches/14a8ea2a72904f1abcecd38b1c02196b' exists and is not an empty directory (-4).
I have manually deleted the folders in this location, as well as changing the permissions incase the server was having issues writing. Each time I run, I receive the same error. Even after I have deleted the folder so it is empty before the integration.
Does anyone have any ideas on how to solve this issue? I have built my iOS application in Swift (which I believe should still work with the CI server)
I am running OSX Server 4.0 and the latest version of XCode.
I followed Apple's documentation for creating bots
Thanks,
EDIT:
After some experimenting and trying different things to see what the issue is, I disabled 2-factor authentication on my GitHub hosting. This appeared to solve the issue, despite the fact that I was generating a specific application key to get around 2-factor. It solved the issue for a small amount of time, and I managed to successfully get the bot to integrate a few times. However it appears to have gone back to its old tricks.
If anyone has any other knowledge on this, or has managed to get it working on their own machines it will be good to know.
So I believe I have solved this issue, the GitHub 2-factor authentication issue looks to be a red herring.
When setting up the bot, there is a section that says "Checkout the repository", I did not do this step because I already had the repository on my local machine and presumed that it would simply create the repository in another location, and server no other purpose.
However, after some investigation this step is very necessary. From what I understand, checking out the repository does create it again in another location, however this is necessary as this new repository is where the Bot's will pull changes into and build in order to perform the tests. I was trying to use the same repo for development and for the Bots, which it did not like.
Creating a clean checkout of the project (on the server), and configuring the bots in that project then allowed me to progress and get everything setup correctly. It comes down to user error. In hindsight, it makes perfect sense to have a separate repo for the bots (this is my first CI server setup), however the error messages were not helpful and I can't remember seeing this emphasised in the setup guide.