fumeapp / fume-cli Goto Github PK

general clean up functionality for when this happens during a deployment

• swap the config back to normal
• remove any temporary folders made

• make sure to recommend auth:login before config/etc

don't just look for ^

build a micro-service that does the following

• invoke via an endpoint with environment and deploy id info
• get STS credentials through an endpoint
• work in unique directory to not intrude on other tasks
• run docker-build with title involving project name and environment fume-project-env:latest
• get docker login via ecr command aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin {ACCOUNT_ID}.dkr.ecr.us-east-1.amazonaws.com
• tag and push image with docker tag {env-name}:latest {account_id}.dkr.ecr.us-east-1.amazonaws.com and then `docker push {account-id}.dkr.ecr.us-east-1.amazonawes.com/{env-name}:latest

this microservice needs the following dependencies

• exclusive handshake access to the API with verifiable middleware
• docker installed
• ability to set new types of statuses to help report back

Because I'm extremely brain dead at times, I can find it easy to make an environment variable change in fume.app but then fail to sync with AWS. It would be helpful to me if upon change to env-vars, the sync variables button changes color or something, so as to remind me to click sync

❯ GOOS=linux GOARCH=arm64 go build -tags lambda.norpc -o bootstrap main.go
❯ zip myFunction.zip bootstrap
  adding: bootstrap (deflated 46%)
❯ aws lambda create-function --function-name myFunction \
--runtime provided.al2 --handler bootstrap \
--architectures arm64 \
--role arn:aws:iam::313370:role/whataburger-lambda \
--zip-file fileb://myFunction.zip
❯

These build args will produce arm64 binaries, will run faster, and will leverage the updated and AWS preferred runtime for golang. The billing model changes slightly - the current runtime does not get billed for invocation time, whereas the new runtime will, but it AWS claims it is not really much of a difference since it is so much faster now.

I am unable to deploy to any of my environments . I've left the deployment running for an hour and below is what I see:

Fume CLI:

✔ Deps: 314.8MB Code: 7.9MB Assets: 879.7KB Total: 323.5MB Mode: efs
⠼ Sync dependencies
  › 100.00% complete

Fume web app:

Allow a user to specify a longer timeout for file uploads/etc

• add a request endpoint that results in a unique id for the CLI
• pass that as the url to prompt and/or open instead of the previous
• test the token upon retrieval and continue

• [] make it re-usable code in the status class

• run node_modules/.bin/nuxt generate to generated the production assets in .nuxt/
• zip up .nuxt/ into something like deployment-{environment}.zip
• using the js aws-sdk, upload the archive to an s3 bucket
• communicate with the fume api to deploy the s3 object

maybe ignore node_modules/fume-cli/

I am unable to delete a project (in order to create it again in an attempt to fix the hanging sync dependencies issue I've also reported). The web app DELETE request to your API fails with a 504 status.

• properly show the url needed to go to
• duplicate when cli.open doesnt work and fallback with another solution

• [] trigger when no environment given
• [] still error when the wrong environment is given

fume login aliases to fume auth:login

I think this would be a great feature to add to Fume. I've tested with a fresh create-nuxt-app project and after ~15 minutes of idle, the site takes 15-20s to respond which for most apps/ecommerce/blogs etc is slow enough to lose visitors.

I believe warming is relatively simple with the serverless framework and is a common practise. Is it something you'd consider adding to Fume as a toggle on a per-project basis?

this is in situations where a nuxt project is in a sub-directory

I have lambdas that are just complicated enough to want warrant multiple go source files in order to keep me sane. Unfortunately, deploytasks just wants one source file. This is all fine and good and I can deal with it, but the problem occurs when I need to debug something: since i cannot have multiple files, i end up importing my code from another module and using in main.go... in debugging, this may result in my having to update the module and then the lambda's go.mod... so that's 2 commits (one for module one for lambda) and 3 pushes (1 for module, 1 for lambda main, 1 for lambda production). It would help to be able to gather all the go sources in the directory and include them in the build line:

./src/lib/deploytasks.ts:273:    await execa('go', ['build', '-o', 'main', 'main.go'], { env: { GOOS: 'linux', GOARCH: 'amd64' } })

I can do this, likely, but I do not know js/typescript so I cannot whip out a change real quick. I'm guessing one can just use glob or another something from fs. Since it's probably something I should just learn and know for future, I will look to add this and submit a PR, but wanted to make issue first in case I should not.

100s of lines showing compression is not acceptable for CI/CD logs

• get the compression status to a percentage value .. not MB
• only reflect compression status so many x frames, maybe every 10%
• harness the newer updated info in the CLI where the total folder bytes is stored

• machine it did not work on was big sur

I've tried to deploy using Bitbucket Pipelines but when I run the fume deploy stating command it shows me an error

::fume:cli:: v0.2.6
[STARTED] Verify authentication
[STARTED] Initialize environment
[TITLE] Initialized for production environment
[SUCCESS] Initialized for production environment
[STARTED] Test Credentials
[TITLE] Authenticated as [email protected] from FUME_TOKEN
[TITLE] Authenticated as [email protected]
[SUCCESS] Authenticated as [email protected] from FUME_TOKEN
[SUCCESS] Authenticated as [email protected]
[STARTED] Verify fume configuration
[SUCCESS] Verify fume configuration
[STARTED] Initialize deployment
[FAILED] Error: This project has no commits, please add one before deploying

Anyone knows how can I avoid this?

by default not everyone has a static folder, if this is v3 we should look for public/ instead anyways

Try this out https://github.com/rvagg/node-du

Would be great if I got warning if my local CLI version was not up-to-date.

For example if I am on fume:cli:: v0.2.0 would be good to see when I run something like
fume deploy stage

I get console output somewhere that a version fume:cli:: v0.2.4 is available.

When I create a variable, the request succeeds but it isn't added to the table. Submitting again gives the error because it already exists. After refreshing, the variable appears. There are no console errors.

I'm sure this was working previously 🤔