Moodle Development kit - Revision history

Devdocsbot: Protected "Moodle Development kit": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

2022-05-06T07:27:17Z

Protected "Moodle Development kit": Developer Docs Migration ([Edit=Allow only administrators] (indefinite))

← Older revision	Revision as of 07:27, 6 May 2022
(No difference)

Andrewnicols: Update migration status and path

2022-04-20T06:45:54Z

Update migration status and path

← Older revision		Revision as of 06:45, 20 April 2022
Line 1:		Line 1:
	{{Template:Migrated\|newDocId=general/development/tools/mdk}}		{{Template:Migrated\|newDocId=/general/development/tools/mdk}}
	Every developer creates simple tools to avoid repeating cumbersome and/or boring tasks, and that is precisely why MDK has been created: to pack all those useful tools in a portable way across systems. Initially developed in Bash, the project moved to Python to avoid dealing with inconsistencies between Unix platforms, and eventually to support Windows.		Every developer creates simple tools to avoid repeating cumbersome and/or boring tasks, and that is precisely why MDK has been created: to pack all those useful tools in a portable way across systems. Initially developed in Bash, the project moved to Python to avoid dealing with inconsistencies between Unix platforms, and eventually to support Windows.

Andrewnicols: Note migration to new docs

2022-04-19T14:11:50Z

Note migration to new docs

← Older revision		Revision as of 14:11, 19 April 2022
Line 1:		Line 1:
			{{Template:Migrated\|newDocId=general/development/tools/mdk}}
	Every developer creates simple tools to avoid repeating cumbersome and/or boring tasks, and that is precisely why MDK has been created: to pack all those useful tools in a portable way across systems. Initially developed in Bash, the project moved to Python to avoid dealing with inconsistencies between Unix platforms, and eventually to support Windows.		Every developer creates simple tools to avoid repeating cumbersome and/or boring tasks, and that is precisely why MDK has been created: to pack all those useful tools in a portable way across systems. Initially developed in Bash, the project moved to Python to avoid dealing with inconsistencies between Unix platforms, and eventually to support Windows.

Mudrd8mz: Reverted edits by Mudrd8mz (talk) to last revision by Tusefomal

2021-08-09T13:17:02Z

Reverted edits by Mudrd8mz (talk) to last revision by Ferran Recio Calderó

← Older revision		Revision as of 13:17, 9 August 2021
Line 52:		Line 52:
	mdk create -i -v 24 -e mysqli -r dev users -n stable_24-mysql		mdk create -i -v 24 -e mysqli -r dev users -n stable_24-mysql

	== ~~tableing~~ an issue ==		== Fixing an issue ==

	mdk fix 12345		mdk fix 12345

Mudrd8mz: MDLSITE-6551

2021-08-09T13:06:51Z

MDLSITE-6551

← Older revision		Revision as of 13:06, 9 August 2021
Line 52:		Line 52:
	mdk create -i -v 24 -e mysqli -r dev users -n stable_24-mysql		mdk create -i -v 24 -e mysqli -r dev users -n stable_24-mysql

	== ~~Fixing~~ an issue ==		== tableing an issue ==

	mdk fix 12345		mdk fix 12345

Tusefomal: /* Backporting a fix */

2020-11-04T11:55:50Z

Backporting a fix

← Older revision		Revision as of 11:55, 4 November 2020
Line 102:		Line 102:
	mdk create -v 37 -i -r dev users makecourse -n stable_37		mdk create -v 37 -i -r dev users makecourse -n stable_37

	Once you have the stable_XX versions, go to the branch you want to backport and execute:		Once you have the stable_XX versions, go to the instance where you have the branch you want to backport and execute:

	mdk backport --versions 37 38 --push --update-tracker		mdk backport --versions 37 38 --push --update-tracker

Fox: /* Backporting a fix */

2019-12-04T10:22:27Z

Backporting a fix

← Older revision		Revision as of 10:22, 4 December 2019
Line 106:		Line 106:
	mdk backport --versions 37 38 --push --update-tracker		mdk backport --versions 37 38 --push --update-tracker

	~~En the~~ example params are:		The example params are:
	* -v 37 38 backports the patch to the versions 3.7 and 3.8		* -v 37 38 backports the patch to the versions 3.7 and 3.8
	* --push pushes the branch to github		* --push pushes the branch to github
