I use Vercel to deploy a Next.js app and I use Vercel for GitHub for CI/CD. Vercel automatically deploys code pushed to my master branch to production, and I would like to keep this functionality. However, Vercel also creates preview deployments for each push, and when I create a pull request, this deployment shows up under 'Checks.' Is there a way to stop this from happening? I don't have an issue with Vercel creating a preview deployment for each push I make, but I would like for Vercel's deployment not to appear under the 'Checks' section of each pull request.
You can use the "Ignore Build Step": https://vercel.com/support/articles/how-do-i-use-the-ignored-build-step-field-on-vercel
You can tell Vercel only to build master (or main depending on your git configuration), and all other branches will be ignored.
EDIT: Thanks to #Dani Akash for the suggestion below
Adding the following command in the ignored build step box of /settings/git page of your project to disable running the builds for non-production environments. Effectively disabling deploy previews
[ "$VERCEL_ENV" != production ]
Related
We are managing to change our CI/CD process on github. Previously we were using one branch by environment (Test and Production).
Now, we would like to have the same build deployed on all environment. So we are using one main branch which build and allow to deploy on Test environement and if it succeed and approved to prodution.
So far so good.
Most of the time, we are deploying in Test environment only. For this cases, we are rejecting or cancelling the workflow after deploying to Test but our actions and Pull request are all in failled state.
The question is, how could we manually skipped the production deployment without having the status of Github action being failed.
Thanks in advance
Our Company used to self-host GitLab for source-code management and configured webhook on gitlab to trigger all the project pipelines on jenkins. Initially, the gitlab url was 'https://git.fulcrumdigital.com' and later for an upgraded version, they changed url to 'https://autobuild.fulcrumdigital.com'
Recently, we migrated to 'github.com' and created an organization. The source codes for various projects are found under this organization, which is private. Now, when I try to configure webhooks for these projects, I see that they deliver as intended to jenkins, but jenkins doesn't trigger the respective project's build. Instead, it gives out a message as shown below.
jenkins-github webhook error
I don't find any info regarding this webhook on global configuration page.
Here is a snapshot of jenkins logs
jenkins logs
I don't face this webhook issue for newly created pipeline-projects on jenkins. I face this issue for older pipeline-projects that already had their webhook configured earlier for gitlab.
Help me to resolve this issue and make jenkins trigger build from github webhook for older pipeline-projects.
Did you try force regenerating the webhooks?
Go to Manage Jenkins > Configure System > GitHub plugin > Advance > Re-registers hooks for all jobs.
I had this problem myself. The first thing you want to do is go to Manage Jenkins -> Configure System scroll down to the GitHub section and click on "Advanced". You will see this:
It's important to have access to your Jenkins log (I'm running Jenkins with Docker). When I clicked on Re-register hooks for all jobs, I got the following error:
In my case, the error mentioned something with my access token. So, I checked my Github personal access token and it turned out, I need to turn on Read and Write for Webhook:
Now, go back to Jenkins and click on Re-register hooks for all jobs again, and on the next push, the build was automatically triggered.
We are using Github + CircleCI + Heroku with automatic deploys setup.
From time to time there are deploy errors that are not captured by CI (deployment fails event though CI run is fine). We have review apps set up for all our PRs.
It would be great if the PR would indicate this and stop us from merging if the deployment of the review app fails (that usually means the deployment of the staging/production app would also fail).
I could not find any documentation on this. The only possible way I see is to use the GitHub API to add a custom check for this.
Anyone solved this issue?
We have made a GitHub Action to test the deployment status of a Heroku Review App: https://github.com/marketplace/actions/heroku-review-app-deployment-status.
This can be used in the GitHub workflow to test the deployment status.
UPDATE: We wrote a nice blog post about different approaches to verify Review App deployment status.
Link: https://blog.niteo.co/staging-like-its-2020/
You can use Github's protected branches for this https://help.github.com/en/articles/enabling-required-status-checks
Navigate to your repository's settings -> Branches -> Add Protection Rule -> Select "Require Status Checks Before Merging" and select "CircleCI".
In order for this to work you need to cause CI to fail if your deployment fails. If you get a failure from Heroku, you should run any command that will return exit 1 as a status code, which will fail CI for you.
I have a project hosted on GitHub and I have it compiling with Appveyor.
I would like to set up Appveyor so that each build is deployed as a GitHub release, but with each build overwriting the last. This way there will only be one GitHub release from Appveyor that will always have the latest build attached.
I can't see how to do this, because if I specify a release in appveyor.yml I get an error saying the release already exists (yes I want to overwrite it), and if I don't, then each deployment creates a new tag with the current build, which will litter the repository with useless tags.
On top of that, every time the release gets deployed, it creates a new tag which in turn triggers another Appveyor build. This means every push to the repository triggers two identical builds.
Has anyone worked out a way to deploy to the same GitHub release continuously, replacing the files with the latest versions, and to prevent a new Appveyor build from being triggered in response to an Appveyor deployment?
You can add force_update: true to GitHub deployment provider settings to overwrite existing release.
I'm wondering if there are any convenient ways to automate deployment of code to a live server in GO, either standard built-in methods, or otherwise.
I want something google app engine like, I just run the command and it uploads to the server and triggers a restart.
(Ultimately I want a git commit to trigger a rebuild and redeploy, but thats for down the track in the future)
I recommend Travis CI + Heroku.
You can deploy to heroku directly with just a git push, but I like to use Travis to build and run the tests before that.
There are some guides online but I'll try to go directly to the point:
What you will need?
Github account
Travis account (linked with github, free if open source)
Empty Heroku app (Free dyno works great)
Setup
In your github repo, create the following files:
.travis.yml (more info on the Travis CI documentation)
Procfile
.go-dir
After that go to your Travis account, add your repository and enabled the build for it.
Here is a sample minimal config file content (based on my app that I deploy to heroku):
.travis.yml
language: go
go:
- tip
deploy:
provider: heroku
buildpack: https://github.com/kr/heroku-buildpack-go.git
api_key:
secure: <your heroku api key encripted with travis encrypt>
on: master
Procfile
worker: your-app-binary
.go-dir
your-app-binary
Procfile and .go-dir are heroku configs so it can vary if you are deploying a web app, you can read more at the heroku documentation
One important and easily missed point is the build pack, without it the deploy will not work.
Read the Travis docs to see how to encrypt the heroku key
How it works?
Basically, every push to your repository will trigger the Travis CI build, if it passes it will deploy the app to heroku, so you set this up once and build + deploy is just a push away ;)
Also Travis will build and updated the status of all Pull Requests to your repository automagically.
To see my config and build, please take a look at my Travis build and my repository with my working configs