custom domain keeps on getting removed every time i do a deployment - travis-ci

I’m using Docusaurus / Travis CI to build my docs and I’m trying to have them hosted on a custom domain - myproject.com. The way I have it setup right now Travis CI initiates a build every time I do a commit BUT the custom domain gets wiped out every time this happens. I can duplicate the issue by manually initiated builds myself.
It happens regardless of what the repo name is. I’ve tried myproject.github.io as the repo name and myproject.com (to match the custom domain) as the repo name. In both cases the custom domain gets wiped. When the repo name is myproject.github.io the site gets published to https://myproject.github.io/ and when the repo name is myproject.com the site gets published to https://myproject.github.io/myproject.com/ .
Am I just going to have to remember to always re-add the custom domain every time I make a commit to my build branch? 🙄

I had this issue, if you're pushing something to the gh-pages branch. it could be that you're not preserving the CNAME file.
When you add a custom domain, github automatically adds a CNAME file to your gh-pages branch with your domain inside it.

I figured this out. Farook's post pointed me in the right direction.
So when the branch is named myproject.github.io the master branch is used for deployments. Like myproject.github.io is a mirror of what's in the master branch.
The problem is that the *.md files that you modify to work with Docusaurus aren't the end product so you have to work out of a branch other than master. Within that branch a lot of the root contents are built from the *.md files but the rest of it is copied from the website/statics directory so I just put the CNAME file there and that worked!

Related

Bitbucket (server API) treats new files as renamed/copied old ones. Is there a way to prevent this?

The problem:
I'm using bitbucket stash (server) API in a script for my project with the {path} api method:
/rest/api/1.0/projects/{projectKey}/repos/{repositorySlug}/browse/{path:.*}
The idea was to save versions of config files in a repository (version01-versionXX for every config). But those configs have the same structure with different names and parameters,
so when I push a new config with a commit message like 'version01' without specifying any sourceCommitId, bitbucket automatically adds a parent commit from the last file with the same structure (if it exists). As a result, in this new file's history I'm getting several 'version01' commits, which is not what I was intended to have.
What I've tried:
If I do specify sourceCommitId as the initial or the last commit on the branch, I get an error message since the file doesn't exist on this commit.
I've tried to experiment with empty sourceBranch parameter, but still some parent commit appears.
The only idea I came up with is to create a new branch for every config, but this seems like overkill to me.
All attempts to find a method for editing file commit history via API also failed.
At the moment as a work around I create every config file with its name as the only line of its content and then change it to the structure I need. This works so far, but doesn't look like a good solution to me and requires 2 API requests instead of one.
Is there a better way to prevent BitBucket from treating those new files as copies of old ones?

Jenkins GitHub Webhook not triggering builds

I have a Jenkins server (2.249) setup and I have connected my GitHub account and tested the connection and it works fine, but for a normal pipeline job where you enter the GitHub repo url, Jenkins seems to add an extra slash at the end? So I can't get my normal pipeline job to build on a push event, I've checked the logs and it says:
skipped [repo-name] because it doesn't have a matching repository.
So I've starting to think its because Jenkins is adding an extra slash at the end of my repo url? The webhook on the GitHub side works as it gives back a green tick and it works on another multibranch job for push events, just not the normal pipeline jobs.
Don't know if the problem is still on after more than one year but because I've just faced the same issue, here is an answer that help me to understand : https://serverfault.com/a/884717
Just to resume the answer : you have to complete the git part (scm) of your Project Configuration :
For my part: as the project is a private one, in an organisation that I can't update to add a personal token (as I'm not the owner of the resource - organisation), I choose to use the git+ssh url with a ssh key access to this repo. The next trick for github is to add the github's IPs to the jenkins user know_hosts file !
The reason behind the need to add twice the repository url is obscure. But I could only see that in https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/com/cloudbees/jenkins/GitHubRepositoryNameContributor.java#L113 the method parseAssociatedNames will try to get the Jenkins'job associated names from :
com.cloudbees.jenkins.GitHubRepositoryNameContributor$FromSCM
com.cloudbees.jenkins.GitHubTrigger$GitHubRepositoryNameContributorImpl
org.jenkinsci.plugins.github_branch_source.GitHubSCMSourceRepositoryNameContributor
I think the third one is for multibranch pipelines. I don't really know for the second but indeed the first one is fromSCM configuration !

Changing path in an config file stored in TFS

We have a solution stored in TFS that deploys to SharePoint. As part of the solution we have a config file that has a path to a specific site. The problem is this path changes dependent on the users dev machine e.g
<site>devmachine1/somesite</site>
<site>devmachine2/somesite</site>
This can obviously be updated to work locally after a check out however when the file gets checked back in it will be incorrect on the next users machine if they do a Get. Is there a way that the file can be excluded or a script can be run to update the path when checked back in or out?
The best option I'd to rationalist all of the developer workstations.
I would do this by adding an identical entry to the hosts file that hard coded the name of the Sharepoint, allowing you to have the same config file work on every dev machine.
Make it dynamic by having a pre build instruction that adds the host, that way any developer can get and build.
You can use a custom check-in policy to update back the file when is checked-in. See here

RefineryCMS Changing Site Name in Production

I have a refinery site up on heroku and, in order to change the site name I have been going to my local copy, changing config.site_name, adding the new config file to my git repository, and doing git push heroku master. Though I don't anticipate having to change the site name that many more times (I have a client who is still deciding on a final site name), I was wondering if there was a faster way to do this (I tried to figure out if this was a config option I could just change from the terminal in heroku but to no avail).
I will suggest to add new model 'site_setting' for adding some additional settings. So you can add one column ie site_name. So admin can dynamically add/update the name of site by providing simple UI to insert the name of site.
Remaining task is to add that object at site_bar.html.erb
I hope this work for you.

How do you deploy and build an application using bitbucket and AppHarbor?

Here is what I've done so far.
Grabbed the Repository URL from AppHarbor
In bitbucket, I configured the AppHarbor service to use that token.
For the project, I entered the same name of the application I used in AppHarbor (I have no idea what a slug is)
I saved the settings
I granted apphb read permissions in Access Management
I pushed to bitbucket. I even created a dummy changeset to make sure it would get a new push
In AppHarbor, I clicked on "Build URL" and it tells me that my URL was succesfully copied to the clipboard.
I followed the guide to the letter (well, with the exception of the slug, so I'm expceting that is the issue).
Steps to Follow and what gets filled in where:
On BitBucket:
Apphb needs read access to the repository (if it's private)
Go to admin
Add Service: AppHarbor
Token is the UglyValue from the "authorization=UglyValue" part of the build url
Project Name is the last part of the url when looking at that application on AppHarbor. So https://appharbor.com/applications/slug-is-here would use "slug-is-here"
Then you are good to go. You can get more complicated than that (like branches and whatnot) but that's the basic setup.

Resources