I have a lambda layer set up, and a shell file that deploys it. I have written github workflows that triggers this shell file whenever there's a change in code in that particular repository. Since a newer version is published, I would like to change the lambda-layer-version to change in zappa-settings.json. Is there a way to automate this, or will I have to manually do it everytime?
Here's my zappa-settings.json file:
{
"dev": {
"app_function": "app.app",
"profile_name": "zappa-dev",
"project_name": "zappa-app",
"runtime": "python3.8",
"s3_bucket": "zappa-app-dev",
"aws_region": "ap-south-1",
"slim_handler": true,
"layers": ["arn:aws:lambda:ap-south-1:594519763223:layer:testapp-lambda-layer:2"]
}
}
Over here, I would like to change '2' to the latest version. I have tried using $LATEST, but it throws regex error.
It seems zappa code in https://github.com/zappa/Zappa passes this value directly to boto3 client's create_function method. So the issue is with specifying latest layer version in AWS itself.
It can be manually updated by fetching list of versions and selecting the first result, like here:
https://stackoverflow.com/a/55752188/3014044
Related
In Compose Desktop projects, how can we manage secret keys without committing?
In Android projects, Gradle has the buildConfigField() and resValue() functions. They will generate a BuildConfig.java during compile time, and we can use the values during runtime.
For example, in an Android project, first, we create two environment variables — RELEASE_API_KEY and STAGING_API_KEY (It can be either local computer, or a CI/CD environment).
Then in build.gradle file we can say:
android {
buildTypes {
release {
buildConfigField("String", "API_KEY", "\"${System.getenv('RELEASE_API_KEY')}\"")
}
staging {
buildConfigField("String", "API_KEY", "\"{System.getenv('STAGING_API_KEY')}\"")
}
}
}
..and in the Kotlin code we can use:
val apiManager = ApiManager( BuildConfig.API_KEY )
Is there a similar approach in Compose Desktop projects so that:
I don't have to commit the secret to the source repository?
I can easily configure secrets in a CI/CD environment?
So there are some Gradle plugins that were built to solve just a problem like this - inject build time constants into our runtime code. Here is the one that came up in a Google search:
https://github.com/gmazzo/gradle-buildconfig-plugin
And here is the one that came up when I swapped the c in config for a k (you know these Kotlin devs can't resist it right?)
https://github.com/yshrsmz/BuildKonfig
Of course - if you don't want to mess around with gradle plugins like this, the easy solution is to just create a file with your dev code where the same constants are nulled out or are empty strings, or reference an ignored file to get the value, and then just overwrite the file in CI using bash, replacing all the constants with what you want. This approach is very useful when you don't have access to gradle, like in a js project:
#!/usr/bin/env bash
AWS_FILE=<your aws credentials file here>
if [ -f "$AWS_FILE" ]; then
echo "Injecting the AWS Credentials"
echo "export const AWS_CREDENTIALS = {
clientId: \"$AWS_CLIENT_ID\",
secret: \"$AWS_CLIENT_SECRET\"}" > $AWS_FILE
else
echo "$AWS_FILE doesn't exist."
exit 1
fi
I am developing a quick ASP.Net Core 3.1 app, and trying to push it to a Free Linux-hosted WebApp in Azure.
The app builds, runs locally, and deploys to a docker environment in Windows Azure. All the files are deployed as expected.
The challenge is this:
Upon starting the app using the command
dotnet <mywebproject>.dll
The log tells me this:
The framework 'Microsoft.WindowsDesktop.App', version '3.1.0' was not found.
First thing to check was to see if there was a missing runtime
root#4182491:~/site/wwwroot# dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.0 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
After some fondling, I see that there is a file named .runtimeconfig.json:
{
"runtimeOptions": {
"tfm": "netcoreapp3.1",
"frameworks": [
{
"name": "Microsoft.WindowsDesktop.App",
"version": "3.1.0"
},
{
"name": "Microsoft.AspNetCore.App",
"version": "3.1.0"
}
],
"configProperties": {
"System.GC.Server": true
}
}
}
So the runtime I need is there, but dotnet does not want to select it!
From the error, I am assuming that dotnet is attempting to start the website using the first framework that it can see, however how do I get rid of it during build? I've looked up how these files get generated during build, and can see no options to prevent a framework from being put into the runtimeOptions file.
Since I am building the app using Azure DevOps, I can't simply edit the file manually and upload it to the hosted linux container that it runs in.
So I need help with either:
How to build the project and EXCLUDE "Microsoft.WindowsDesktop.App" from the list of frameworks being generated
How to START the application in the linux container with a specific target framework NAME (I can only choose version from the settings I see in dotnet exec using SSL to the container.
This is more or less driving me nuts!
I am going to answer this one myself, since I found the solution after way too much coffee:
Turns out that the options you see here:
{
"runtimeOptions": {
"tfm": "netcoreapp3.1",
"frameworks": [
{
"name": "Microsoft.WindowsDesktop.App",
"version": "3.1.0"
},
{
"name": "Microsoft.AspNetCore.App",
"version": "3.1.0"
}
],
"configProperties": {
"System.GC.Server": true
}
}
}
Aren't options at all, but requirements. I found a dependency on a package designed for WPF that of course requires the Microsoft.WindowsDesktop.App runtime to be installed. Since I'm developing on a windows computer, the code had all the necessary runtimes to run in debug, but not on linux.
I'll close this for now, but since the naming led to confusion, I will leave the question up in case someone else runs into the same confusion that I did.
I am following this tutorial
https://hyperledger.github.io/composer/integrating/deploying-the-rest-server.html
I have done all the steps. But when I run rest-server through github, it prints following stack trace.
Error
404 Cannot GET /auth/github
status: 404
Error: Cannot GET /auth/github
at raiseUrlNotFoundError (/home/praval/.nvm/versions/node/v6.11.1/lib/node_modules/composer-rest-server/node_modules/loopback/server/middleware/url-not-found.js:21:17)
I presume you installed the Github strategy via npm install -g passport-github?
If so did it create a folder /auth/github?
You are required to go to this Folder per documentation: "Authenticate to the REST server by navigating to the value of the authPath property specified in the environment variable COMPOSER_PROVIDERS. In the example above, this is http://localhost:3000/auth/github"
In my case that folder was not created. I read on Github website: https://github.com/cfsghost/passport-github
"The author of Passport-Github has not maintained the original module for a long time. Features in his module don't work since Github upgraded their API to version 3.0. We forked it and re-published it to NPM with a new name passport-github2"
I'm looking for guidance on this.
Before create private api just execute this command in your terminal.
export COMPOSER_PROVIDERS='{
"github": {
"provider": "github",
"module": "passport-github",
"clientID": "<your id>",
"clientSecret": "<your secret>",
"authPath": "/auth/github",
"callbackURL": "/auth/github/callback",
"successRedirect": "http://localhost(domain of angular app):4200(port)/home(page to redirect)",
"failureRedirect": "http://localhost(domain of angular app):4200(port)/login-github(page to redirect)""
}
}'
To check if all is fine - run command
echo $COMPOSER_PROVIDERS
After this you will see your COMPOSER_PROVIDERS value.
And after in github profile app (https://github.com/settings/applications/) you must configure "Homepage URL" (ex. http://APIdomain:3000/) and "Authorization callback URL" (ex. http://APIdomain:3000/auth/github/callback)
I am trying to configure my machine to deploy Parse Cloud Code. This requires downloading and running ParseDeploy.exe, followed by parse new.
I am running Win 8.1, and using the latest parse-windows-2.0.7.exe.
The folder structure is correctly created.
After entering my email & password, I am meant to see a list of my apps. Instead I am seeing:
1: results
Select an App:
"results" is not the name of any of my 3 apps.
This is what the PowerShell output looks like:
PS E:\...\demo> parse new
Creating a new project in directory E:\...\demo\parse
Creating directory E:\...\demo\parse\config
Creating config file E:\...\demo\parse\config\global.js
on
Creating directory E:\...\demo\parse\cloud
Writing out sample file E:\...\demo\parse\cloud\main.js
Creating directory E:\...\demo\parse\public
Writing out sample file E:\...\demo\parse\public\index.
html
Email: richard#glowworm.mobi
Password:
1: results
Select an App:
Related post:
Parse: No list of apps from Parse in CTL windows 7
I have used this successfully on previous projects. What has changed?
Some very old versions of the Parse command line utility may run into this issue due to some backend changes. You can get around this issue by making sure you're running the latest version of the command line utility, available at https://parse.com/docs/downloads
I also recommend joining the Parse developer mailing list, where we made an announcement a couple of weeks ago recommending that people make sure they update their command line utility prior to the backend change going into effect: https://groups.google.com/forum/#!topic/parse-developers/WoRnDft4qmE
Update
v2.1.3 fixes this issue, and works correctly on my machine.
What has changed? Parse has made updates, requiring a new version of parse.exe to be downloaded.
Unfortunately the initial new versions do not work.
Workaround
I have rolled back to using v1.4.2 of parse.exe.
It is currently working for deploying projects.
However, it breaks when creating a new project with parse new (as per my question).
The file that breaks is .\config\global.json - it seems to be in a new format, and it tries to reference this non-existent "results" project.
What I have done is to an existing global.json file from an older project, and manually edit it to update the values for my new project. Here is an example:
{
"global": {
"parseVersion": "1.4.2"
},
"applications": {
"<< AppName >>": {
"applicationId": "<< app id >>",
"masterKey": "<< master key >>"
},
"_default": {
"link": "<< AppName >>"
}
}
}
Just update the following fields:
<< AppName >>
<< app id >>
<< master key >>
(works as of 2 June 2015)
Bug Reported
A bug has been opened related to this issue on Facebook Developers:
https://developers.facebook.com/bugs/971635999542789/
The following versions are not running on my machine:
v2.0.7
v2.0.8
v2.0.9
There are other reports on the support forum that these versions are broken for other people as well.
I know the slug compiler removes the .git directory when creating a heroku slug, but is there any way to configure Heroku so that I can access the currently running git commit number from within my scripts?
I'd like to be able to have a small link on my sinatra app (run within Heroku) which says "running version e72fb274a0" (or something similar). How can I retrieve this, or force the slug compiler to add it to an environment variable?
PROGRESS:
I reckon the best way to do this is to make a custom buildpack which writes the git commit version number to the heroku slug before the .git directory is deleted.
I've tried to do this (see my fork of the ruby buildpack) but the line I've added – line 23 – doesn't seem to be doing the job. Heroku sees & uses the new buildpack, but doesn't seem to write the file to the slug.
Anyone have any idea why my custom buildpack isn't working as expected?
Thanks,
JP
A couple of options...
SOURCE_VERSION environment variable (build-time)
Since 1st April 2015, there's a SOURCE_VERSION environment variable available to builds running on Heroku. For git-pushed builds, this is the git commit SHA-1 of the source being built:
https://devcenter.heroku.com/changelog-items/630
(thanks to #srtech for pointing that out!)
An example of me using that variable in a build - if you look at the HTML served by the deployed app, you'll see the commit id is coming though in an HTML comment near the very bottom: https://gu-who.herokuapp.com/
/etc/heroku/dyno metadata file (run-time)
Heroku have beta functionality to write out a /etc/heroku/dyno metadata file onto your running dyno. If you email support you can probably get added to the beta. Here's a place where Heroku themselves are using it:
https://github.com/heroku/fix/blob/6c8ab7a/lib/heroku_dyno_metadata.rb
The contents look like this:
{
"dyno":{
"physical_id":"161bfad9-9e83-40b7-b385-78305db2f168",
"size":1,
"name":"run.7145"
},
"app":{
"id":null
},
"release":{
"id":50,
"commit":"2c3a0b24069af49b3de35b8e8c26765c1dba9ff0",
"description":null
}
}
..so release.commit is the field you're after. I used to use this method until the SOURCE_VERSION variable became available.
In 2018 this is what you want:
https://devcenter.heroku.com/articles/dyno-metadata
heroku labs:enable runtime-dyno-metadata -a <app name>
You can run a script before deploy that store this information (maybe on a YAML)
using these a = `ls` (note that is not ' "apostrophe" sign is ` "inverse accute" sign)
the a variable will have the result of this bash command,so you can do
git = `git log`
and then find the information you want it and store it.
So you will be able to retrieve it later.
Did this helped ?