Line 113:		Line 113:
	After the execution, your stable_XX instances will be on the fix branch, commits are pushed to you github project and backport links will be updated in the tracker.		After the execution, your stable_XX instances will be on the fix branch, commits are pushed to you github project and backport links will be updated in the tracker.

	Of for some reason one cherry pick could not finish successfully, mdk will ask you if you want to keep this backport on no. If you choose to keep the partial backport, your stable_XX instance will be in cherry-picking state. In that case you need to solve any conflict and ~~user~~ mdk to push your changes:		If for some reason one cherry pick could not finish successfully, mdk will ask you if you want to keep this backport or no. If you choose to keep the partial backport, your stable_XX instance will be in cherry-picking state. In that case you need to solve any conflict and use mdk to push your changes:

	# go to your stable_XX with cherry pick conflict		# go to your stable_XX with cherry pick conflict
Line 120:		Line 120:
	# once all conflicts are solved, push to your repository and tracker using		# once all conflicts are solved, push to your repository and tracker using
	mdk push -t		mdk push -t


	== Upgrading the instances ==		== Upgrading the instances ==

Tusefomal: /* Typical workflows using MDK */

2019-12-04T09:51:10Z

Typical workflows using MDK

← Older revision		Revision as of 09:51, 4 December 2019
Line 95:		Line 95:
	mdk phpunit -r -u repository/tests/repository_test.php		mdk phpunit -r -u repository/tests/repository_test.php

			== Backporting a fix ==

			MDK could handle for you most of the cherry-picking work when you backport a fix. To do so, you need to have installed locally instances called "stable_XX" for each version you want to backport your fix. To do so you can use commands like:

			mdk create -v 38 -i -r dev users makecourse -n stable_38
			mdk create -v 37 -i -r dev users makecourse -n stable_37

			Once you have the stable_XX versions, go to the branch you want to backport and execute:

			mdk backport --versions 37 38 --push --update-tracker

			En the example params are:
			* -v 37 38 backports the patch to the versions 3.7 and 3.8
			* --push pushes the branch to github
			* --update-tracker updates the tracker issue

			After the execution, your stable_XX instances will be on the fix branch, commits are pushed to you github project and backport links will be updated in the tracker.

			Of for some reason one cherry pick could not finish successfully, mdk will ask you if you want to keep this backport on no. If you choose to keep the partial backport, your stable_XX instance will be in cherry-picking state. In that case you need to solve any conflict and user mdk to push your changes:

			# go to your stable_XX with cherry pick conflict
			# solve conflicts with git mergetool or any other tool
			git cherry-pick --continue
			# once all conflicts are solved, push to your repository and tracker using
			mdk push -t


	== Upgrading the instances ==		== Upgrading the instances ==

Fpataleta at 01:33, 21 May 2019

2019-05-21T01:33:59Z

← Older revision		Revision as of 01:33, 21 May 2019
Line 154:		Line 154:
	## Via Homebrew: ''brew upgrade moodle-sdk''		## Via Homebrew: ''brew upgrade moodle-sdk''
	# Run MDK doctor to fix its ''masterBranch'' configuration. ''mdk doctor --fix --masterbranch''		# Run MDK doctor to fix its ''masterBranch'' configuration. ''mdk doctor --fix --masterbranch''
	# Run MDK doctor to check the master instances. If you don't see an error saying something like “stable_master is on branch master instead of MOODLE_XX_STABLE”, then you're all good. Otherwise, do a hard reset your master instances:		# Run MDK doctor to check the master instances. ''mdk doctor --all''
			#* If you don't see an error saying something like “stable_master is on branch master instead of MOODLE_XX_STABLE”, then you're all good. Otherwise, do a hard reset your master instances:
	mdk update -c		mdk update -c
	cd ~/moodles/[integration/stable]_master		cd ~/moodles/[integration/stable]_master

Fpataleta at 03:45, 20 May 2019

2019-05-20T03:45:01Z

← Older revision		Revision as of 03:45, 20 May 2019
Line 149:		Line 149:
	Every Moodle release, a new version of MDK is also being released in order to prepare for the development of the next Moodle version. To upgrade MDK:		Every Moodle release, a new version of MDK is also being released in order to prepare for the development of the next Moodle version. To upgrade MDK:
	# Update all of the Moodle instances: ''mdk update --all''		# Update all of the Moodle instances: ''mdk update --all''
			# Check out the master branch for all of your master instances, e.g. in your stable_master branch: ''git checkout master''
	# Upgrade MDK		# Upgrade MDK
	## Via pip: ''sudo pip install moodle-sdk --upgrade''		## Via pip: ''sudo pip install moodle-sdk --upgrade''