How to upload the Lighthouse CI results as GitHub status checks? - travis-ci

I am trying to set/upload the Lighthouse CI results as GitHub status checks based on this guide.
Based on the guide, I installed and authorized the GitHub app
Lighthouse CI.
Then I set the token I got as LHCI_GITHUB_APP_TOKEN
in the Travis Environment Variables.
This is the part of my .travis.yml.
language: node_js
node_js:
- "12"
branches:
only:
- master
cache: yarn
before_install:
- yarn global add #lhci/cli
install:
- yarn install --frozen-lockfile
jobs:
include:
# other stages...
- stage: lighthouse
script:
- yarn build
- lhci autorun
after_script:
# Set the results as GitHub status checks
- lhci upload
addons:
chrome: stable
lhci autorun succeed runnning.
However, when lhci upload runs, it returns error
Error: Must provide token for LHCI target
at runLHCITarget (/home/travis/.config/yarn/global/node_modules/#lhci/cli/src/upload/upload.js:212:29)
at Object.runCommand (/home/travis/.config/yarn/global/node_modules/#lhci/cli/src/upload/upload.js:323:14)
at run (/home/travis/.config/yarn/global/node_modules/#lhci/cli/src/cli.js:90:23)
at Object.<anonymous> (/home/travis/.config/yarn/global/node_modules/#lhci/cli/src/cli.js:118:1)
at Module._compile (internal/modules/cjs/loader.js:959:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:995:10)
at Module.load (internal/modules/cjs/loader.js:815:32)
at Function.Module._load (internal/modules/cjs/loader.js:727:14)
at Function.Module.runMain (internal/modules/cjs/loader.js:1047:10)
These are my pull request and corresponding Travis error log.
How to set up this token for LHCI target correctly to be able to upload the Lighthouse CI results as GitHub status checks? Thanks
UPDATE:
Based on the error, I traced to here in the source code, I found out that the token that requires is actually the Lighthouse CI server token.
token: {
type: 'string',
description: 'The Lighthouse CI server token for the project, only applies to `lhci` target.',
},
For how to set up t he Lighthouse CI server, please refer to this guide.
So I think lhci upload only applies if you have set up a Lighthouse CI server, which is not for setting the Lighthouse CI results as GitHub status checks.
But still I haven't figured out how to upload the Lighthouse CI results as GitHub status checks.

You need to respect the naming of the variable, per the guide it must be : LIGHTHOUSE_API_KEY not the string you used LHCI_GITHUB_APP_TOKEN
You can see in the source that API_KEY could also work with a warning : https://github.com/GoogleChromeLabs/lighthousebot/blob/289d17fa9732b41035196fdcbd3e470cc2980b77/runlighthouse.js#L24-L30

Thanks the help from Johnny and Patrick on GitHub.
For the GitHub status check we need to link to something so if you're
not setting up the server you can just use temporary-public-storage.
Below is the final version:
# ...
jobs:
include:
# other stages...
- stage: lighthouse
script:
- yarn build
- lhci autorun --upload.target=temporary-public-storage
addons:
chrome: stable

Related

Daily automatic Bitbucket deploy with manual step when pushed to branch

I'm trying to set up a pipeline in Bitbucket with a daily schedule for two branches.
develop : There a scheduled daily deployment running + when I push to this branch the pipeline runs again
master : This is the tricky one. I want to have a daily deployment because the page need to be rebuild daily, but I would like to have a security that if anyone pushes to this branch by mistake or the code is bad, it only runs the deployment after a manual trigger.
So my question is that is it possible to set up a rule to track if there was a push and in this case let the admin manually start the pipeline ?
pipelines:
branches:
develop:
- step:
name: Deploy staging
deployment: staging
caches:
- node
script:
- npm run staging:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN --project $FIREBASE_PROJECT_STAGING --only functions,hosting
artifacts:
- build/**
master:
- step:
name: Deploy to production
deployment: production
caches:
- node
script:
- npm run deploy:auto
- npm install firebase
- npm install firebase-functions
- npm install -g firebase-tools
- firebase deploy --token=$FIREBASE_TOKEN_STAGING --project $FIREBASE_PROJECT_PRODUCTION --only functions,hosting
artifacts:
- build/** ```
I'd suggest to schedule a different custom pipeline other than the one that runs on pushes to the production branch. The same steps definition can be reused with a yaml anchor and you can replace the trigger in one of them.
E.g:
definitions:
# write whatever is meaningful to you,
# just avoid "caches" or "services" or
# anything bitbucket-pipelines could expect
yaml-anchors:
- &deploy-pro-step
name: Deploy production
trigger: manual
deployment: production
script:
- do your thing
pipelines:
custom:
deploy-pro-scheduled:
- step:
<<: *deploy-pro-step
trigger: automatic
branches:
release/production:
- step: *deploy-pro-step
Sorry if I make some yaml mistakes, but this should be the general idea. The branch where the scheduled custom pipeline will run is configured in the web interface when the schedule is set up.

Travis CI Trigger Build option on repo unabled

I'm working on my first Travis CI project. I'm not sure how it works yet.
The thing is when I try to configure trigger builds (Image example), option appears as not allowed, it doesn't let me click it.
And this is my .travis.yml file:
language: node_js
cache:
directories:
- ~/.npm
node_js:
- '12'
git:
depth: 3
script:
- yarn build
deploy:
provider: pages
edge: true
skip-cleanup: true
keep-history: true
github-token: $GITHUB_TOKEN
local-dir: dist/
target-branch: gh-pages
commit_message: "Deploy Release"
on:
branch: main
Did you try to confirm your account with the email that Travis CI is sent to you?
With the new feature of Travis CI, you will need to confirm your account once your sign up for travis-ci.com. To confirm you get an email that is attached to your GitHub accounts. After confirmation, you will be able to see the "Trigger Build" option visible.

Google Cloud Build - Summary status shows FAILURE, all steps succeded

I've setup a Google Cloud Build pipeline that'll build a docker image from a Dockerfile, test the image and push the image into Google Container Registry.
Upon running the pipeline I noticed that all defined steps passed with SUCCESS status but the build summary itself returned with FAILURE status even though I can see the image being produced into Google Container Registry.
I used following command to build the image
gcloud builds submit --config cloudbuild.yml --gcs-log-dir 'gs://<bucket>' .
and below is the error message returned:
ERROR: (gcloud.builds.submit) build www-xxxx-yyyy-zzzz completed with status "FAILURE"
🚨 Error: The command exited with status 1
Is there any reason for the gcloud builds submit command to exit with code 1 as above if all the steps were marked as SUCCESS?
Below is some filtered log data taken from gcloud builds describe command for that specific build.
steps:
- args:
- build
- -t
- <host>/<project/<image>:<tag>
- .
name: gcr.io/cloud-builders/docker
status: SUCCESS
- args:
- test
- --image
- <host>/<project/<image>:<tag>
- --config
- test_config.yml
- -o
- json
name: gcr.io/gcp-runtimes/container-structure-test
status: SUCCESS
Below is Google Cloud Build setup:
# cloudbuild.yml
steps:
# Build the image
- name: 'gcr.io/cloud-builders/docker'
args: [ 'build', '-t', '<host>/<project/<image>:<tag>', '.' ]
# Test the image
- name: 'gcr.io/gcp-runtimes/container-structure-test'
args: [
'test',
'--image',
'<host>/<project/<image>:<tag>',
'--config',
'test_config.yml',
'-o',
'json'
]
# Push the image
images: [ '<host>/<project/<image>:<tag>' ]
I've finally resolved this issue with the assistance of Google Cloud support team.
They found out a 403 Permission Denied error as the Cloud Build container trying to access Google Cloud Storage to delete a certain log object stored in the bucket, this error message is found at the back system of Cloud Build where users/clients have no access to. The 403 Permission Denied error is the result of the object retention policy applied to the bucket.
In my case, I've replaced retention policy with lifecycle policy to resolve this issue and it worked. We do this as we consider keeping Cloud Build log size under control is our primary objective and, to prevent any accidental deletion/modification to the log file, we ended up with setting read-only access to the resources in the log bucket except for the service account used by Cloud Build.

Travis.ci - Build and Deploy based PR and Tags

I'm trying to create two different actions within travis.ci. The first action is to execute a script on every push on every branch. This is currently working as desired. The second is to trigger a different script only when git push origin --tags. In short:
Execute script1 always (currently working)
Execute script2 when tags are pushed
Here is what I'm trying:
language: python
python:
- 3.7
matrix:
include:
- python: 3.7
sudo: true
install:
- pip install -r requirements.txt
script: # Always want this to happen
- invoke package
branches:
only:
- master
- /^x\/.*/
deploy: # Want this to occur on git push origin --tags
provider: script
script: invoke release
on:
tags: true
The deploy section is not being triggered, and I can find no evidence of the invoke release script being invoked.
Update:
It may be due to the way I'm pushing tags..? I'm seeing this log in travis now:
Skipping a deployment with the script provider because this is not a tagged commit
Solved it from this github issue. Changed the deploy section to this:
deploy:
provider: script
script: invoke release
on:
tags: true
all_branches: true
but had to remove the branches section. Deployment script was invoked, nonetheless.

Publishing to NPMJS with Travis CI

I've set up a Travis CI to run a few scripts that should:
Deploy some static pages to Github pages
Deploy an NPM package to npmjs
Item 1 works, Item 2 doesn't.
Here's what my travis.yml file looks like:
language: node_js
node_js:
- '10'
script:
- gulp build
- gulp npmDist
deploy:
- provider: pages
local_dir: dist-site/
skip_cleanup: true
github_token: "$GITHUB_TOKEN"
on:
branch: master
- provider: npm
email: myemail#mydomain.com
api_key:
secure: THE-API-KEY-I-GOT-BY-CREATING-A-TOKEN-ON-NPMJS-AND-ENCRYPTING-IT-USING-TRAVIS-ENCRYPT-COMMAND-IN-TERMINAL
on:
tags: true
repo: githubaccount/reponame
all_branches: true
I trigger the script in two ways:
- When I merge to master, it deploys to GitHub Pages.
- When I create a tag and push to master it should deploy the package to npmjs.
As stated, the first part of the file works, as it actually deploys to GitHub Pages.
Here's the error I get from npmjs:
npm ERR! publish Failed PUT 401
npm ERR! code E401
npm ERR! You must be logged in to publish packages. : package-name
(oh, and a strange thing: Travis returns with a "Build Passed" and the succesful status (green), even though there's obviously something wrong)
Hope this makes sense? Thanx in advance for any help.
Fixed it — instead of having this in the travis.yml-file:
api_key:
secure: THE-API-KEY-I-GOT-BY-CREATING-A-TOKEN-ON-NPMJS-AND-ENCRYPTING-IT-USING-TRAVIS-ENCRYPT-COMMAND-IN-TERMINAL
I changed it to:
api_key: "$NPM_TOKEN"
..and added the NPM Token as an environment variable inside the Travis CI dashboard.
(Still curious as to why it didn't work, but I can't be bothered to do something about, as I've already wasted way too much time on this issue today)
I had the same problem and I just removed all previous keys and generated them again and my code looks like this:
deploy:
provider: npm
email: $NPM_USER
api_key: $NPM_TOKEN
To create your NPM_TOKEN you must:
Go to your npm profile
Tokens
Create Token
Select "Read and Publish" and create it.
Then you can specify it in your env variables for the corresponding project.
The key do not have to be encrypted and the user is your email. That will be it.
You will receive a notification like:
Installing deploy dependencies
dpl.2
Preparing deploy
dpl.3
Deploying application
+ your-artifact#x.x.x

Resources