Drone is an open source CI/CD tool, based on the container to provide a powerful plug-in system. Many years ago I wrote a book called “Docker-based CI tool — Drone” that describes its advantages in detail. Drone adopts the Server/Agent architecture. The Server end is used to handle requests and distribute tasks to the Agent, and finally execute tasks on the Agent.

Drone as a whole is written with Golang, Drone/Drone-UI is its front-end page warehouse, developed with Vue.js (developed with React long ago). For projects with front and back end separation, a relatively normal middle will use a Web Server such as Nginx for bridging. The user will access the front-end page through the Web Server, and then the page will access the interface after the Web Server’s reverse generation. However, Drone Server is directly used by Golang’s own service, and Golang is a language that needs to be compiled. Bradrydzewski/Togo is a tool designed to compile static resources into Golang code in order to keep the Server compiled as a single file. The compiled result is essentially a hash table of file routing and content that can be seen in the official repository.

Once the compiled Golang file has been submitted to the repository, it can be loaded in as a module in the Server, and the rest is returned by routing the content in the Server. This is cumbersome to develop, but much more convenient for people who use it. However, since the static resources are compiled into the execution file, if we want to customize the front-end interface, we need to follow this process to rebuild and compile the Server execution file.

Building the front-end module

First of all, we need to Fork the original warehouse of Drone/Drone UI, and modify the front-end code according to your requirements in the new warehouse. In Radme, you learned how to develop in a development environment. If the change is not big, you can submit a Pull Request to the upstream warehouse for demand consolidation every time the Drone official release version is released. Performing NPM Run Build generates the final required front-end static resources in the dist/files directory.

Once the front-end resources are ready, you need to install Bradrydzewski/Togo to embed the static resources into the Golang code. If you don’t have Golang installed, you need to install it first. In addition, the global bin directory of Golang needs to be configured in the PATH environment variable, otherwise the command will not be found at compile time.

go get github.com/bradrydzewski/togo
cd dist
go generate dist.go

Note:
go generateIs a way to quickly execute a script using comments. It’s essentially executed
dist.goIn the file
togo http -package dist -output dist_gen.goThis order.

Finally, the dist_gen.go file generated by compilation is added to the warehouse and submitted to complete the construction of the front-end module. Next we need to rebuild the Server execution file.

Build execution file

The warehouse of Server execution files is Drone/Drone. We need to find the files that rely on the github.com/drone/drone-ui module and replace them with the new warehouse address that we Fork. There are three files that need to be replaced:./handler/web/{logout,pages,web}.

go get -v -insecure xxx.com/xxx/drone-ui
sed -i '' 's/github.com\/drone\/drone-ui/xxx.com\/xxx\/drone-ui/' ./handler/web/{logout,pages,web}.go

Note: For this kind of scenario, Golang official module management actually supports replace mode to replace module A with module B. However, I failed the experiment at that time, so I still used sed mode.

go mod edit -replace=github.com/drone/drone-ui=xxx.com/xxx/drone-ui

Then we can execute Go Build to build it. We haven’t made any changes to the project, just the front-end modules it depends on. Therefore, my idea is that when the Drone-UI warehouse is changed, the CI pipeline is executed to clone the Server warehouse and modify it to perform the mirror construction and upload it to the mirror warehouse.

CI implementation is of course to choose Drone, Drone to build Drone sounds very cool! The default Drone will clone the current warehouse, but in fact we do not need to clone the current warehouse, the current warehouse is the module that is dependent on the main warehouse. What we really need to download is Drone/Drone main warehouse.

clone: 
  disable: true

steps:
- name: clone
  image: alpine/git
  commands:
  - git clone https://github.com/drone/drone.git .
  - git checkout ${DRONE_TAG}

trigger:
  event:
  -tag

In the configuration of the Drone, set Disable: false to achieve not cloning the current warehouse. Then add Git clone steps on your own. We clone the repository into the current directory and switch the version of the Server repository based on the current Git tag version number. This ensures that the final compiled image will be the same version number and upstream without any other differences.

-name: build image: golang:1.14.4 commands: - go get -v -insecure xxx.com/xxx/drone-ui - sed -i '' 's/github.com\\/drone\\/drone-ui/xxx.com\\/xxx\\/drone-ui/' ./handler/web/{logout,pages,web}.go - sh scripts/build.sh environment: GOARCH: amd64 GOOS: linux

The following build command is shipped from the upstream Server repository with the exception of adding front-end module dependency substitutions. There are also ARM and ARM64 architecture versions in the upstream build. Since I don’t need them here, I won’t increase the build time.

After that, we will add the steps of Docker image build and upload as the official one to complete the creation of the final image. Use the image when using it.

Afterword.

Also built by Drone, the official https://cloud.drone.io for GitHub will also have a login page if you are not logged in. Principle is the Server service in pages. Go to judge access domain name for the “cloud. Drone. IO” words will display in the handler/web/landingpage/index. A static HTML page. These files can be modified for portal page requirements if necessary.