This question already has answers here:
How to force GitHub Pages build?
(11 answers)
Closed 2 years ago.
Situation
I am using GitHub Pages to display a simple landing page for my project with direct download links to artifacts generated by a GitHub Action. This information is pulled from the GitHub API via this syntax in the GitHub Pages index.md:
[Download Installer (Windows)]({{ site.github.releases[0].assets[1].browser_download_url }})
When I push to the master branch, I run an action that automatically releases new binaries as GitHub Releases. Unfortunately, the GitHub Pages page is being deployed at the same time, with the GitHub API still providing the previous release as the latest release.
GitHub Pages configuration
Deployment page:
Question(s)
How can I tell GitHub to only trigger a deployment of the GitHub Pages page after the release action has completed? Does an Action exist to trigger what GitHub seems to do automagically after each push? And is there a way to disable the automatic deployment so that the page only gets deployed after a (successful) release?
The only action keep getting to when googling is peaceiris/actions-gh-pages, but it seems to have been made to deploy web projects to GitHub Pages. Am I correct in thinking this, or is there a way to use this action to accomplish what I described?
I'm not sure about GitHub's automagic Pages deploy, but if you're somehow able to replicate that into a job of its own in your workflow file, you can use the needs attribute to make the deploy job depend on the release job completing. The 2 jobs must be defined in the same .yml workflow file.
Related
I'm collaborating on a website using Github for source control. The site is hosted on a shared server on Dreamhost. I'd like to set up an easy way for myself and my collaborator to be able to see changes that have been merged into the main branch on the staging site then also run a couple of other shell commands (composer update, for example, after deploying the changes).
I'm new to this. I've found pieces of relevant documentation but have not been able to tie it all together. So far I am running into at least two issues.
Setting up github environments to point to development and staging environments
I looked into Github Workflows but it seemed Github Actions might be easier. I set up Github Environments called staging and development. When setting up the environments, I saw the option to add environment secrets but don't know what exactly to add here. So my environments in Github have names but don't really point to my development and staging environments. I think the first thing I need to figure out is how to link my Github Environments and actual development and staging environments together. I found Deploying with Github Actions but didn't find an answer there.
Invalid workflow file error
Also I found an action in Github Marketplace called branch-deploy. I created a yaml file under .github/workflows to test it. When this runs, I see an error on the workflow in Github of
Invalid workflow file
The workflow is not valid. .github/workflows/deploy.yml (Line: 2, Col: 1): Unexpected value 'id'
Not sure what is going on with this error because the "basic usage" example in the Marketplace page uses the same value for id.
During an automated "pages build and deployment" workflow, I get the following error:
Error: Request failed with status code 400
This is just a static site, no jekyll or anything like that (I have a .nojekyll file in the root) and it's worked fine for several years until today.
I've opened a ticket on GitHub support, but in case anyone here can help me in the meantime... Is there anything I can do to try to resolve this?
It could be the side-effect of (from two days ago)
GitHub Pages: using GitHub Actions for builds and deployments for public repositories
Today you will begin to see a new workflow running called pages build and deployment in your public GitHub Pages repositories.
This workflow is automatically triggered when you push to the branch configured for GitHub Pages in your repository.
As the name suggests, it builds and deploys your pages site.
The initial benefit of this change is enabling you to see your build logs and any errors that may occur which has been a long standing issue for Pages users.
However, in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.
You may notice this workflow uses some new actions actions/pages-deploy, and actions/jekyll-build-pages.
For now these actions are designed to be used in the generated workflow, however, starting early next year we will introduce some additional changes that will enable you to take advantage of them.
Learn more about GitHub Pages
So Cecilapp/GitHub-Pages-deploy (the GitHub Pages deploy) workflow you might be using) might behave differently in light of those recent changes.
I have developed a tiny library that I chose to host on GitHub. The code is being built by a VSTS build and published as a NuGet package.
I have written a README.md file and I am trying to include a Build badge on it, as described in the Microsoft documentation. Consequently, I have added the following line in the MD file and replaced the placeholders accordindly:
The problem is that the link is not accessible to anyone that is not logged-in on VSTS and I end up with a 'broken' link on my readme page:
Question
What must be done to make the VSTS Build Badge available to a GitHub repo?
I suppose you must include an authentication token of sorts in order to have at least read-access to the VSTS build from your GitHub page.
Note that the documentation lists also multiple pending issues, including MicrosoftDocs/vsts-docs issue 1499:
Build status badge added to GitHub readme doesn't show up.
So this is still in progress.
On that last issue, it says:
This is due to public vs. private projects.
If you make your project public the image URL will render.
There are other potential workarounds we are looking at for the doc.
See "Change the project visibility, public or private".
I've noticed Github allows linking to deployments:
I currently have Travis CI doing automatic builds on new PRs and deploying the artifacts to transfer.sh. How could I get such a link to View deployment to show up in my Github PR?
You need to add an environment_url field when POST'ing the deployment status.
Additionally, you need to use the application/vnd.github.ant-man-preview+json Content-Type header as it's still a developer preview feature.
More info:
It's mentioned in the API docs https://developer.github.com/v3/repos/deployments/#create-a-deployment-status
https://developer.github.com/changes/2016-04-06-deployment-and-deployment-status-enhancements/#link-to-a-live-deployment
Currently, my team is using TeamCity to automatically build pull requests from GitHub.
We have a configuration to build all the pull requests. In the version control settings of the config, our branch specification is
+:refs/pull/*/merge
In the "Build Triggers" configuration setting, we have only one trigger with the following trigger rule:
+:root=Pull Requests on our Repository:\***/*\*
"Pull Requests on our Repository" is our VCS root name.
The issues:
When someone views a pull request on GitHub website without doing anything else, a build would be triggered in the TeamCity build agent. This is quite annoying, because from time to time, we have multiple build agents building the same pull requests (when multiple people view it).
When someone comments on a pull request, a build would also be triggered.
From my perspective, the only time I want TeamCity to start a build is when new commits are pushed to the pull requests.
Is there a way to do it?
Github's refs/pull/*/merge branches are updated every time mergeability of the branch is recalculated, i.e. on every commit to destination (most likely master) branch. They are also updated when pull request is closed and then reopened. Github's support says these branches are not intended for end users use. The only workaround at the moment is to run builds on refs/pull/*/head branches automatically and on refs/pull/*/merge branches manually.
Do you have TeamCity configured as per this blog post? I then activate the TeamCity service hook in GitHub which takes care of triggering a build in TeamCity whenever there is a push. This seems to do the right thing for me. Or am I missing something?
I know this is old but I wanted to post what we've found as alternatives:
Stop using VCS roots altogether as a mechanism for triggering pull requests. Instead, configure a GitHub webhook to notify a web app of yours whenever there is an update to a PR and only then trigger a build via the TeamCity REST API.
In your build config, add a step that checks what changed in the PR. If nothing changed (i.e. no new commits were added), or if the PR is closed, cancel the build. The problem with this is that the build queue will still be populated with builds that will then be cancelled. Also, you'd have to store somewhere the last commit that was built in order to do the check.
According to their TeamCity's issue tracker, the issue of the TeamCity.GitHub plugin causing an infinite loop of builds was fixed in v9.0