IssueContent="`sed ':a;N;$!ba;s/\n/\\\n/g' $pth/issueTemplate`"

Will got this on FreeBSD v10.2

sed: 1: ":a;N;$!ba;s/\n/\n/g": unused label 'a;N;$!ba;s/\n/\n/g'

To help debug.

Including npm and submodule installation and updating.

Current order is not reliable enough.

Can print more detail messages for debug.
(also in log)

I wonder some build failed on my new machine is because there is no system wide nodejs and npm, should support nvm.

Aliased commands may cause a wrong/unexpected result.

Currentlly, logs are handled by each functions, like output()/run(), that's not maintainable, should separate it out.

• Basically purge the cache of homepage and libraries list.
• Advanced purge the cache of certain libs, needs build process support.

Ref: https://api.cloudflare.com/#zone-purge-all-files

For output report

Wait for #25 implement log() function

Still pushed meta branch ... 4265880

When the network is unstable, the issues may be too many and annoying.

Should retry if command failed, especially the commands need networking.

thank you!
come from cdnjs/new-website#108
I am learning the code of this project, I already see line 29 of buildScript/update-website.sh(See https://github.com/cdnjs/buildScript/blob/master/update-website.sh#L29), I found no $pth/colorEcho/dist/ColorEcho.bash file. How to get the colorEcho which like a plugin? I use windows.
thank you!

Currently, only local terminal will catch that event, see:
https://github.com/cdnjs/buildScript/blob/master/update-website.sh#L50-L53

Should also report that in issue, like ... cdnjs/cdnjs#5877

    if [ "$isBuiltIn" = "false" ]; then
        nice -n $nice timelimit -q -s 9 -t $((timeout - 2)) -T $timeout "$@"
        local exitStatus=$?
        if [ $exitStatus -eq 137 ]; then
            error "Got timeout($timeout sec) while running command: '$@'"
        elif [ $exitStatus -ne 0 ]; then
            error "Got error while running command: '$@'"
        fi
    else
        "$@" || error "Got error while running command: '$@'"
    fi

if [ "$1" = "build" ]; then
    set -e
    init
    build
fi

bash will catch the error by set -e ...

The window title will be "bash " by default because this is a bash shellscript project, so it is unrecognized once we are using bash as our shell, there is no difference between this buildScript and an interactive bash, we should set a title for it.

Currenttly, many messages with "Success" are not really a message with success but just designed to use it's color, should change it to "Info" or something else.

To prevent infinite waiting on a certain command.

We can easily have timeout on GNU/Linux distrobutions, but FreeBSD need version 11 to have it.

Some standard outputs may be useless, should hide them.

There are some commands can fail without catch:

I thought there are at least 2 part:

command like this:

timelimit -q -s 9 -t 1 -T 2 cd /home/peter/cdnjs-deploy/new-website

Will not get any error but in fact don't change it's directory.

Should return non-zero status.

$ ./build.sh
Main repo not found, exit now.
Error on curl!!! Message may not be posted on our gitter chatroom
$ echo $?
0

We have submodule tutorials under new-website, should better do submodule update like:
git submodule update or git submodule update --init during the build to prevent unstaged changes.

It's also possible to update submodule during the process and automatically commit the updates of submodules.

cc @cdnjs/team-cdnjs

As title, for debug.

nice works when been manually triggered but not working when triggered by cronjob

• datetime
• option to decide cleanup or append the old log
• custom log file path

The issue in our main repo:
cdnjs/cdnjs#5549

This time, the breakpoint seems to the timeout of curl post to gitter's hook, this should not break the whole build process I think, it's not a critical job in the whole process.

Once git operation timeout occurred, the git process will be killed, but its lock won't be removed, so caused a series build failed.

cdnjs/cdnjs#7167
cdnjs/cdnjs#7168
cdnjs/cdnjs#7169
cdnjs/cdnjs#7170
cdnjs/cdnjs#7171
cdnjs/cdnjs#7172
cdnjs/cdnjs#7173
cdnjs/cdnjs#7174
cdnjs/cdnjs#7175

The project could not be analyzed because of maven build errors. Please review the error messages here. Another build will be scheduled within 24 hours. If the build is successful this issue will be closed, otherwise the error message will be updated.

_{This is an automated GitHub Issue created by Sonatype DepShield. GitHub Apps, including DepShield, can be managed from the Developer settings of the repository administrators.}

• Force rebuild option
• Force reindex option
• More error detection and exit when getting error
• Logs (?)
• Website repo should has 2-tier update (fetch from local repo as main repo).
• Gitter webhook
• Color output

The issue is about why we have so many build-failed issues in a short time, and in series.

Examples:
cdnjs/cdnjs#7139
cdnjs/cdnjs#7140
cdnjs/cdnjs#7141

We have time limit setting here:

https://github.com/cdnjs/buildScript/blob/master/config.sh#L14

timeout=600

https://github.com/cdnjs/buildScript/blob/master/update-website.sh#L82

nice -n $nice timelimit -q -s 9 -t $((timeout - 2)) -T $timeout "$@"

So we have 10 mins for each command by default.

By tracing the log, I found the failed point usually be this line:

https://github.com/cdnjs/buildScript/blob/master/update-website.sh#L110

run git reset --hard

I found that once I reboot my server, almost the all the git commands in cdnjs repo will be very very slow, the hard disk will be noisy for a while, the memory usage increase, it will continue about 15~25 mins, and once it finished, the upcoming commands will be very fast, maybe just few seconds, so I guess linux will cache the recently used files on the filesystem, but once we reboot, the cache had been flushed, the only first git command after booting will be very slow, maybe adding a warm-up command can improve this problem.

Today we got problem on heroku deployment:
cdnjs/cdnjs#5305

This build script successfully detected the unsuccessfully building process and submit an issue for tracking this issue, I was just around my computer and try to trace the problem and pause the cronjob for cdnjs building, in case I am not around, the crontob will continue calling the build process every hour, will cause message/issue flooding until the problem been solved, I think we should provide a mechanism to prevent this problem.

Essential feature(s):

• Write a error record as a lock when getting error.
• Detect the lock from the start, skip build if lock exists. (Need manually remove it when problem been fixed.)

Advanced feature(s):

• Do not skip the following build process, but reply the status on the same issue(need to write down the issue number first)
• Automatically report and close the issue when the first successful build come up.