It also tells the pipeline to only run this task on the master branch (you can change that to be any branch you release from). This names the pipeline job "Tag Release", and allocates it to the stage 'tag'. This first part defines the docker image to use, the stages of the pipeline, and then updates Ubuntu (the Docker image used), and installs the basic components we require to undertake the tagging and release.
This allows markup to be used within the release notes.īreaking down the file gives us the following: image: ubuntu:focal md file which is named the same as the version i.e. This requires there to be a folder called changelog and then each release to have its own. Git tag -a $VERSION -m "Version $VERSION"Ĭurl -header 'Content-Type: application/json' -header "PRIVATE-TOKEN: $OAUTH2_TOKEN" \ git config -global user.name "username" git config -global user.email "your_email" MESSAGE="$(php -r "echo json_encode() ")" VERSION="$(php -r "echo json_decode(file_get_contents('./composer.json'), true) ")"
#FINAL DRAFT TAGGER MANUAL INSTALL#
DEBIAN_FRONTEND=noninteractive apt-get -y install php php-json git openssh-client curl
#FINAL DRAFT TAGGER MANUAL UPDATE#
DEBIAN_FRONTEND=noninteractive apt-get update gitlab-ci.yml file to perform this action in isolation with no other pipeline elements is simply: image: ubuntu:focal Setting it as protected and masked will ensure it doesn't appear in and console output for the pipeline job The token generated when "Create personal access token" is pressed should then be added as a CI/CD variable within the project settings. You can create an access token by going to User Settings and selecting Access Tokens from the menu. This needs to have api and write_repository access. The tag and release should always be the final stage of the pipeline.īefore starting, make sure you have a personal access token ready to use. gitlab-ci.yml file and, if needed, creates a new branch and performs the release.
You commit a change to your default branch, it runs the pipeline defined in your. You also keep full control over your version numbers, and can build release notes to be used as part of the release. Doing so will mean you manually have to change the version, but doing this as part of the work for a sprint is a small task, and will mean no more worrying about whether all commit messages meet the guidelines for a package to determine the next version number. This is a great place to store the version of your application or package using the version field of the schema. If you work with PHP for projects, there's a good chance you work with Composer as a package manager, and therefore have a composer.json file.
0 kommentar(er)
