I appear to be experiencing the same issue, unfortunately.
Hi @dundonian and @Matt_Reimer,
Iāve looked into it and it looks like Wercker made an undocumented (so far) change in the way they work. I released a new version of the step that takes this into account (1.8.2).
For me this seems to have fixed the issue, but can you please verify if itās working for you as well now?
1 Like
Hi @ArjenSchwarz, adding this to the end of my build step (per the discussion on the Wercker Slack channel) did the trick for me:
- script: name: copy output directory code: | cp * -R $WERCKER_OUTPUT_DIR
Weird. Seems fixed for me. I also got onto the slack channel @ArjenSchwarz thanks for looking into this. Hopefully we wonāt have too more of this kind of thing. Wercker is on warning for us. A CI tool that doesnāt deliver consistently is of zero use to us.
On the other hand, itās free soā¦
@ArjenSchwarz I have a slightly different use case and was hoping you could provide some guidance. Iām going to use Hugo to just produce some HTML snippets in the same repository as the rest of the source organization.
I have publishdir = "html-snippets" in my config.toml.
Here is my wercker.yml, which seems to be building successfully, but I canāt seem to get the Hugo build to publish the built contents to the html-snippets directory at the root.
box: golang
build:
steps:
- arjen/hugo-build:
version: "0.15"
config: config.toml
disable_pygments: true
The ultimate goal will be to use Hugo to build the full site, but for right now I am just leveraging it as a blazing fast SSG for snippets I need to create in an old/terrible legacy CMS.
I also set up the auto deploy to deploy to master, but to no avail. I think Iām missing something essential here. The build is happening, but I want the result of that successful build to end up in the html-snippets folder at the root of the repo.
Any help would be greatly appreciated. Thanks!
@rdwatters, if I understand correctly the code is generated but what isnāt working is pushing the result of the build back to your repository? Youāll need a deploy step configured for that, and something like the below might work. What this does (or is supposed to do, as I havenāt tested it from the root directory) is push up everything to the defined repository and branch. You can add this after the build step you have defined above and adjust it to your needs.
Iām not 100% sure if pushing it back to the master will cause the master to build again though, I suspect Wercker has protection against that, but Iāve never tried it. Either way, if you donāt need to push it back to the exact same branch Iād recommend you push it to something like a release branch instead so you donāt have generated code mixed in with your other work. Iām sure youāre in a better position to make that judgment though, so feel free to ignore that.
deploy:
steps:
- install-packages:
packages: git ssh-client
- leipert/git-push:
gh_oauth: $GIT_TOKEN
repo: YOUR_REPO HERE
branch: master
basedir: .
Let me know how it goes.
@ArjenSchwarz Thanks so much for your help. Iām currently just doing this on a play/starter repo Iām putting together.
I got it to work with the following (I wanted to push the build to a branch called āhtmlā):
box: golang
steps:
- arjen/hugo-build:
version: "0.15"
config: config.toml
disable_pygments: true
deploy:
steps:
- install-packages:
packages: git ssh-client
- leipert/git-push:
gh_oauth: $GIT_TOKEN
repo: rdwatters/hugo-starter
branch: html
basedir: .
I like your suggestion of moving just the built out code to a new branchāhence the switch to the āhtmlā branch. That said, right now itās copying the entire repo to the html branch. Is there a way for me to get just the public directory (ie, my publishdir in config.toml is public) to push to the html branch instead?
@rdwatters if you just want to push up the contents of that directory you can update the basedir part of the step to be that directory. In your case, that would make that line
basedir: public
@ArjenSchwarz You have been a HUGE help. Thanks so much! Freakinā awesome.
Iāve got this build to workāthanks to your inputāand put just the built content into a new āhtml-snippetsā branch. That said, it looks like moving the built content to a separate branch actually triggers another quasi-build in master, so the commit message in my new html-snippets branch is always ā[ci skip] deploy from rdwattersā - any thoughts on how to circumvent this extra/unnecessary step?
@rdwatters No worries, glad to help.
I just checked, and that step hardcodes the commit message to be ā[ci skip] deploy from $usernameā so that canāt be changed unless you use a different step. But what do you mean by it triggers another quasi-build? Does Wercker run again when the changes are pushed up to the html-snippets branch?
@ArjenSchwarz Yup, thatās basically it. See the attached screenshot. It runs the build, then the deploy without issue. Then, for whatever reason, it starts the build/deploy again but aborts it and leaves the ā[ci skip] deploy from rdwattersā as the commit message. Also, here is the repo Iām using for testing.
Hi @rdwatters, I just found the solution for that. In Wercker, if you go to the settings of your application then under Options there is the possibility to ignore certain branches. If you add your html-snippets branch to that it will no longer trigger a build for that.
@ArjenSchwarz Awesome. That did the trick. Even cooler? I found out that gh-pages is ignored by default and doesnāt count towards your 10 ignored branches. Wercker is really cool.
I canāt say this enough: THANKS! You saved me a ton of time. Cheers!
OK, Iāve been using this reliably for quite some time, and then my most recent build totally made things get really odd.
It seems like it rebased the github repo, and instead of deploying the content, it deployed the wercker code itself.
Take a look at the repo - itās super odd. https://github.com/devopsdays/devopsdays.github.io
@mattstratton it looks like the problem was a line of code that I put in when Wercker was having problems earlier this year. For some reason that started behaving weirdly after I made a completely unrelated change earlier today. Iāve removed it now, and at least my deployments are now working correctly again. Can you try a new deployment and see if it goes correctly for you as well?
My sincere apologies for causing this problem.
All better now! Thanks for the fix. Youāre awesome!
1 Like
So hereās a random idea I had, and Iām sharing it as I go to see if a) anyone has done something similar and b) to help others who want to do similar things.
Thereās been a request from some folks in our org for our Hugo site (currently being deployed via Wercker to GH Pages) to have a āliveā place to see changes. What Iām thinking is something like this:
- Have a branch called āstagingā which will kick off a certain wercker build
- This build should only deploy to either a) another GH pages or b) an Amazon s3 bucket.
If I recall correctly, setting up a GH pages under an existing account (when one already exists) might be less than delightful. We also are thinking about possibly moving to s3 instead of GH pages in general due to the lack of .htaccess rewrites in GH pages.
Iām going to attempt working on it this afternoon, but curious as to what initial feedback yāall have?
Hey @mattstratton, you may have finished your work on this now, but to me it sounds like a good idea. You can easily define multiple deployment targets (I wrote about how I did that in this article).
Following that you can then set up an automated deployment for your staging branch for that deployment the same way you probably already have for your master branch.
As for S3 instead of GH Pages, I believe youāre correct concerning that you can only have one version per project. You could theoretically push the staging result to a different repository, but thatās a bit of a dirty hack. S3 will probably be easier in that regard, especially considering the rewrites.
One more thing, last week Wercker introduced their new pipelines system. This might make the whole process easier, but as Iām currently overseas on holiday I havenāt had a chance to play with it yet.